When a framework like Next.js, Nuxt or SvelteKit asks you how you want to render a page, your answer is not purely technical. It defines how fast your system responds, how fresh the information is, and — more important than it looks — how the user perceives what they see.
There are three main strategies. Understanding them properly saves you from picking the wrong one.
SSR — Server-Side Rendering
With SSR, every request generates the HTML on the server right then. The user asks for the page, the server fetches the data, builds the HTML, and returns it.
What it gives the user: fresh, personalized information. If your app shows account data, real-time prices, or session-based content, SSR is the only strategy that can do it correctly.
What it costs the system: every request consumes server resources. Under heavy traffic, latency grows. Availability depends on the server responding well — if it is slow, the page is slow.
What it is for: user dashboards, ecommerce with dynamic pricing, personalized content feeds, anything where the data changes between one user and the next or between one request and the next.
SSG — Static Site Generation
With SSG, the HTML is generated once, at build time, and served as a static file from a CDN. There is no server to process per request — the file already exists.
What it gives the user: extreme speed. A file served from a CDN close to the user is as fast as a web page gets. No server latency, no database queried in real time.
What it costs the system: the data is frozen at build time. If something changes, you have to rebuild and deploy for the change to show up. On sites with highly dynamic content, that is unmanageable.
What it is for: landing pages, documentation, blogs, marketing sites, anything where the content changes rarely and load speed matters a lot.
ISR — Incremental Static Regeneration
ISR is the middle ground: pages are generated statically, but with a revalidation window. After a certain amount of time, the next request triggers a regeneration in the background. The current user still sees the cached version; the next one already sees the new one.
What it gives the user: nearly the same speed as SSG, with data that refreshes periodically without full rebuilds.
What it costs the system: it is harder to reason about. At some point the user is going to see data that is a few minutes stale. For most cases that is fine; for critical data (stock levels, real-time prices), it is not.
What it is for: ecommerce product pages, content listings, anything that changes but not every second — and where you can tolerate a window of eventual consistency.
How to compare them
| SSR | SSG | ISR | |
|---|---|---|---|
| Response speed | Depends on the server | Very high (CDN) | High (CDN + revalidation) |
| Data freshness | Always current | Frozen at build | Periodically current |
| Personalization | Yes | No | Limited |
| Operational complexity | High | Low | Medium |
| Ideal for | Dynamic, personalized data | Static content | Semi-dynamic content |
The question that settles everything
Before you choose, one single question: does the data on this page change between one user and the next, or between one request and the next?
If the answer is yes — SSR. If the answer is no, but it changes every so often — ISR with a sensible revalidation window. If the answer is no, or almost never — SSG, served from the CDN closest to your users.
Most real applications need all three strategies on different routes. The home page can be SSG. Product pages, ISR. The user dashboard, SSR. Modern frameworks let you mix them per route for exactly this reason — they do not force you to pick one for the whole site.
The most common mistake is defaulting to SSR because "that way I always have fresh data", without considering that every request that could have been static is burning server resources for nothing. The second most common mistake is defaulting to SSG because "it is faster", then finding out in production that the prices or stock the site is showing are three hours old.
The right choice is not the most sophisticated one — it is the one that gives the user what they need with the least operational complexity.