Rendering Strategy
Rendering strategy shapes frontend performance and resilience — approaches should match user and product needs.
01 — Purpose
Rendering as a product decision
Rendering strategy shapes frontend performance and resilience — approaches should match user and product needs.
Static, server, client, and hybrid models each trade speed, dynamism, cost, and complexity. The right strategy is per route — not one framework default for the entire product.
See static vs SSR vs CSR for a detailed comparison and islands architecture for hybrid interactivity.
02 — Principles
Rendering decisions should improve user experience first
Minimise unnecessary JS, prioritise meaningful content, progressively enhance.
- static rendering — pre-built HTML, CDN delivery, maximum resilience
- server rendering — fresh HTML per request for dynamic or personalised pages
- client rendering — dense interactive apps where client state dominates
- hybrid rendering — static or SSR shell plus hydrated islands
03 — Practice
Choosing and combining approaches
Match rendering to content freshness, personalisation, and interactivity.
- map routes to models — marketing static, account SSR, app shell CSR
- minimise unnecessary JS — see JavaScript cost and progressive enhancement strategy
- prioritise meaningful content in first HTML — not loading spinners
- use progressive hydration — see progressive hydration for deferring non-critical widgets
- measure TTFB and LCP per strategy — see TTFB and backend impact
04 — Avoid
Rendering mismatches
Over-engineering simple experiences and hydration-heavy architectures waste users’ time.
- over-engineering simple experiences — SPA for a brochure site
- hydration-heavy architectures unnecessarily — full React tree for static prose
- one-size-fits-all — same rendering for docs and real-time dashboard
- choosing by trend — CSR because the team knows React, not because users need it
- ignoring resilience — blank page when JS fails on content that could be static
05 — Close
Hybrid is usually the answer
Static or SSR for content; islands for interaction — not a binary choice.
Revisit rendering decisions when product requirements change — new personalisation, new real-time features, or new content types. Update the route map, not just the framework version.
See static vs SSR vs CSR, islands architecture, and performance budgets.