SSR, ISR und Edge Rendering für Commerce-Frontends: der Entscheidungsrahmen 2026

Nuxt 3, Next.js 15 und Astro 4 bieten heute vier Rendering-Modi an. Welcher davon für welche Seite deines Storefronts richtig ist, ist keine akademische Frage. Sie bestimmt, ob dein LCP unter 2 Sekunden bleibt, ob Google korrekt indexiert und ob dein Deployment-Team um 3 Uhr morgens einen Hotfix auf einer PDP ausrollen kann, ohne die ganze Site zu invalidieren.

Dieser Post gibt dir einen konkreten Entscheidungsbaum. Keine Marketing-Prosa, keine Framework-Kriegsführung.

Die vier Modi kurz

Bevor der Baum: ein schneller Stand der Dinge in 2026, damit wir mit denselben Begriffen arbeiten.

SSR (Server-Side Rendering): Jede Anfrage erzeugt eine frische HTML-Antwort auf dem Server. Daten immer aktuell, kein CDN-Warmup nötig. Preis: Server-Load und Latenz pro Request.

SSG (Static Site Generation): HTML wird beim Build erzeugt und als statische Datei auf dem CDN gecacht. Schnellste Time-to-First-Byte, aber Build-Zeit skaliert mit Produktanzahl. Bei 50k+ SKUs realistisch 20+ Minuten Build.

ISR (Incremental Static Regeneration): Hybridansatz. Seiten werden on-demand oder nach einem Revalidate-Intervall neu generiert. Die erste Anfrage nach Ablauf triggert einen Hintergrund-Rebuild. Nuxt nennt das SWR (Stale-While-Revalidate); die Logik ist dieselbe.

Edge Rendering: SSR-Logik, die nicht auf einem zentralisierten Server läuft, sondern auf dem Edge-Node (Cloudflare Workers, Vercel Edge, Fastly Compute) am nächsten beim User. Latenz minimal, Kaltstart praktisch null bei V8-Isolates. Einschränkung: kein Node.js-Native-API, kein großes npm-Bundle.

Der Entscheidungsbaum nach Seiten-Typ

PDP (Product Detail Page)

Produkt-Daten ändern sich mehrmals täglich: Preis-Regeln, Lagerstand, personalisierte Bundles. Statische Auslieferung ist bei mehr als ein paar Dutzend Produkten unrealistisch.

Empfehlung: ISR mit kurzem Revalidate (30-300 Sekunden) + Edge-Middleware für Personalisierung

Konkretes Muster:

• ISR baut das kanonische HTML (Preis + Bestand aus dem letzten bekannten Stand)
• Edge-Middleware injiziert personalisierte Elemente (Geo-Preis, Loyalty-Status, A/B-Variante) ohne Server-Round-Trip
• Der kombinierte TTFB liegt unter 80 ms aus dem Edge-Cache heraus

Was das braucht: ein CDN mit Edge-Compute-Unterstützung und ein Frontend-Layer, der ISR-Revalidate-Trigger aus dem Produktkatalog-System empfangen kann. Eine Agentic Frontend Management Platform macht diesen Trigger konfigurierbar, ohne Code-Deployment.

PLP (Product List Page)

Kategorie-Seiten haben weniger volatile Daten als PDPs, aber Facetten-Filter machen SSG unpraktisch: 10 Filter-Dimensionen mit je 20 Werten ergeben theoretisch Milliarden Kombinationen.

Empfehlung: SSR für filterbare PLPs, ISR für redaktionelle Kategorie-Landingpages

Filterbare PLPs profitieren von SSR, weil jede Query-Kombination einzigartig ist. Server-seitige Datenbankabfragen über den Produktkatalog bleiben konsistent. Der Preis ist TTFB von 120-300 ms, aber eine gute Edge-Cachestrategie (Cache auf dem CDN bei Shared-Query-Mustern) reduziert den Server-Load erheblich.

Redaktionelle Kategorie-Seiten (saisonale Collections, Kampagnen-Landingpages) hingegen ändern sich selten und eignen sich gut für ISR mit langen Revalidate-Intervallen.

Checkout

Checkout ist sicherheitskritisch, session-gebunden und muss immer aktuell sein. Kein Caching. Keine statischen Varianten.

Empfehlung: SSR, serverseitig, kein Edge für Business-Logik

Edge-Rendering für Checkout-Seiten ist eine verbreitete Falle. V8-Isolate-Beschränkungen bedeuten, dass typische Checkout-Dependencies (Session-Handling, Fraud-Detection-SDKs, payment-gateway-spezifische Libraries) nicht laufen oder stark angepasst werden müssen. Der Gewinn durch Latenz-Reduktion rechtfertigt den Engineering-Aufwand selten.

Checkout bleibt auf SSR. Klar, einfach, wartbar. Das Performance- und Core-Web-Vitals-Modul kann auch SSR-Seiten über optimierte Resource-Hints und kritische CSS-Inline-Strategien auf unter 2 s LCP bringen, ohne den Rendering-Modus zu wechseln.

CMS-Seiten (Landingpages, Blog-Posts, Kampagnenseiten)

CMS-Content ändert sich selten und wird redaktionell gesteuert. Keine Session-Abhangigkeit, keine Preis-Volatilitat.

