In short
Static generation (SSG) builds HTML once at deploy time and serves files; it is fastest, cheapest and most crawlable, and suits any page whose content is the same for every visitor. Server-side rendering (SSR) builds HTML per request; it suits pages that are personalised or change constantly and still need to be fast and indexable. Client-side rendering (CSR) sends an empty shell and builds the page in the browser; it suits applications behind a login where SEO is irrelevant. Most sites should be static by default, server-rendered where necessary, and client-rendered only for the interactive parts.
The three strategies
Static site generation (SSG). At build time, a generator turns content into finished HTML files. Visitors receive those files from a CDN. Nothing is computed per request. Updating content means rebuilding, which can be automated on every change.
Server-side rendering (SSR). On each request, a server assembles the page: fetches data, renders HTML, sends it. The visitor receives complete HTML immediately, and a JavaScript bundle may then take over the page for interactivity.
Client-side rendering (CSR). The server sends a minimal HTML shell and a JavaScript bundle. The browser downloads the bundle, runs it, fetches data from APIs, and constructs the page. Until that finishes, the page is blank or a loading spinner.
Each describes where the HTML is produced: at build, on the server per request, or in the browser.
The trade-offs
| SSG | SSR | CSR | |
|---|---|---|---|
| Time to content | Fastest; files from a CDN | Fast; depends on server and data | Slowest; waits for JS and API calls |
| SEO and AI crawlers | Complete HTML, always | Complete HTML, always | Depends on Google rendering; invisible to most AI crawlers |
| Freshness | As of last build | Per request | Per request |
| Personalisation | None at build; via JS after | Full | Full |
| Infrastructure | Static hosting, near-free | A server or serverless runtime | Static hosting plus an API |
| Scaling | Effortless | Server cost grows with traffic | API cost grows with traffic |
| Complexity | Low | Medium to high | Medium; simple server, complex client |
| Failure mode | Stale content | Server down | Blank page |
Where each one fits
Static suits marketing sites, documentation, blogs and articles, portfolios, landing pages, product catalogues that change daily rather than by the second, and anything else where every visitor sees the same page. That is most of the web. Static is also the safest: there is no server to fail or to attack, and hosting costs round to zero. This site is static HTML; its content changes when an article is published and not otherwise.
Server-side suits pages that differ per visitor or per moment: dashboards, search results, carts, feeds, pricing that depends on location, anything behind a login that still needs to be fast on first load, and large catalogues where building every page statically would take hours. It also suits content that must be indexed and changes too often to rebuild.
Client-side suits applications: the interface inside a product after login, editors, tools, anything highly interactive where the first-load delay is acceptable because the user has committed and SEO is irrelevant. It is the wrong choice for anything that needs to be found, because Google renders JavaScript with delays and limits and AI crawlers mostly do not render it at all.
The hybrid reality
Modern frameworks stopped forcing the choice per site. Next.js, Nuxt, SvelteKit, Astro and their peers allow the strategy to be chosen per page or per component:
- Static by default, rendered at build.
- Incremental regeneration, where static pages are rebuilt in the background after a set interval or on demand, giving static speed with near-fresh content.
- Server-rendered for the few pages that need it.
- Islands or partial hydration, where a static page contains small interactive components that load their JavaScript independently, so the page is fast and the widget works.
- Edge rendering, where server rendering happens on a CDN node near the visitor, which narrows the speed gap between SSR and static.
The practical pattern for most sites is therefore: static for everything that can be, server-rendered for what cannot, client-rendered islands for the interactive parts, and a full client-rendered app only for the product behind the login.
A note on cost and failure
The strategies also differ in what happens when things go wrong. A static site under a traffic spike serves more files from the CDN and costs nothing extra; a server-rendered site under the same spike needs more server capacity or it slows and fails; a client-rendered site shifts the load to its API, which fails in the same way. When a deploy contains a bug, a static site serves the previous files until the next build, a server-rendered site errors on every request, and a client-rendered site shows a blank page. These are not reasons to avoid server or client rendering where they are needed, but they are reasons to confine them to the pages that need them.
The decision, page by page
Ask of each page:
- Is the content the same for every visitor? Static.
- Does it change more often than you can rebuild, or depend on who is asking? Server-rendered.
- Is it an interface the visitor uses after logging in, with no need to be indexed? Client-rendered is acceptable; server-rendered first load is still nicer.
- Does it need to be cited by search engines and AI assistants? Then not client-rendered, whatever else is true.
A site that answers those honestly usually ends up mostly static with a small server-rendered surface, which is also the cheapest and most reliable shape. Our overview of modern front-end architecture covers how the pieces fit. If you are choosing for a new build or untangling an existing one, book a call.
Common questions
Which is best for SEO: SSR, CSR or SSG?
Static generation and server-side rendering are equally good, because both deliver complete HTML that every crawler can read immediately. Client-side rendering is the weakest: Google renders it with delays and limits, and most AI crawlers do not execute JavaScript, so the content is invisible to them. Any page that needs to be found should be static or server-rendered.
Is static site generation faster than server-side rendering?
Usually, because static files are served from a CDN with no computation per request, while SSR has to fetch data and render on each visit. Edge rendering and caching narrow the gap. Static is also cheaper and cannot go down under load, which is why it is the default for any page whose content does not vary per visitor.
When should you use client-side rendering?
For applications behind a login, editors, dashboards and highly interactive tools, where the visitor has committed, the first-load delay is acceptable, and search indexing is irrelevant. It is the wrong choice for marketing pages, articles, product pages or anything that must be found or cited.
Can a website use both SSR and SSG?
Yes, and most modern frameworks encourage it. Next.js, Nuxt, SvelteKit and Astro allow the rendering strategy to be set per page: static for content that does not change per visitor, server-rendered for personalised or rapidly changing pages, with incremental regeneration and interactive islands in between.
What is incremental static regeneration?
A hybrid where pages are generated statically but rebuilt in the background after a set interval or when content changes, so visitors get static speed while the content stays close to fresh. It suits large catalogues and frequently updated content that would otherwise need server-side rendering.
