Next.js4 min read
Next.js caching explained: the four layers and how to control them
Most 'Next.js is showing stale data' bugs are one of four caches doing exactly what it was told. Here is the mental model that makes them predictable.
Use static generation (SSG) for content that changes rarely, incremental static regeneration (ISR) for content that changes on a schedule, server-side rendering (SSR) for per-request personalised content, and client-side rendering (CSR) for data that only matters after interaction. Next.js lets you choose per route, so most real applications use several.
| Strategy | HTML generated | Freshness | Best for |
|---|---|---|---|
| SSG | At build time | Until next deploy | Marketing pages, docs, blog posts |
| ISR | At build, rebuilt in background | Revalidation window | Catalogues, listings, content sites |
| SSR | Per request | Always current | Dashboards, personalised pages, auth-gated views |
| CSR | In the browser | Always current | Post-interaction data, editors, real-time UI |
The trade-off is always the same shape: the closer generation happens to the request, the fresher the content and the more you pay in latency and compute per visitor.
Whenever the page looks the same for every visitor and changes less often than you deploy.
Static pages are served from a CDN edge with no server work. Time to first byte is typically a few dozen milliseconds anywhere in the world, cost is near zero, and there is nothing to fall over under traffic spikes. For marketing sites, documentation and blogs, this should be the default.
The objection we hear is 'but our content changes'. Almost always it changes on the order of hours or days, which is what ISR is for — not a reason to render on every request.
ISR serves the cached page instantly and rebuilds it in the background once the revalidation window expires. Visitors always get a fast response; the content is at most N seconds old. For a product catalogue with 40,000 SKUs, ISR also means you do not rebuild 40,000 pages to change one price.
When the response depends on who is asking. Authenticated dashboards, account pages, region-priced pages, A/B-assigned variants and anything reading cookies or headers must render per request — there is no correct cached version to serve.
The cost is real: every visit runs your server and hits your database. Budget for it. Keep queries to a handful, cache the expensive shared parts at the data layer, and stream the page so the shell arrives before the slow region resolves.
“Static by default, dynamic by evidence. Every route that renders per request should be able to explain why.”
— ROVQIX architecture review checklist
Yes, and it should. Rendering is configured per route segment, so your marketing pages can be static while your dashboard renders per request in the same deployment.
No — SSR produces full HTML and indexes fine. The risk is performance: slow server responses hurt Core Web Vitals, and that does affect rankings indirectly.
It is a model where a static shell is served immediately while dynamic holes stream in within the same response, blending SSG and SSR in one route. It removes much of the either/or from this decision as it matures.
The build output lists every route with its rendering mode. Check it in CI — a route that silently flipped from static to dynamic is a performance regression worth catching before deploy.
Harshal Patel
Founder & Lead Engineer, ROVQIX
Harshal leads engineering at ROVQIX, where he has shipped production Next.js, Node.js and PostgreSQL systems for startups, SaaS teams and ecommerce brands. He writes about the trade-offs behind architecture decisions rather than the framework of the week.
ROVQIXdesigns and builds production web platforms — Next.js front ends, Node.js APIs and the infrastructure behind them. Tell us what you're building and we'll scope it with you.
Most 'Next.js is showing stale data' bugs are one of four caches doing exactly what it was told. Here is the mental model that makes them predictable.
The two Next.js routers are not two syntaxes for the same thing. They are different rendering models, and that difference decides your data fetching, caching and hiring plan.
LCP is not one number, it is four phases. Optimising the wrong one is why so much performance work produces no measurable change.
No spam. Just the occasional case study and craft breakdown.