SSR vs. SSG vs. ISR in 2026: What the Caching and Cost Data Actually Show

On Vercel's published rate card for ISR reads and writes, an Incremental Static Regeneration write costs ten times as much per operation as an ISR read: $0.004 per 1,000 writes against $0.0004 per 1,000 reads. That ten-to-one spread explains more about when to choose server-side rendering, static generation, or incremental static regeneration than any framework comparison chart does, because it points to the one variable that actually drives cost under ISR: how often a page's content changes, not how many people read it.

How Three Rendering Paths Handle the Same Request Differently

Next.js's own documentation on rendering strategies draws the basic distinction plainly: server-side rendering is pre-rendered at request time rather than at build time, which suits pages that are very dynamic, while incremental static regeneration lets developers update static pages after the site has shipped, on a per-page basis, without a full rebuild, so that a site can keep the benefits of static output while scaling to a very large number of pages. Static generation is the simplest of the three: the HTML is produced once, during the build, and served as a plain file from then on.

Vercel's account of how ISR actually serves a request is more granular than "update pages without redeploying." A request that lands on a CDN region where the page is already cached is served immediately, and the origin function does not run at all. Only a cache miss gets forwarded to the origin, where Vercel checks a separate, durable ISR store before invoking a function; if even that store is empty, the function runs and the result is written back to both layers. Revalidation itself runs in the background, whether triggered by a timer or an on-demand call: visitors keep receiving the cached page while the new version renders, and once it's ready Vercel purges every CDN region within roughly 300 milliseconds. The diagram below traces what happens to a single request under each of the three strategies.

Why an ISR Write Costs Ten Times More Than an ISR Read

Vercel's public limits page lists ISR reads at $0.0004 per 1,000 operations and ISR writes at $0.004 per 1,000 operations, a spread of exactly ten to one. A read happens whenever the CDN has to fall back to the durable ISR store instead of serving straight from the edge. A write happens whenever a page's content actually changes, whether through a timed revalidation window or an on-demand call. Because a CDN cache hit skips both the function and the ISR store entirely, a page that gets read a million times but revalidated once a day accumulates almost no metered ISR cost beyond that single daily write. A page that is read rarely but revalidated every few seconds accumulates write cost regardless of how few visitors ever see the result.

That is the tradeoff neither pricing page nor mechanism page states directly on its own: the meter that governs ISR cost is revalidation frequency, largely independent of traffic, which runs against the instinct that a busier page should cost more to keep current. A short revalidate window on a low-traffic page can outcost a long window on a high-traffic one. In Next.js's App Router, that window is set per route, commonly with a line as simple as export const revalidate = 60; inside the route segment, which tells the platform how often to attempt a background write rather than how often visitors are expected to arrive.

What Google's 2026 Field Data Says About Server Response Time

web.dev's guide to Time to First Byte defines TTFB as the interval between a browser starting to navigate to a page and the first byte of the response beginning to arrive, and recommends that most sites keep it at 0.8 seconds or less at the 75th percentile, because TTFB precedes every other loading metric a visitor experiences. The guidance is careful to add a real qualifier: TTFB is not itself one of the three Core Web Vitals, and the 0.8-second figure is a rough guide rather than a pass-fail line, since a server-rendered page doing more work per request can still post a better Largest Contentful Paint than a page that ships quickly but leaves the browser to render everything afterward with JavaScript. That distinction matters for this comparison specifically, because it means a slower SSR response is not automatically a worse user experience than a faster SSG or ISR response, only a different budget to manage.

The most recent Chrome UX Report dataset, covering May 2026 activity and published by the Chrome team on June 9, 2026, found that 68.6% of measured origins had a good Largest Contentful Paint, 81.3% had a good Cumulative Layout Shift, and 86.6% had a good Interaction to Next Paint, with 55.9% of origins passing all three at once. These figures describe the entire measured web, not a controlled comparison isolating SSR from SSG from ISR. CrUX reports by origin, not by rendering strategy, so the dataset cannot say how much of the gap between a passing and a failing origin comes from the rendering choice itself rather than image weight, third-party scripts, or hosting region. What it does establish is the size of the remaining gap: even after years of tooling built specifically around Largest Contentful Paint, close to a third of origins still miss it.

What CrUX's Origin-Level Averages Can't Tell You About One Route's Rendering Choice

Next.js's own framing of the decision treats it as a per-page one rather than an app-wide setting: server-side rendering fits pages that are very dynamic, static generation fits pages that don't need to be rebuilt on every visit, and incremental static regeneration exists specifically so a site doesn't have to choose one mode for every page it serves. Because CrUX only reports an origin's aggregate field data, a team cannot read the May 2026 figures above and conclude which of its own routes need to change, or whether a slow route is even the one dragging the origin's average down. The only way to know whether a specific route's TTFB sits inside web.dev's 0.8-second guide is to measure that route with the same class of field tool CrUX itself draws from, and then decide its rendering strategy, and its place on Vercel's revalidation-frequency cost curve, one route at a time rather than by adopting a single platform default for the whole site.