SSR, SSG, or ISR: Choosing a Rendering Strategy at Enterprise Scale

We get asked to weigh in on "SSR vs. SSG vs. ISR" more than almost any other architecture question, and it's usually framed as a framework or performance decision. It isn't, mostly. At enterprise scale the decision is governed by two things: how often the underlying data actually changes, and how much operational complexity you're willing to carry to keep cached output correct. Get those two answers right and the rendering strategy falls out on its own.

Start from data volatility, not page templates

The mistake we see most is choosing a rendering strategy per route type — "marketing pages are SSG, dashboards are SSR" — without checking whether that maps to the actual write frequency of the underlying data. A pricing page that changes twice a year is a perfect static-generation candidate regardless of how it's templated. A "static-looking" product catalog page backed by real-time inventory is not, even though it looks identical to the pricing page in the router. We profile write frequency per data dependency, not per route, before recommending a strategy — a single page can legitimately mix a statically generated shell with a server-rendered fragment for the volatile part.

ISR is a caching strategy wearing a rendering costume

Incremental static regeneration gets pitched as "the best of both worlds," and at moderate scale it often is. At enterprise scale, the property that matters is what ISR actually is under the hood: a time- or event-based cache invalidation system with a page-render worker attached. That means the real engineering problem is the same one you'd face with any cache — invalidation correctness under concurrent writes, thundering-herd protection when a popular page's cache expires under load, and staleness windows that are acceptable to the business. Teams that adopt ISR without treating it as a caching subsystem end up with silent staleness bugs: a price change that doesn't propagate for eleven minutes because a background revalidation job silently failed and nobody alerts on stale-cache age.

SSR earns its cost only when personalization is real

Server-side rendering on every request is the most operationally expensive of the three — it puts your origin compute directly in the request path for every user, which means your rendering tier now has the same availability and scaling requirements as your core API. We only recommend full SSR when the page is genuinely personalized per request — authenticated dashboards, per-account pricing, entitlement-gated content — where caching a shared response isn't even a valid option. If the personalization is limited to a header, a greeting, or an account name, that's a client-side hydration problem, not a rendering-strategy problem, and forcing it into SSR just moves latency into your critical path for no benefit.

The invalidation plan is the actual deliverable

Whichever strategy you choose, the artifact that determines whether it works in production isn't the render mode — it's the invalidation plan: which events trigger a rebuild or a purge, how you handle a purge storm when an upstream system replays a backlog of events, and what your fallback behavior is when regeneration fails. We write this plan before touching the rendering config, because a rendering strategy without an invalidation plan is a promise to eventually serve stale data to a customer at the worst possible moment — usually a pricing error, which is the one class of staleness bug that shows up in a support ticket.

A rule of thumb that holds up

If you can articulate, in one sentence, the maximum acceptable staleness window for a given page's data, you're ready to pick a rendering strategy for it. If you can't, that's the actual work — go find out how fresh the data needs to be before you touch the render config.