Empfehlung: ISR mit on-demand-Revalidation via CMS-Webhook

Der Redakteur publiziert im CMS, der Webhook triggert eine Revalidation des betroffenen Slugs, das CDN liefert die neue Version. Bei dieser Konstellation sind Build-Zeiten irrelevant, und du hast die TTFB-Vorteile eines statischen Assets.

Das Composable Headless Frontend unterstutzt dieses Muster out of the box - inkl. Webhook-Handler für Hygraph, Contentful und Storyblok.

Zusammenfassung in einer Tabelle

• Seiten-Typ | Empfohlener Modus | Revalidate | Edge OK?
• PDP | ISR + Edge-Middleware | 30-300 s | Ja (nur Personalisierung)
• PLP (filterbar) | SSR | - | Nein (Query-Varianz)
• PLP (redaktionell) | ISR | 1-24 h | Ja
• Checkout | SSR | - | Nein
• CMS-Seite | ISR (on-demand) | Webhook | Ja
• Search-Ergebnis | SSR | - | Möglich

Warum dieser Entscheidungsbaum 2026 wichtiger ist als 2024

Zwei Faktoren haben sich verändert:

Edge ist reif. Cloudflare Workers, Vercel Edge Functions und Fastly Compute at Edge haben 2025 ihre Einschrankungen deutlich reduziert. V8-Isolate-Warmup ist kein Problem mehr, und der Okosystem-Support für typische Frontend-Dependencies hat nachgezogen. Was 2023 noch als Experiment galt, ist heute produktionsreif.

Rendering-Modi sind Framework-unabhängig geworden. Nuxt 3 (Nitro-Engine), Next.js 15 und Astro 4 konnen alle vier Modi in derselben Applikation mischen, pro-Route. Du brauchst keine separate Deployment-Infrastruktur pro Modus mehr.

Das eroffnet einen neuen Raum: Rendering-Strategie als Konfiguration statt als Code. Eine Agentic Frontend Management Platform kann den Rendering-Modus einer Seite zur Laufzeit anpassen, ohne Build-Deployment. Das bedeutet: ein Kampagnen-Manager kann eine CMS-Seite für eine Flash-Sale-Phase auf SSR umschalten, ohne ein Developer-Ticket. Nach dem Sale: zuruck auf ISR.

Dabei bleibt das Framework das Framework. Der FMP-Layer sitzt darüber und macht Rendering-Strategie zur Betriebsentscheidung, nicht zur Architekturentscheidung.

Nuxt vs. Next.js vs. Astro: welches Framework für welchen Use Case?

Kurze, ehrliche Einschatzung:

Nuxt 3 ist die erste Wahl für DACH-Teams mit Vue-Erfahrung. Die Nitro-Engine ist die flexibelste Deployment-Abstraktion im Markt - sie deployed denselben Code auf Cloudflare, Vercel, AWS Lambda und plain Node.js ohne Code-Anderungen. Für neue Composable-Commerce-Projekte in der DACH-Region ist Nuxt 3 + Hygraph + commercetools/Shopify eine bewiesene Kombination.

Next.js 15 bleibt die industriestandard-Wahl für React-Teams. Server Components in App Router machen SSR weniger schmerzhaft als je zuvor. Für Teams, die bereits in React/Next unterwegs sind: kein Wechselgrund.

Astro 4 gewinnt bei content-heavy Storefronts mit wenig Interaktivitat. Die Islands-Architektur (nur die interaktiven Komponenten senden JavaScript) ist ideal für Landingpages und Blog/Magazin-Frontends. Für vollständige Commerce-Applikationen mit Cart/Checkout ist Astro weniger verbreitet.

Für alle drei gilt: die Rendering-Entscheidungen oben bleiben dieselben. Framework-Wahl beeinflusst Developer-Experience und Ecosystem-Fit, nicht die richtige Architektur-Antwort auf das PDP-Problem.

Was Developer Docs dazu sagen

Für das konkrete Setup empfehlen wir, die Developer Docs zu konsultieren. Dort sind die Rendering-Konfiguration für Nuxt und Next.js, die Webhook-Handler für on-demand-Revalidation und die Edge-Middleware-Patterns vollständig dokumentiert.

Den Artikel aus dem Cross-Link-Kontext zum Render-Contract-Thema findest du hier: React Server Components in E-Commerce: the architecture shift that actually matters.

Fazit

Die vier Rendering-Modi sind kein akademisches Spektrum. Sie sind Werkzeuge, und jeder Seiten-Typ in deinem Storefront hat eine klare erste Wahl:

• PDP: ISR + Edge-Personalisierung
• PLP filterbar: SSR
• PLP redaktionell: ISR
• Checkout: SSR, fertig
• CMS-Seiten: ISR on-demand

Was sich 2026 ändert: dieser Entscheidungsbaum muss nicht mehr bei der ersten Architektur-Sitzung für immer fixiert werden. Mit einer FMP-Schicht wird Rendering-Strategie zur Laufzeit-Entscheidung. Das ist der Punkt, an dem Frontend-Architektur zum Business-Vorteil wird, nicht nur zur Tech-Auswahl.