Rendering strategy affects load speed, SEO, server cost, and how "live" your data can be. Choosing the wrong one is a common source of both slow sites and unnecessary infrastructure spend.
The three approaches
| Approach | HTML generated | Best for | Trade-off |
|---|---|---|---|
| Static (SSG) | At build time | Marketing pages, docs, blogs | Content updates need a rebuild or on-demand revalidation |
| Server-side rendering (SSR) | Per request, on the server | Pages needing fresh, personalized, or SEO-critical content | Server compute cost per request; more moving infrastructure |
| Client-side rendering (CSR) | In the browser, after JS loads | Authenticated apps, dashboards, highly interactive tools | Slower first paint; weaker default SEO |
What each one looks like in practice
Static — the server (or CDN) has already produced the HTML file. A visitor request is a file lookup. Fastest possible response, zero per-request computation.
SSR — the server runs your application code on every request, fetches whatever data is needed, and returns finished HTML. The visitor sees content immediately, but the server does work every time.
CSR — the server returns a near-empty HTML shell. The browser downloads JavaScript, runs it, fetches data via API calls, and paints the page. Great for app-like interactivity, weaker for the very first impression.
A decision framework
Does the page need to rank in search or be cited by AI systems?
If yes, lean static or SSR. Don't gamble discoverability on JavaScript execution.
Does the content change per request or per user?
Personalized dashboards, logged-in views, and real-time data favor SSR or CSR over static.
How often does the underlying content change?
Rarely-changing content (docs, marketing pages) is a strong static candidate, even with on-demand revalidation for occasional updates.
What is the interactivity level after load?
Highly interactive, app-like experiences (drag-and-drop, live editors, complex dashboards) are naturally CSR-heavy once the initial shell is in place.
Pros
- +Static: fastest response, cheapest to host, simplest to secure
- +SSR: fresh data on first paint, strong SEO, works without client JS
- +CSR: rich interactivity, less server load per interaction after initial load
Cons
- −Static: content updates require a rebuild or revalidation step
- −SSR: server cost and complexity scale with traffic
- −CSR: weaker first paint and default SEO without extra work
Mixing strategies on one site
Most production sites are not "all SSR" or "all static." A typical split:
- Marketing pages and this resources section: static, rebuilt on publish
- Product pages with pricing or inventory that changes: SSR or static with revalidation
- Authenticated portal or dashboard: CSR, since SEO does not apply and interactivity matters more
Choosing per route, rather than per project, is usually the lazier and more correct answer than picking one strategy for an entire application.
FAQ
FAQ
What is the difference between SSR and CSR?+
SSR (server-side rendering) builds the HTML on the server for every request, so the browser receives a complete page. CSR (client-side rendering) sends a mostly empty HTML shell and builds the page in the browser using JavaScript after it loads.
Is static rendering faster than SSR?+
Usually yes for pages that don't need per-request data, because static HTML is generated once at build time and served directly from a CDN, with no server computation per visit.
Can a single website mix SSR, CSR, and static rendering?+
Yes. Most modern frameworks support rendering different routes differently — static marketing pages, server-rendered product pages, and client-rendered authenticated dashboards inside one codebase.
Related resources
Headless CMS: What It Is, When to Use One, and When Not To
A plain-language explanation of headless CMS architecture, how it differs from traditional CMS platforms, and a practical checklist for deciding if your team actually needs one.
EngineeringWebsite Architecture Explained: Layers, Patterns, and How to Choose One
What website architecture actually means, the layers involved, the main patterns in use today, and a practical framework for picking one based on real constraints.
GuidesWebsite Performance Checklist for Modern Business Sites
A practical performance checklist covering Core Web Vitals, asset strategy, fonts, caching, and what actually moves conversion on marketing and product sites.
Newsletter
Product notes, not noise.
Occasional frameworks on portals, SaaS MVPs, and automation. No agency spam.