ISR vs SSR vs SSG — Ecommerce Rendering Strategy 2026
ISR vs SSR vs SSG is the rendering decision behind every headless store. A clear decision rule for which strategy fits product pages, carts, content and search.
ISR vs SSR vs SSG is the rendering-strategy decision at the heart of every headless commerce build, and getting it wrong is the most common cause of either stale prices or slow stores. The honest answer to ISR vs SSR vs SSG is that no single mode is right for a whole store — the strongest stores apply different rendering per route. This guide gives you the decision rule for choosing correctly page by page.
Search intent: comparison and decision — developers choosing how to render each part of a headless storefront. We define ISR vs SSR vs SSG precisely, map each to the right route type, give a one-line decision rule, and cover the hybrid approach real stores use. This builds on edge rendering (where the rendering runs) and feeds CDN architecture (how the output is cached).
ISR vs SSR vs SSG: What Each Mode Means
In the ISR vs SSR vs SSG trio: SSG (Static Site Generation) builds HTML once at deploy time and serves it from the CDN — fastest possible, but stale until the next build. SSR (Server-Side Rendering) generates HTML fresh on every request at the server or edge — always current, higher compute cost per view. ISR (Incremental Static Regeneration) is the hybrid: serve static HTML like SSG, but revalidate and rebuild individual pages in the background on a timer or on-demand — near-static speed with controllable freshness. Understanding ISR vs SSR vs SSG as a freshness-versus-cost spectrum is the key to choosing.
ISR vs SSR vs SSG: Mapping Modes to Store Routes
The ISR vs SSR vs SSG decision becomes simple when you map by how often data changes and whether it varies per user. Static content (about, blog, evergreen landing pages) → SSG: build once, never stale. Product and category pages where prices change periodically → ISR: static speed with a 60-second-to-hourly revalidation window. Cart, checkout, account and live search results → SSR: must be fresh and per-user on every request. The decision rule for ISR vs SSR vs SSG: does the data change per user? SSR. Per time window? ISR. Rarely? SSG.
| Route type | Strategy | Why |
|---|---|---|
| About, blog, landing | SSG | Content rarely changes — build once |
| Product, category | ISR | Periodic price/stock change — revalidate |
| Cart, checkout, account | SSR | Per-user, must be live every request |
| Search results | SSR | Query-dependent, always fresh |
| Whole store | Hybrid | Mix per route — never one global mode |
ISR vs SSR vs SSG: The Hybrid Approach and Common Mistakes
Real stores never pick one mode globally — the right ISR vs SSR vs SSG answer is hybrid, with rendering chosen per route. Next.js, Astro and Nuxt all support this: prerender static routes, set ISR revalidation on catalogue routes, and force SSR on cart and account. The most common mistake in ISR vs SSR vs SSG is over-using SSR — rendering everything server-side because it is “always fresh”, then paying compute cost and latency on pages that could be ISR or SSG. The second mistake is SSG-ing product pages and shipping stale prices. Match the mode to the data, route by route. The Next.js rendering documentation details per-route configuration, and our headless commerce team sets the rendering map on every build.
How we set the rendering map on a real headless store
We start by listing every route and labelling its data volatility. Before writing code, we tag each route static, periodic, or per-user. That single exercise produces the rendering map and prevents the “SSR everything” default that quietly doubles hosting cost.
ISR revalidation windows are a business decision, not a technical one. A 60-second window suits flash-sale pricing; an hourly window suits stable catalogues. We set it with the merchant based on how fast a price change must appear, not on a developer’s guess.
The classic bug is stale product pages after a price change. Teams SSG the catalogue for speed, then a price update never reaches the static HTML until the next deploy. ISR with on-demand revalidation (triggered by a price-change webhook) fixes this — static speed, instant freshness when it matters.
Frequently Asked Questions About ISR vs SSR vs SSG
What is the difference between ISR, SSR and SSG?
In the ISR vs SSR vs SSG comparison: SSG builds HTML once at deploy and serves it static (fastest, can go stale). SSR renders fresh on every request (always current, more compute). ISR serves static HTML but revalidates individual pages in the background on a timer or on demand — near-static speed with controllable freshness.
Which rendering strategy is best for ecommerce product pages?
ISR is usually best for product and category pages in the ISR vs SSR vs SSG decision. It gives static-page speed while revalidating in the background so price and stock changes appear within your chosen window. On-demand revalidation triggered by a price-change webhook makes updates near-instant without a full rebuild.
Should I use SSR for the whole store?
No — rendering everything with SSR is the most common ISR vs SSR vs SSG mistake. It pays compute cost and latency on pages that could be ISR or SSG. Reserve SSR for per-user, always-fresh routes like cart, checkout, account and search; use ISR for catalogue and SSG for static content.
What is the decision rule for ISR vs SSR vs SSG?
Ask how the data changes. Does it change per user? Use SSR. Does it change on a time window? Use ISR. Does it rarely change? Use SSG. Applying this rule route by route produces the hybrid rendering map that real ecommerce stores use rather than one global mode.
Can one site use ISR, SSR and SSG together?
Yes — and it should. Next.js, Astro and Nuxt all support per-route rendering, so a single store can SSG its blog, ISR its product pages, and SSR its cart and account. The hybrid approach is the correct answer to ISR vs SSR vs SSG for almost every real store.
Does ISR work with edge rendering?
Yes. ISR and edge rendering complement each other — ISR controls freshness (when a page rebuilds) while edge rendering controls location (where it runs and is cached). Many headless stores serve ISR pages from edge caches, combining controllable freshness with sub-100ms global delivery.
Need a Rendering Strategy for Your Headless Store?
Our team builds the per-route rendering map — SSG, ISR and SSR matched to each page’s data volatility.
