Side by side
SSGvsSSR
What is the difference between SSG and SSR?
Updated 2 min read7 differences
In short
SSG builds each page into HTML once, at build time, and serves the same file to everyone, while SSR builds the HTML on every request, so it can show fresh data.
SSG
Static Site Generation
SSG is a technique that renders a website's pages to plain HTML files at build time, so servers or CDNs can deliver them instantly without extra work.
Read the page on SSGSSR
Server-Side Rendering
SSR is a technique where the server builds the full HTML for a page on each request, so users and search engines receive ready-to-read content immediately.
Read the page on SSRSSG and SSR compared
| Aspect | SSG | SSR |
|---|---|---|
| When HTML is built | Once, at build time | On every request, at request time |
| Speed | Very fast: prebuilt files served from a CDN | Depends on server work and data fetching per request |
| Freshness | Content is as old as the last build | Content can be current on every request |
| Personalization | Same HTML for every visitor | Can vary by user, cookie, location or query |
| Infrastructure | Static hosting or a CDN; no running server | A server or serverless function runs for each request |
| Build time | Grows with the number of pages | Stays short; the work happens at runtime |
| Best for | Blogs, documentation, marketing pages and glossaries | Dashboards, carts, search results and user-specific pages |
The difference, explained
Static site generation (SSG) runs your page code ahead of time, during the build, and saves the output as plain HTML files. Server-side rendering (SSR) runs the same kind of code on a server at the moment a request arrives, producing HTML just for that request.
The difference is timing, and it creates a trade-off between speed and freshness. Static files can be served from a CDN in milliseconds with almost no server cost, but they change only when you rebuild. SSR can read cookies, the current user and live data on every request, at the cost of running a server and doing that work each time.
Many sites use both. Marketing pages and documentation are generated statically, while account pages and shopping carts are server-rendered. Incremental approaches, often called incremental static regeneration (ISR) or revalidation, sit in between: pages are static but rebuilt in the background after a set time or when their data changes.
A common misconception is that static sites cannot be dynamic. A statically generated page can still run JavaScript in the browser to fetch live data, such as comments or stock levels; only the initial HTML is fixed at build time.
Which one should you use?
Choose SSG when…
- Content changes rarely, or only when you publish.
- Every visitor should see the same page.
- You want the fastest load times and the cheapest hosting.
Choose SSR when…
- Pages depend on who is logged in.
- Data changes constantly, like prices, stock or search results.
- There are too many possible pages to build ahead of time.
Readers ask
Is SSG faster than SSR?
Usually, yes, for the first response. A static file is already built and can be cached close to the user, while SSR must run code and often query data before it can respond.
What is ISR?
Incremental static regeneration serves a static page but rebuilds it in the background after a set interval or on demand, combining the speed of SSG with fresher content.
Can one site use both SSG and SSR?
Yes. Most modern frameworks let you choose the rendering mode per page, so static and server-rendered pages can live in the same project.