What decides whether a product should render on the server or the client?
Show the full answer Hide the answer
What is being tested
Whether you choose from requirements rather than from framework default — which is how the decision is usually made.
What decides it
1. Who your users are, on what devices and networks. JavaScript is expensive on low-end devices — parsing and execution, not just download. A bundle that is fine on a developer's machine can take seconds on a mid-range phone. If a meaningful share of users are on constrained devices, server rendering moves that cost to your infrastructure where it is cheap.
2. First-load versus subsequent interaction. Content consumed once — an article, a product page, a search result — is dominated by first-load performance, favouring server rendering or static generation. An application used for an hour is dominated by interaction after load, favouring client rendering.
3. Discoverability. Content that must be indexed favours server-rendered or statically generated HTML.
4. How often content changes. Rarely: static generation, with the read path served entirely from a CDN and surviving an origin outage. Frequently and per-user: server rendering or client fetching.
5. Operational cost. Server rendering costs compute per request; client rendering shifts it to the user's device. At high volume that is a real budget line.
The usual answer
Hybrid — a server-rendered shell for fast first paint, hydrated for interaction, with subsequent navigation handled client-side. It costs complexity and it serves most products best.
The decision that matters as much
State ownership, which is the largest source of avoidable frontend complexity. Separate server state (a cache of remote data, stale by default, needing invalidation), client state (local UI concerns) and URL state (filters, pagination, selection — shareable and restorable).
Treating cached server data as local state produces synchronisation bugs indefinitely, because the client believes it owns data it does not own.
The failure to name
Rendering strategy chosen by framework default, then discovered to be wrong when performance is measured on real devices — which is usually late, because performance is measured on fast machines and fast networks where the users who suffer are invisible.