A commerce platform must choose between server rendering, static generation, client rendering and streaming for different pages. What decides each?

What decides each

• Static generation for content that is the same for everyone and changes rarely: category landing pages, editorial content, help articles. Cheapest to serve, best cache behaviour, and the answer whenever it applies — which is more often than teams assume.
• Server rendering for pages that are personalised or must reflect current data and where first-paint speed matters: product detail, search results. The trade is per-request compute for a faster first paint on a constrained device.
• Client rendering for interactive application surfaces behind a login, where the initial load is amortised over a long session: an account dashboard, a seller console. Search visibility does not matter and interactivity does.
• Streaming server rendering where a page has a fast core and slow supplementary sections — the product detail rendered immediately, recommendations and reviews streamed as they resolve. This is frequently the right answer for a commerce page and it removes the choice between a fast empty page and a slow complete one.

The decision inputs that matter

• Whether the content is cacheable and shared. A page identical for a thousand users should be generated once, and personalisation is what forecloses that — so the question is which parts are genuinely personal rather than whether the page is.
• The device and network of the actual audience. On a low-end phone, JavaScript execution frequently costs more than the network transfer, which argues against shipping a large client application.
• Whether search visibility matters, which for a commerce catalogue it does and for a logged-in console it does not.

The pattern that resolves the personalisation conflict

Cache the shared shell and personalise at the edge or on the client. The product page is generated once; the price for a logged-in customer, the recommendations and the basket state are applied afterwards.

That preserves the cache hit rate — which for a commerce platform is a direct margin consideration — while delivering the personalisation. Rendering the whole page per user because one element is personal is the common and expensive mistake.