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, and islands architecture 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, 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
Minimal server-side complexity with a flexible client runtime.
Best fit
Internal products, signed-in workspaces, and highly interactive flows where SEO is not the primary constraint.
Cost to manage
The team must manage first render, bundle size, and state restoration after refresh 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
Freshness policy, revalidation, and the boundary between shared HTML and personalized regions must be explicit.
Islands / partial hydration
Ships useful HTML quickly and hydrates only the interactive regions.
Best fit
Content-heavy pages, landing pages, and reference material with a few interactive blocks.
Cost to manage
Widget boundaries, data exchange, and client-side island diagnostics require discipline.
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
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.