The real question: when is the HTML generated?
Static (SSG — Static Site Generation): every page's HTML is generated once, ahead of time, at build/deploy time. A request for that page simply serves the already-generated file — no computation happens at request time at all.
Dynamic (SSR — Server-Side Rendering, or a traditional server-rendered app): HTML is generated fresh on every request, typically by querying a database or running business logic in response to that specific request, then rendering the result.
This timing difference is the actual root of every other tradeoff between the two approaches — not a stylistic preference, a genuine architectural consequence.
Why static sites are typically faster and cheaper to host
Since a static page's HTML already exists before any request arrives, serving it is just handing over a pre-built file — extremely fast, and cacheable at a CDN edge close to the visitor with no origin server computation needed per request. This is also why static hosting is often cheaper: there's no server-side compute cost per visitor, just file storage and bandwidth, which scales far more cheaply than running a database query and template render for every single page view.
Why dynamic rendering still matters
Static generation has a hard limitation: it can only show what was true at build time. Content that changes per-user (a logged-in dashboard, a shopping cart, personalized recommendations) or that must reflect the absolute latest data on every load (real-time stock prices, live inventory counts) fundamentally needs computation at request time — no amount of pre-building ahead of time can show a value that depends on who's asking or what just changed a moment ago.
| Static (SSG) | Dynamic (SSR) | |
|---|---|---|
| When HTML is generated | Build/deploy time | Every request |
| Speed | Very fast (pre-built, cacheable) | Slower (per-request computation) |
| Content freshness | Only as fresh as the last build | Always current at request time |
| Hosting cost at scale | Low (static file serving) | Higher (server compute per request) |
| Personalized/per-user content | Not natively possible | Native fit |
The hybrid middle ground
Many modern frameworks support mixing both approaches on the same site — static generation for content that rarely changes (blog posts, marketing pages, documentation) and dynamic rendering specifically for pages that genuinely need per-request freshness or personalization (a dashboard, search results, cart contents). This isn't a compromise so much as applying each approach exactly where its tradeoff actually fits, rather than forcing an entire site into one model.
Common mistakes
- Using dynamic rendering for content that never actually changes per-request. This adds unnecessary server compute cost and latency for pages that could be pre-built once and served instantly instead.
- Trying to force genuinely personalized or real-time content into a static build. Static generation has no mechanism for per-user or truly live data — that content needs request-time computation.
- Assuming a site must be entirely one or the other. Most real sites benefit from mixing static and dynamic rendering per page, based on what that specific page's content actually requires.
FAQ
Why are static sites generally faster than dynamic ones?
Because the HTML already exists before a request arrives — serving it requires no per-request computation, unlike a dynamic page that queries a database and renders fresh on every load.
Can a static site ever show personalized, per-user content?
Not natively — static generation produces the same pre-built HTML for everyone; genuinely personalized content requires request-time (dynamic) rendering or client-side data fetching after the static page loads.
Is it normal for a single site to mix static and dynamic pages?
Yes — many modern sites statically generate content that rarely changes (blog posts, marketing pages) while dynamically rendering pages that need per-request freshness or personalization (dashboards, search results).