Static Site Generation vs Server-Side Rendering: Which Should You Choose?
Building pages ahead of time versus on each request: how the choice affects speed, freshness, hosting, scalability and cost.
Quick answer
Static site generation builds pages ahead of time and serves them as files, which makes them fast, cheap to host and resilient under traffic, but less suited to data that changes per visitor or by the second. Server-side rendering builds pages on each request, which keeps them current and personalized, at the cost of server work and infrastructure. Use static generation for content that changes on publish, request-time rendering for personalized or real-time content, and incremental regeneration to bridge the two.
When Rendering Happens
Both approaches produce full HTML on the server side, so both are SEO-friendly. The difference is timing: static generation renders once, ahead of time; server-side rendering renders per request. If you're weighing browser versus server rendering instead, see SSR vs CSR.
Comparison
| Factor | Static site generation | Server-side rendering |
|---|---|---|
| When HTML is built | At build or publish time | On every request |
| Speed | Fastest; served from CDN cache | Fast with caching; work per request |
| Freshness | As fresh as the last build or regeneration | Always current |
| Personalization | Not in the HTML itself | Built in |
| Hosting | Static files and a CDN | Compute that scales with traffic |
| Traffic spikes | Handled easily | Needs capacity or caching |
| Large sites | Needs incremental regeneration | No build-time penalty |
Dynamic Content
The deciding question is how content changes. Blog posts, service pages and documentation change when someone publishes, which suits static generation. Prices, inventory, account data and carts change constantly or differ per visitor, which needs request-time rendering or client-side fetching.
Incremental Approaches
Incremental regeneration lets a site keep static speed while updating pages after a publish or on a schedule, without rebuilding everything. Frameworks increasingly blur the line further: current Next.js can prerender a static shell for a page and stream dynamic sections into it on request. The Next.js guide explains that model.
Choosing a rendering strategy for a new site?
ZSpace maps each type of page to the rendering approach that fits it, rather than forcing one model across the whole site.
Hosting, Scalability and Cost
Static pages are cheap to serve and handle sudden traffic well, since a CDN absorbs the load. Server rendering needs compute capacity that grows with traffic, so caching becomes important for cost and resilience. See scalable website architecture for how caching fits the bigger picture.
Business Use Cases
- Marketing sites, blogs, documentation: static generation
- Large content catalogs updated regularly: static with incremental regeneration
- Product pages with live stock or pricing: static shell with dynamic sections, or SSR
- Account areas and dashboards: request-time or client-side rendering
- Search results and filtered listings: request-time rendering with caching
Want your site both fast and current?
Talk to ZSpace about combining static and dynamic rendering for your content.
Conclusion
Static generation wins on speed, cost and resilience for content that changes on publish. Server-side rendering wins when content must be current or personal. Most sites benefit from using both, page by page, with incremental regeneration filling the gap.
Common questions
Building a site's pages into HTML files ahead of time, usually during deployment, so they can be served instantly from a CDN without any work on each request.