Choosing server or client rendering by journey

Server rendering, static generation and browser rendering solve different delivery problems. A service can combine them if ownership of data, caching, hydration and failure states remains explicit.

Classify the page requirement

Record whether content is public or personalised, how frequently it changes, whether it must be indexed, and what the user can do before JavaScript arrives. Use representative journeys rather than a site-wide label such as application or content site.

Budget the first useful response

Server rendering can deliver readable HTML early but may wait on backend data. Client rendering can reuse an API but adds script download, execution and a second request. Measure both on lower-powered devices and a cold connection.

Control hydration cost

If server HTML becomes interactive through hydration, quantify the JavaScript and main-thread work required to reproduce state already rendered. Use smaller interactive islands where the rest of the page remains stable content.

Design cache and personalisation boundaries

Cache public responses at the appropriate layer and keep user-specific fragments private. Avoid changing the same markup immediately after hydration because server and client interpreted locale, time or permissions differently.

Test degraded operation

Disable JavaScript, delay APIs, expire a session and serve stale content. Define which tasks remain available and how recovery works instead of allowing a spinner to become the only response to a backend fault.