SSR, ISR and Edge Rendering for Commerce Frontends: the Decision Framework for 2026

Nuxt 3, Next.js 15, and Astro 4 all support four rendering modes today. Which one belongs on which page of your storefront is not an academic question. It determines whether your LCP stays under two seconds, whether Google indexes correctly, and whether your deployment team can push a hotfix on a PDP at 3 am without invalidating the entire site.

This post gives you a concrete decision tree. No framework marketing, no rendering-mode tribalism.

The four modes, quickly

Before the tree: a fast state-of-play in 2026 so we are working with the same terms.

SSR (Server-Side Rendering): Every request produces a fresh HTML response on the server. Data is always current, no CDN warmup required. Cost: server load and per-request latency.

SSG (Static Site Generation): HTML is produced at build time and served as a static file from the CDN. Fastest time-to-first-byte, but build time scales with product count. At 50k+ SKUs, 20+ minute builds are realistic.

ISR (Incremental Static Regeneration): A hybrid approach. Pages are regenerated on demand or after a revalidation interval. The first request after expiry triggers a background rebuild. Nuxt calls this SWR (Stale-While-Revalidate); the logic is equivalent.

Edge Rendering: SSR logic that runs not on a centralized server but on the edge node (Cloudflare Workers, Vercel Edge, Fastly Compute) closest to the user. Latency is minimal, cold-start is near-zero with V8 isolates. Constraint: no Node.js native API, no large npm bundles.

Decision tree by page type

PDP (Product Detail Page)

Product data changes multiple times daily: pricing rules, stock levels, personalized bundles. Static delivery is impractical beyond a few dozen products.

Recommendation: ISR with a short revalidation interval (30-300 seconds) + Edge middleware for personalization

Concrete pattern:

• ISR builds the canonical HTML (price + stock from the last known state)
• Edge middleware injects personalized elements (geo price, loyalty status, A/B variant) without a server round-trip
• Combined TTFB stays below 80 ms from the edge cache

This requires a CDN with edge compute support and a frontend layer that can receive ISR revalidation triggers from the product catalog system. An Agentic Frontend Management Platform makes this trigger configurable without a code deployment.

PLP (Product List Page)

Category pages have less volatile data than PDPs, but faceted filters make SSG impractical: 10 filter dimensions with 20 values each produce billions of possible combinations.

Recommendation: SSR for filterable PLPs, ISR for editorial category landing pages

Filterable PLPs benefit from SSR because every query combination is unique. Server-side catalog queries remain consistent. TTFB runs at 120-300 ms, but a smart edge caching strategy (cache shared query patterns at the CDN) reduces server load significantly.

Editorial category pages (seasonal collections, campaign landing pages) change infrequently and are well suited to ISR with long revalidation intervals.

Checkout

Checkout is security-critical, session-bound, and must always be current. No caching. No static variants.

Recommendation: SSR, server-side, no Edge for business logic

Edge rendering for checkout pages is a well-known trap. V8 isolate constraints mean typical checkout dependencies (session handling, fraud detection SDKs, payment gateway-specific libraries) either do not run or require heavy adaptation. The latency gain rarely justifies the engineering cost.

Checkout stays on SSR. Clean, simple, maintainable. The Performance and Core Web Vitals module can push even SSR pages below 2 s LCP through optimized resource hints and critical CSS inlining, without changing the rendering mode.

CMS pages (landing pages, blog posts, campaign pages)

CMS content changes infrequently and is editorially controlled. No session dependency, no price volatility.

Recommendation: ISR with on-demand revalidation via CMS webhook

The editor publishes in the CMS, the webhook triggers revalidation of the affected slug, the CDN serves the new version. In this setup, build times are irrelevant and you get the TTFB benefits of a static asset.

The Composable Headless Frontend supports this pattern out of the box, including webhook handlers for Hygraph, Contentful, and Storyblok.

Summary table

• Page type | Recommended mode | Revalidate | Edge OK?
• PDP | ISR + Edge middleware | 30-300 s | Yes (personalization only)
• PLP (filterable) | SSR | - | No (query variance)
• PLP (editorial) | ISR | 1-24 h | Yes
• Checkout | SSR | - | No
• CMS page | ISR (on-demand) | Webhook | Yes
• Search results | SSR | - | Possible

Why this decision tree matters more in 2026 than in 2024

Two things have changed:

Edge is mature. Cloudflare Workers, Vercel Edge Functions, and Fastly Compute at Edge significantly reduced their constraints in 2025. V8 isolate warmup is no longer a concern, and ecosystem support for typical frontend dependencies has caught up. What was experimental in 2023 is production-ready today.

Rendering modes have become framework-agnostic. Nuxt 3 (Nitro engine), Next.js 15, and Astro 4 can all mix all four modes within the same application, per route. You no longer need separate deployment infrastructure per mode.

This opens up a new space: rendering strategy as configuration rather than code. An Agentic Frontend Management Platform can adjust a page's rendering mode at runtime without a build deployment. That means a campaign manager can switch a CMS page to SSR for a flash sale window, without a developer ticket. After the sale: back to ISR.

The framework stays the framework. The FMP layer sits above it and turns rendering strategy into an operational decision, not an architectural one.

Nuxt vs. Next.js vs. Astro: which framework for which use case?

A brief, honest take:

Nuxt 3 is the first choice for DACH teams with Vue experience. The Nitro engine is the most flexible deployment abstraction in the market - it deploys the same code on Cloudflare, Vercel, AWS Lambda, and plain Node.js without code changes. For new composable commerce projects in the DACH region, Nuxt 3 + Hygraph + commercetools or Shopify is a proven combination.

Next.js 15 remains the industry-standard choice for React teams. Server Components in App Router make SSR less painful than ever. For teams already in the React/Next ecosystem: no reason to switch.

Astro 4 wins for content-heavy storefronts with limited interactivity. The Islands architecture (only interactive components ship JavaScript) is ideal for landing pages and editorial magazine frontends. For full commerce applications with cart and checkout, Astro is less common in production.

For all three: the rendering decisions above remain identical. Framework choice affects developer experience and ecosystem fit, not the correct architecture answer to the PDP problem.

Developer Docs

For concrete setup details, consult the Developer Docs. Rendering configuration for Nuxt and Next.js, webhook handlers for on-demand revalidation, and Edge middleware patterns are fully documented there.

For the related architecture topic, see: React Server Components in E-Commerce: the architecture shift that actually matters.

Summary

The four rendering modes are not an academic spectrum. They are tools, and each page type in your storefront has a clear first choice:

• PDP: ISR + Edge personalization
• PLP filterable: SSR
• PLP editorial: ISR
• Checkout: SSR, full stop
• CMS pages: ISR on-demand

What changes in 2026: this decision tree no longer has to be fixed forever at the first architecture session. With an FMP layer, rendering strategy becomes a runtime decision. That is the point at which frontend architecture becomes a business advantage, not just a tech selection.