Rendering
A site renders one of two ways, and the choice is a property of the site called the adapter:
ssr— the runtime renders HTML per request. See Server-side rendering.static— the build produces files, and the runtime executes nothing. See Static.
You usually don't set it. The platform detects the adapter from what your build actually produced and remembers it on the site — see Frameworks. Setting it explicitly is a check rather than an instruction: declaring ssr on a build that emitted only static files fails the build instead of deploying something that won't run.
Which one a storefront wants
A commerce storefront is ssr. Not as a default to reconsider, but because the pages that make money are buyer-specific: a price that depends on the customer's price list, stock that changes hourly, a cart, a signed-in account. None of that can be baked at build time, and rendering it client-side after paint costs you the SEO on exactly the pages you want indexed.
static is the right answer for the things around a storefront — a landing page, a campaign microsite, documentation, a brochure site. It is also what the framework quick-starts assume, because they are for apps that aren't storefronts.
The two aren't exclusive within one app. Nuxt, Next.js, SvelteKit and Astro can prerender some routes and render others per request; a site on the ssr adapter serves both, and the reference theme uses that — the shell and catalog pages cache well, the buyer-specific parts don't.
What changes between them
static | ssr | |
|---|---|---|
| When HTML is produced | At build time, once | On every request |
| Per-request code | None | Your server routes and render |
| Environment variables | Build time only — baked in | Build and run time |
console.log goes to | The browser console | The site's logs |
Default 404 | Served by the platform | Served by your framework |
| Cold start | None to speak of | Real, and worth measuring |
| Framework support | All fifteen | The eight with an ssr adapter |
| Runtime specification | Barely matters | Sizes the machine that renders |
Two of those rows decide most designs.
Environment variables. A static site can only read a variable at build time, so changing one always means a new deployment. A server-rendered site reads run-time values per request — but the variable still only reaches the runtime on the next deployment. See Environment variables.
Where logs go. On a static site there is no server, so nothing you log is visible to you — it goes to your visitor's console. On ssr, server-side output lands in the site's logs, which is where you debug a failing render. See Logs.
Neither one puts the render at the edge
Worth being explicit, because "edge rendering" is a phrase other platforms use and this one does not.
Your server-side code runs at the origin, in Germany. The four points of presence in front of it terminate TLS, filter the request and cache what is cacheable — so a rendered response still reaches the reader from nearby — but the render itself happens in one place.
That is good news for a storefront's data path: a catalog read from inside your render is a read in the same region, not a round trip across the network. It is the thing to know about the render path: work you put on it is paid at the origin, once per request, inside the site's request timeout.
Related
- Server-side rendering — the per-framework configuration and the injected variables
- Static — static builds, SPAs, and the fallback file
- Frameworks — the fifteen frameworks and how the adapter is detected
- Build configuration — the commands and output directory per adapter
- Catalog, cart and checkout — what belongs on the render path and what doesn't