Gavin Grant

Every new project starts with the same decision: how should this thing render?

 (ISR). Static performance and fresh content? Done. It wasn't until I started digging into why certain projects felt harder to maintain than they should that the answer kept pointing back to the same place.

Here's what I found: ISR is a genuinely good tool, but for a specific, well-defined problem. The frontend community has quietly drifted into treating it as a sensible default for almost everything. That drift has a real cost. Developers who reach for ISR out of habit end up managing complexity they didn't sign up for, serving content that's wrong in ways that matter, or both.

If you've ever picked ISR because it felt like the safe choice, this post is for you. Let's talk about why the obvious answer isn't always the right one.

First, let's give credit where it's due. ISR solved a real problem. Before a stable version of ISR was introduced in 2020, as part of 

, you basically had two choices. You could go fully static or server-side rendered. 

 is fast, cheap, globally distributed, but rebuilding your entire site every time a piece of content changed didn't scale. A site with 100,000 pages and a frequently updating CMS simply can't rebuild on demand.

 gave you fresh content on every request but came with real operational overhead: servers to maintain, cold start latency, infrastructure that scaled with traffic load.

ISR threaded that needle neatly. Pre-render your pages at build time, serve them as static assets, but revalidate individual pages in the background when they go stale. The first visitor after a page expires triggers a background regeneration; everyone else gets a fast cached response. No full rebuilds, no live servers per request.

For content sites, marketing pages, and documentation, this is an elegant solution. ISR handles moderate traffic, acceptable staleness, simple page relationships very well, and it does feel like the best of both worlds.

The problem isn't that ISR is bad. It's that "the best of both worlds" framing hides four failure modes that don't show up until you're already committed.

 expires, the next request gets the stale page while a background regeneration fires. Clean in theory, but messier in practice.

CDN edge nodes don't coordinate with each other. When a cached page expires simultaneously across dozens of edge nodes, which is what happens when you set a global TTL, each one independently fires its own regeneration request against your data layer at the same instant. Under heavy traffic, that's not one background regeneration.

And this problem scales with your traffic. Infrastructure that was supposed to handle growth gracefully punishes you for being successful. You can mitigate this with staggered TTLs and origin request coalescing (merging multiple identical, concurrent requests into a single call to the server), but now you're solving a problem that wouldn't exist with a different strategy.

ISR revalidates pages. Your content model has 

A product price changes. You revalidate the product page, but what about the category page showing that price? The search results? The homepage feature? Each of those is stale too, but ISR doesn't know that. It operates on pages in isolation.

Keeping a content graph consistent means mapping every relationship between entities and pages, then triggering coordinated revalidation whenever anything changes. What you've quietly built is a 

 living in your application layer. Cache invalidation is famously one of the 

 in computer science. ISR doesn't solve it. It gifts it to you.

Failure Mode 3: The Hidden Staleness Assumption

This one doesn't fail loudly. It fails slowly, in decisions that were never consciously made.

ISR implicitly assumes serving slightly stale content is acceptable. For a blog post, like the fascinating one you're reading now, 60 seconds out of date is fine. But this assumption gets smuggled into places where it really shouldn't be: inventory levels, flash sale pricing, personalized content, anything with legal or compliance implications.

The danger isn't choosing stale and being wrong about it. It's never choosing at all. You may be letting the framework default make a product decision on your behalf. You find out there's a problem when a customer screenshots a price that no longer exists.

Bounded staleness is a product decision. It should be made deliberately, not inherited from a TTL setting.

Failure Mode 4: On-Demand Revalidation Complexity

The natural response to failure modes 2 and 3 is: switch to on-demand revalidation. Trigger cache clears from your CMS when content changes instead of waiting for a timer.

But here's what it actually requires: a webhook or event system for every relevant content change, a mapping layer translating changes to affected pages, retry and failure handling, revalidation lag monitoring, and cache purging logic for when things go wrong.

You've built a distributed, event-driven cache invalidation system. It's worth asking honestly: is this simpler than just running an SSR server? For many projects, the answer is no. The complexity isn't just architectural — it's financial.

On Vercel, each page regeneration is a separate function invocation billed for 

. A single CMS publish touching 50 related pages fires 50 billable regenerations. I've seen this become a surprise cost line for projects that chose ISR specifically because it seemed like the leaner option.

The Reframe: Complexity Deferred, Not Eliminated

Here's the mental model worth holding onto: 

ISR doesn't eliminate the complexity of serving dynamic content. It defers it.

It's deferred out of your server infrastructure and into your revalidation logic, CDN configuration, and data consistency model.

For the right use case, that's a good trade. For the wrong one, you've paid the full complexity cost without getting the benefit of SSG's simplicity or SSR's consistency guarantees. You're stuck in an awkward middle with a complex caching system that still can't guarantee users see current data.

I'm not saying to avoid ISR. I'm saying choose it consciously while understanding what you're trading.

ISR earns its place when all five of these conditions are genuinely true. If you're not sure, answer the questions in the flowchart below:

Content changes predictably, not event-driven.

 Blog posts, docs, marketing pages, not inventory or pricing tied to real-world events.

Staleness has no material business consequence.

 A conscious decision, not an assumption.

 Revalidating one page doesn't cascade into a dozen others.

 If your site has 500 pages and builds in 30 seconds, just use SSG.

Traffic is distributed, not concentrated.

 Spiky traffic to a small set of high-TTL pages is thundering herd territory.

If any condition fails, here's where to land instead:

The hybrid case is the right answer for most serious production apps. The goal isn't to pick one strategy. It's to identify the 

. ISR can be exactly right for your marketing pages and exactly wrong for your product pages. Both things can be true.

One more thing worth naming: framework docs aren't neutral architectural advice. The teams building these features have an incentive to make them look appealing. That doesn't mean ISR is wrong for your use case. It just means you should make that call yourself.

ISR is a useful lens for a pattern that shows up everywhere in software: 

framework defaults defer complexity rather than eliminate it.

 Defaults optimized for the median use case will work fine for most projects and quietly fail some.

The right instinct isn't to become a paranoid engineer distrusting all defaults. Most of the time they're reasonable starting points. The right move is to pause before applying one at scale and ask: 

What complexity is this deferring, and am I prepared to own it?

For Incremental Static Regeneration, the answer is often yes with the right use case. But "yes" should be a decision, not an assumption. That's the difference between a rendering strategy that works for you and one you're constantly working around.

Engineering, explained