Static Sites vs Server-Side Rendering — The Engineering Trade-off
When a user types your URL and presses Enter, the browser asks a server for HTML. Where that HTML comes from is the architectural decision behind every moder...
Three Ways a Browser Receives HTML
When a user types your URL and presses Enter, the browser asks a server for HTML. Where that HTML comes from is the architectural decision behind every modern web framework. There are three answers in 2026, and each one has different latency profiles, different SEO implications, different operational complexity, and different cost.
The three are:
- Static Site Generation (SSG) — the HTML was built ahead of time and is just a file on disk.
- Server-Side Rendering (SSR) — a server runs code on each request and produces fresh HTML.
- Client-Side Rendering (CSR) — the server sends a near-empty HTML shell and JavaScript fills it in.
Most modern apps actually mix these. Knowing which one applies to which page on your site is the engineering decision that determines whether your site is fast, SEO-friendly, and affordable.
CSR — The Single-Page-App Default
In Client-Side Rendering, the server response to GET /any-url is the same skeleton:
<!DOCTYPE html>
<html>
<head><title>App</title></head>
<body>
<div id="root"></div>
<script src="/app.js"></script>
</body>
</html>
The browser downloads app.js, JavaScript runs, the script fetches data, and React/Vue/Svelte renders the actual page into <div id="root">. The HTML the user sees is constructed in their own browser.
CSR was the default for SPAs in the 2015-2020 era — Create React App, Vue CLI, Angular CLI all defaulted to it. The pattern is simple to deploy (any static host works), simple to develop (one frontend codebase, no server), and simple to reason about (everything is JavaScript).
The downsides become obvious in production:
- First paint is slow. The user stares at white screen until JS downloads, parses, executes, fetches data, and renders. On a slow phone or flaky connection, that is several seconds.
- SEO is poor. Search crawlers used to ignore JavaScript-rendered content. Modern crawlers (Google, Bing) execute JS and see the rendered page, but the indexing happens on a delay and is less reliable than indexing pre-rendered HTML.
- Social previews break. Twitter, LinkedIn, Facebook all read your
<meta>tags from the server response. CSR ships generic meta tags in the shell; the per-page meta is set by JS later. Social cards show the generic ones.
Pure CSR has fallen out of fashion for content sites because of these issues. It still makes sense for logged-in interfaces (where SEO does not matter and the user expects a brief loading state) — Gmail, Figma, Linear, every SaaS dashboard.
SSR — Fresh HTML on Every Request
In Server-Side Rendering, when the server gets a request for /posts/42, it:
- Fetches the post from the database.
- Runs the React/Vue component tree on the server with that data.
- Sends the fully rendered HTML to the browser.
- The browser shows the HTML immediately.
- The same JS bundle then loads and "hydrates" — attaches event listeners to make the page interactive.
The HTML the user sees is constructed on the server, fresh, on every request. This is what Next.js, Nuxt, SvelteKit, and Remix do by default.
The benefits are real:
- Fast first paint. The user sees content immediately, before JS even loads.
- Great SEO. Crawlers see the fully rendered HTML. No JS execution required.
- Per-request data. A logged-in user gets a personalized page; a flag-based experiment can branch on user attributes; pricing can vary by region.
The costs are also real:
- You need a server. A static host (S3, GitHub Pages) is not enough. You need a Node.js (or Deno, Bun, etc.) runtime that runs your framework's SSR code on every request.
- Per-request latency. Each request runs database queries and component rendering. A slow database query becomes a slow page.
- Scaling complexity. A spike of traffic means a spike of server CPU. You need autoscaling, load balancers, and capacity planning.
- Monthly bill. Server CPU costs money even when no one is using the site.
For sites where content is genuinely per-user or per-request (logged-in dashboards with SEO concerns, e-commerce with personalization), SSR is the right call. For sites where content is mostly the same for everyone, paying SSR's costs on every request is wasteful.
SSG — Build the HTML Ahead of Time
In Static Site Generation, the framework runs the same component tree the SSR version would run, but at build time, not at request time. The output is a folder full of HTML files. When a request comes in, the server (or CDN) just serves the matching file. No code runs per request.
This is what Hugo, Jekyll, Astro, and Next.js's output: 'export' mode do. It is also what most production sites end up using for the parts of their site that fit.
The benefits are exceptional:
- Fastest possible response. The HTML is on disk; the CDN serves it from memory at the edge. Every request is a static file from the closest data center.
- Best SEO. Same as SSR — crawlers see fully rendered HTML.
- Cheapest hosting. Static hosts cost cents per month. Cloudflare Pages, Netlify, GitHub Pages — all free for normal use.
- Brutal simplicity. No server, no scaling concerns, no runtime errors, no security surface beyond the static files. Production debugging mostly disappears.
The drawback is the inverse of the benefit: the content is fixed at build time. If your site has 10,000 product pages and the prices change every five minutes, SSG means a build every five minutes — not viable. If your homepage content depends on who is logged in, SSG cannot serve that.
For mostly-static content (blogs, marketing sites, documentation, portfolios, brochure sites), SSG is the right answer almost every time. The site this article is hosted on is SSG via Nuxt — every page in the curriculum and blog is pre-built and served from Cloudflare's edge.
ISR — The Hybrid That Solved Half the Problem
The strict line between SSR and SSG started to blur around 2020 with Incremental Static Regeneration (ISR), introduced by Next.js. The idea: build pages statically the first time, serve them as static files, and re-build them in the background when their data changes or after a configurable expiration.
Concretely:
- Page is requested for the first time → generated and cached as static HTML.
- Subsequent requests within the cache window → served instantly from cache.
- A request after the cache expires → user gets the old version immediately, the page is regenerated in the background, the next user gets the new version.
This is "static-with-fresh-data" and it covers a lot of ground. An e-commerce site with a million products that change occasionally? ISR. A news site with thousands of articles? ISR. The performance of static, the freshness of SSR, with cost in between.
Most modern frameworks support some form of ISR or "revalidation": Next.js, Nuxt, Astro, SvelteKit. The naming varies; the pattern is the same.
Streaming and Server Components — The 2023+ Story
A more recent development worth knowing about: streaming SSR and React Server Components. The shape:
- The server starts sending HTML before the page is fully rendered.
- Pieces of the page that are slow (waiting on a database query) ship later in the same response stream, with placeholders showing first.
- Components marked as "server components" run only on the server, never ship JavaScript to the client, and can access databases directly.
This is the direction Next.js App Router and the Vercel-led part of the React ecosystem has gone. The benefits are real for complex apps — you can have a fast first paint AND data freshness AND smaller JavaScript bundles. The cost is mental overhead — knowing which side of the boundary each component lives on, which lifecycle it follows, what it can and cannot do.
For most teams in 2026, this is the cutting edge but not yet the safe default. The mainstream answer is still: SSG for content, SSR/ISR for personalized parts, CSR only inside logged-in areas.
A Decision Process That Actually Works
When deciding which mode for a new page, run through these questions in this order:
- Is this content the same for everyone? If yes, candidate for SSG.
- Does the content change every few minutes or less? If yes, ISR is probably right; if no (changes once a week or less), pure SSG with a build-on-content-change webhook.
- Is the content per-user or per-request? If yes, SSR or CSR depending on SEO needs.
- Does this page need SEO? If yes, SSR over CSR.
- Is this behind a login wall where SEO is irrelevant? CSR is acceptable, often easier.
Apply this per-page, not per-site. The marketing pages of a SaaS are typically SSG. The signed-in dashboard is typically CSR or SSR. The pricing page might be ISR (because it changes when you update plans). All three modes coexist in one app.
A Concrete Site Mapping
For a fictional SaaS at acme.com, the right architecture might look like:
| URL | Mode | Why |
|---|---|---|
/ | SSG | Marketing copy, same for everyone, changes weekly |
/pricing | SSG | Same as above, rebuilds when plans change |
/blog/* | SSG | Articles are static once published |
/docs/* | SSG | Documentation; rebuild on Git push |
/login | SSG | Static form |
/dashboard | CSR | Logged-in only, SEO irrelevant, JS-heavy |
/dashboard/api | SSR | Per-user data, but crawlers do not care |
/api/* | n/a | Backend endpoints, not pages |
Most of the URLs are static. The high-traffic public pages are the cheapest to serve and the best for SEO. The dynamic parts are isolated to where they actually matter.
Where This Fits
Lesson 10 of the ABCsteps curriculum ships your milestone project. This article gives you the rendering decision before that ship — should this page be static, server-rendered, or client-only? With the modes named and the trade-offs concrete, the answer becomes obvious for each page in your project, and the deployment target (Cloudflare Pages? Vercel? a real server?) follows from those decisions naturally.
Apply this hands-on · Module B
Milestone: Your App Is Online
Lesson 10 ships your milestone project. This article gives you the rendering decision framework before you choose how to deploy.
Open lesson