Every page a browser shows had to be assembled somewhere: either ahead of time, at build (static generation), or on demand, when the visitor asks for it (server rendering). This one decision shapes your hosting costs, your page speed, your SEO, and how fresh your content can be. Here's how to make it — with the trade-offs stated plainly, and with what we chose for our own site and why.
The two models in one paragraph each
Static generation (SSG): every page is pre-built into plain HTML, CSS, and JavaScript files at build time. Visitors receive ready-made files from a server or CDN — no computation happens per request. The site is as fast as files can be delivered, which is very fast, and there is almost nothing to hack, crash, or scale.
Server-side rendering (SSR): pages are assembled per request by a running server. The visitor asks for a page, the server fetches the relevant data, renders HTML, and responds. Content is always current to the second, and pages can differ per user — but you now operate a server, and every request costs computation.
The comparison that actually matters
| Factor | Static (SSG) | Server-rendered (SSR) |
|---|---|---|
| Speed | Fastest possible — pre-built files from CDN | Fast, but adds server processing per request |
| Content freshness | Updates require a rebuild (minutes) | Real-time, always current |
| Personalisation | Same page for everyone (client-side JS for the rest) | Per-user pages, natively |
| Hosting cost | Minimal — any static host or CDN | Server or serverless compute, scales with traffic |
| Reliability | Nearly nothing to break | Server is a failure point to monitor |
| Security surface | Files only — no runtime to exploit | Running application to patch and protect |
| SEO | Excellent — instant, complete HTML for crawlers | Excellent — complete HTML, slightly slower TTFB |
SEO: mostly a tie, with one nuance
Both approaches serve complete HTML to crawlers, which is what matters — the SEO problem child is client-only rendering (a bare React SPA), not SSR or SSG. The nuance: Core Web Vitals are part of ranking, and static files from a CDN reliably deliver better time-to-first-byte than per-request rendering. It's a small edge, but in competitive niches small edges are the game. This applies equally to AI crawlers like GPTBot and ClaudeBot: fast, complete, structured HTML is the easiest content for them to ingest and cite.
Choose static when…
- Content changes on a human schedule — daily, weekly, monthly — rather than every second. Marketing sites, portfolios, blogs, documentation, landing pages.
- Every visitor sees essentially the same pages. No per-user dashboards on the public site.
- Performance and uptime matter more than instant content updates. A static site survives traffic spikes that would require serious infrastructure work on a server-rendered one.
- You want minimal hosting cost and maintenance. Static files run on the cheapest hosting tier that exists and don't need patching.
Choose server-rendered when…
- Content must be current to the second — live inventory and pricing, search results, availability calendars, news that can't wait for a rebuild.
- Pages are personalised — logged-in dashboards, recommendations, carts, anything that differs per visitor at the HTML level.
- You have too many pages to pre-build — a marketplace with a million listings can't rebuild the world on every change.
- Content comes from user actions — reviews, comments, and listings that should appear immediately, not after the next deployment.
The hybrid reality (and why we use Next.js)
This is rarely an either/or decision at the product level. A typical SaaS product wants static marketing pages and a blog (speed, SEO, zero maintenance) plus a server-rendered application behind login (personalised, real-time). Modern frameworks make that split natural: Next.js lets you decide per page — pre-render this one at build, render that one per request — inside one codebase. There's also a middle path, incremental static regeneration, where static pages quietly re-generate themselves on an interval, giving near-fresh content at static speed.
What we chose for our own site
webaholic.studio is fully static: Next.js with output: 'export', pre-rendered to plain HTML at build time, served by Apache with long-lived caching. No Node server runs in production. The result is a 100/100/100/100 PageSpeed score — 0.9s first contentful paint on mobile, zero layout shift, zero blocking time. Our content changes when we publish work or articles, which is a rebuild-and-deploy, not a real-time event. Static was the honest fit — and the same reasoning applies to most agency, portfolio, and marketing sites.
Frequently asked questions
Is a static site really faster in practice?
Yes, measurably. A pre-built HTML file served from a CDN typically starts arriving in tens of milliseconds; a server-rendered page adds data fetching and rendering time per request — often 100–500ms before the first byte. Users feel that difference, and Core Web Vitals record it.
Can a static site have dynamic features like forms and search?
Yes. 'Static' describes how pages are delivered, not what they can do. Forms post to a small endpoint or service, search can run entirely in the browser for moderate content volumes, and any interactive component works normally — it's JavaScript either way. Our own contact form runs on a static site via a single small PHP endpoint.
How often can I update a static site?
As often as you can rebuild — and builds take one to three minutes for a typical site. With a CMS wired to trigger rebuilds automatically, editors publish normally and never know the site is static. What you can't do is show content that changes per second; for that, you need server rendering on those specific pages.
Which is cheaper to run?
Static, by a wide margin. Static files run on shared hosting, free CDN tiers, or object storage for a few euros a month regardless of traffic spikes. Server rendering means paying for compute that scales with every request — modest at small scale, but it grows with success and needs monitoring either way.
Last updated: 28 July 2026