Choosing between SPA, SSR, SSG, streaming, and hybrid rendering is rarely a purely technical decision. It is really a decision about where you pay for first-screen speed, how you handle SEO, how complex the deployment contour becomes, and who owns hydration failures in production.
The chapter is useful because it turns rendering debates into measurable trade-offs: TTFB, LCP, HTML cacheability, the cost of personalization, and the complexity of diagnosis. That shifts the conversation from framework ideology back to architecture for a specific product.
For interviews and reviews, this is important because rendering strategy is where frontend, edge, CDN, backend composition, and browser-runtime limits all meet in one decision point.
Practical value of this chapter
Design in practice
Split routes by class: public pages, catalog, checkout, signed-in workspace, and documentation often need different rendering models.
Decision quality
Evaluate the choice through TTFB, LCP, HTML cacheability, bundle size, personalization cost, and diagnostic complexity.
Interview articulation
Explain the choice as route class, SEO and latency constraints, data model, caching, hydration, and migration path.
Trade-off framing
Make clear where the main cost is paid: server, CDN, user device, or the team's operating complexity.
Context
Frontend Platform Performance
Rendering model affects perceived performance earlier than most local UI optimizations do.
Rendering model defines where the first useful screen appears: on the server, through a CDN, at the edge, or only after client code has loaded. That means SPA, SSR, SSG, islands architecture, React Server Components, and partial prerendering are really a conversation about latency, SEO, platform cost, and operating complexity.
The right question is not “which mode is best”, but “which route classes justify which trade-offs”.
This chapter connects rendering model, client runtime, server rendering, static generation, streaming rendering, hydration, partial hydration, React Server Components, partial prerendering, CDN behavior, TTFB, LCP, bundle size, personalization, and cache invalidation.
Rendering model map
A page can ship an empty shell, ready HTML, a static artifact, streamed HTML, or interactive islands. Switch modes to see where the first useful screen appears and where the main complexity is paid.
HTML on the server
The server renders HTML for the request, the browser sees content early, and client code hydrates the page afterward.
Input
Route request
The server receives URL, cookies, headers, and user context.
Rendering
Server runtime
It combines data, templates, and request context into initial HTML.
Response
Ready HTML
Search engines, previews, and users receive content before full client startup.
Interactivity
Hydration
Client code connects HTML to state and event handlers.
Architecture meaning
Use when
- Public pages need SEO and a strong first screen.
- Share previews, fast HTML, and controlled personalization matter.
- The team can operate a server runtime and debug hydration issues.
SSR delivers useful HTML earlier, but client code is still part of the cost: heavy hydration can still hurt user experience.
Where each model pays off
SPA
The server side stays thin: all UI logic lives in the client runtime, and the server only ships near-empty HTML and a bundle.
Best fit
Internal products, signed-in workspaces, and highly interactive flows where SEO is not the primary constraint.
Cost to manage
The first screen, bundle size, and state restoration after refresh are nobody else's job — the team owns each of them explicitly.
SSR / streaming SSR
Server rendering gives more control over initial HTML, link previews, and indexable content.
Best fit
Marketplaces, media, search pages, and mixed public/private routes where SEO and fast first view matter.
Cost to manage
Server runtime, cache invalidation, hydration diagnostics, and personalization all become more complex.
SSG / ISR
Static generation fits CDN delivery well, while Incremental Static Regeneration (ISR) refreshes ready pages without rebuilding the whole site.
Best fit
Documentation, knowledge bases, marketing pages, and catalogs with predictable update frequency.
Cost to manage
Without an explicit freshness policy, revalidation rules, and a boundary between shared HTML and personalized regions, the page eventually serves stale data.
Islands / partial hydration
The page stays mostly HTML and only the interactive regions come alive through partial hydration, so far less code ships to the browser.
Best fit
Content-heavy pages, landing pages, and reference material with a few interactive blocks.
Cost to manage
The price is stable widget boundaries, clear data exchange between islands, and separate diagnostics for each client-side island.
Modern models: Server Components and partial prerendering
The four modes above answer when and where HTML appears. React Server Components and partial prerendering add two more axes, so they are best examined next to streaming SSR and islands: the first changes where a component executes, the second changes how granular the boundary between static and dynamic is.
React Server Components (RSC)
Change not the rendering moment but the execution boundary: a Server Component runs only on the server — at build time or per request — and never ships its own code to the browser. The client receives the rendered output plus references to client bundles.
- Server Components are async: data is read during rendering, with no separate client request and no fetch waterfalls.
- The boundary is marked by the client directive; only Client Components hydrate, so client JavaScript and hydration cost drop.
- The server tree is sent not as HTML but as a serialized RSC Payload that streams and is merged into the client tree; Server Component code is never included in it.
- It needs a framework with server-side React support (for example, the App Router in Next.js); the model is stable from React 19 on.
Partial Prerendering (PPR)
Removes the whole-route static-or-dynamic choice: a single route serves a static shell immediately and streams personalized or fresh regions into dedicated holes within the same HTTP response.
- The static/dynamic boundary is Suspense: the fallback ships in the static shell, and the wrapped region's content streams in at request time once it is ready.
- It is built on Server Components: the shell arrives as HTML on first load and as an RSC Payload on client navigation.
- The static-or-dynamic decision is made per Suspense boundary, not per route — a hybrid inside a single page.
- In Next.js, partial prerendering became stable in version 16 and is enabled via the cacheComponents flag; the former experimental experimental.ppr was removed.
Architecturally this extends two of the chapter's rules: Server Components attack hydration cost at the model level, and partial prerendering moves the “shared cacheable frame vs personalization” boundary from the route down to an individual block.
Decision signals
- How useful the page must be before sign-in and before the heavy client runtime loads.
- Whether SEO, social previews, and a public first screen are hard requirements.
- Whether HTML can be cached at the edge or the response is too personalized.
- How often the content changes and how painful slightly stale HTML would be.
- Whether the team can operate server runtime, hydration mismatches, and hybrid routing.
Example route classes
Public landing page
SSG or SSRThe main constraints are usually SEO, fast first screen, link previews, and cheap CDN delivery.
Catalog and search
SSR, streaming SSR, or hybridThe user should see structure quickly, while filters, inventory, and recommendations often require fresh data.
Checkout and critical flow
SSR + client interactivityThe first screen matters, but correctness matters more: cart state, validation, and payment steps must stay controlled.
Dashboard or signed-in workspace
SPA or signed-in hybridIndexability is usually secondary; state, fast transitions, query caching, and response to user actions matter more.
Documentation and knowledge base
SSG / ISR + islandsMost of the page is static, while search, sandboxes, copy buttons, and filters can be interactive islands.
Related
Content Delivery Network (CDN)
HTML cache behavior, stale-while-revalidate, and invalidation paths often define the real cost of SSR and SSG more than the framework itself.
Architecture rules
Choose rendering per route class, not for the whole product
A landing page, search, checkout, and signed-in dashboard operate under different constraints. One global rendering mode is rarely optimal for every route class.
Hydration is an operational risk of its own
Mismatch between server HTML and the client tree often appears only in real conditions: timezone, locale, feature flags, A/B tests, and late-arriving data.
Personalization breaks cheap HTML caching first
The earlier user-specific regions enter the response, the harder it becomes to reuse shared HTML. It is often better to ship a common frame and fill personalization after first paint.
CDN and edge are part of rendering architecture
TTFB, cache keys, prefetching, and invalidation paths need to be discussed together with rendering model, not after the framework choice.
Data loading defines the real model boundary
If a screen depends on many sources, saying SSR or SPA is not enough. Decide where route loaders run, what can be shown partially, and which data can tolerate stale fallback.
Rendering trade-offs
Operational checklist
- Every key route has target TTFB, LCP, bundle-size, and time-to-interactive budgets.
- Cache keys, HTML lifetime, stale-while-revalidate behavior, and invalidation paths are documented.
- Hydration errors, locale differences, feature flags, and late-arriving data are observable.
- Each route class has an owner for rendering mode and migration decisions as the product grows.
- Slow regions have designed skeletons, stale fallback, partial responses, and understandable errors.
Common anti-patterns
Choosing one rendering mode for the whole product
The team ends up optimizing landing pages, checkout, and internal dashboards with the same rules even though their constraints are different.
Treating SSR as only an SEO tool
Server HTML also shapes first screen, link previews, caching, personalization cost, and operating complexity.
Ignoring hydration cost
Fast HTML does not save the page if the browser then spends too long executing client code before interaction works.
Designing CDN cache after the framework choice
Cache keys, invalidation, and personalization define the real cost of SSR and SSG as much as the runtime itself.
Practical takeaway
References
Related chapters
- Frontend Application Architecture: App Shell, Feature Modules, and Shared Kernel - provides the modular base on top of which route-level rendering modes are chosen.
- Frontend Platform Performance - shows how rendering choices translate into LCP, bundle budgets, and real user experience.
- Content Delivery Network (CDN) - adds edge-cache, invalidation, and TTFB context for SSR, SSG, and hybrid delivery.
- Edge Computing: Architecture and Trade-offs - helps explain when rendering logic is worth moving closer to the user.
- Frontend Data Layer: REST, GraphQL, BFF, and Orchestration - explains why rendering choices depend on data loading, aggregation, and route loaders.