Headless WordPress, ISR oder SSR: den Rendering-Modus nach Änderungsrhythmus wählen
Die Frage “ISR oder SSR” ergibt nur pro Route Sinn. Eine Antwort für die ganze Website gibt es nicht. Astro und Next.js lassen Sie den Modus auf Seiten- oder Layout-Ebene wählen, und erfahrene Entwicklerteams entscheiden bewusst, Route für Route, anhand eines Modells dafür, wie oft sich die Inhalte ändern.
Dieser Artikel gehört zum Leistungsbereich Headless WordPress und ergänzt die Entscheidungsmatrix Next.js oder Astro, die die Wahl auf Framework-Ebene behandelt.
Kurz gesagt
- ISR (oder statisch mit Revalidierung) gewinnt, wenn der Änderungsrhythmus vorhersehbar und der Traffic hoch ist.
- SSR gewinnt, wenn die Seite personalisiert, sitzungsabhängig ist oder Live-Daten enthält.
- Die Korrektheit von ISR hängt an der Cache-Invalidierung; Webhooks schlagen zeitbasierte Revalidierung.
- Cloudflare Workers betreibt beide Modi; ISR kostet kaum CPU, SSR zahlt das volle Rendering.
- Standard ist der günstigste Modus, der korrekte Ergebnisse liefert; auf SSR wechseln Sie nur bei Bedarf.
SSG, ISR und SSR für WordPress erklärt
Statische Seitengenerierung (SSG). Die Seite wird einmal zur Build-Zeit erzeugt und als reines HTML ausgeliefert. Am günstigsten pro Anfrage, am langsamsten bei Aktualisierungen.
Incremental Static Regeneration (ISR). Die Seite wird einmal erzeugt, lässt sich aber durch einen Auslöser neu generieren, meist einen Webhook beim Veröffentlichen oder ein zeitbasiertes Revalidierungsintervall. Günstig pro Anfrage, bei Aktualisierungen letztlich konsistent (eventual consistency).
Server-Side Rendering (SSR). Die Seite wird bei jeder Anfrage gerendert. Immer aktuell, aber die Laufzeitkosten wachsen mit dem Traffic. Personalisierung, Authentifizierung und Live-Daten passen hier ganz natürlich.
In Headless WordPress lesen alle drei Modi über REST oder GraphQL vom WordPress-Origin. Der Unterschied liegt darin, wann sie lesen.
Wann ISR und wann SSR in Headless WordPress
Zwei Faktoren zählen:
Änderungsrhythmus. Wie oft ändert sich diese Seite? Einmal im Quartal, einmal am Tag, jede Minute, in Echtzeit?
Personalisierungsumfang. Unterscheidet sich die Seite je nach Besucher? Login-Status, standortabhängige Preise, Variante eines A/B-Tests.
Die Regel: Wählen Sie den günstigsten Modus, der korrekte Ergebnisse liefert. Statisch ist am günstigsten. SSR am teuersten. Gehen Sie nur dann in Richtung SSR, wenn ein günstigerer Modus nicht korrekt arbeitet.
| Seitentyp | Standardmodus | Warum |
|---|---|---|
| Marketingseiten, Blogbeiträge | Statisch (Rebuild bei Veröffentlichung) | Seltene Änderungen, keine Personalisierung |
| Kategorie- und Tag-Archive | ISR mit Veröffentlichungs-Webhook | Rhythmus folgt der Veröffentlichung |
| Produktseiten, stabiler Katalog | ISR mit Lagerbestands-Webhook | Vorhersehbare Invalidierung |
| Produktseiten, Bestand in Echtzeit | SSR mit Edge-Cache | Bestand ändert sich binnen Sekunden |
| Warenkorb und Checkout | SSR | Per Definition sitzungsabhängig |
| Dashboard nach Login | SSR | Zustand pro Nutzer |
| Redaktionelle Startseite | ISR mit Veröffentlichungs-Webhook | Rhythmus folgt den Veröffentlichungen |
ISR-Cache-Invalidierung mit WordPress-Webhooks
ISR wirkt kostenlos, bis es nach einer Slug-Änderung eine veraltete kanonische URL ausliefert. Das Muster, das dies verhindert:
Webhook-gesteuerte Invalidierung. WordPress sendet einen Webhook beim Veröffentlichen, bei einer Slug-Änderung oder beim Löschen eines Beitrags. Das Frontend-Framework nimmt den Webhook entgegen und stößt die Regenerierung der betroffenen Seiten an. Die Kosten: eine Webhook-Integration am WordPress-Origin, einmalig.
Zeitbasierte Revalidierung nur als Absicherung. Ein Revalidierungsintervall von 60 Sekunden fängt fehlgeschlagene Webhook-Zustellungen ab, sollte aber nicht der primäre Auslöser sein. Eine Seite, die alle 60 Sekunden revalidiert, wird auch 60 Mal pro Stunde neu gebaut; bei einer Website mit 5000 Seiten ist das nicht tragbar.
Cache-Tags statt URLs. Jede gecachte Seite erhält Tags mit der WordPress-Beitrags-ID, den IDs der referenzierten Begriffe und übergreifenden Tags (Startseite, Sitemap). Kommt ein Webhook an, leert das Frontend den Cache nach Tag, nicht nach URL. Das ist der Unterschied zwischen “die Produktseite neu generieren” (fehleranfällig) und “alles neu generieren, was auf Produkt 8421 verweist” (korrekt).
Kosten von ISR und SSR auf Cloudflare Workers
Astro und Next.js kompilieren beide in eine Workers-kompatible Laufzeit. Das Kostenbild nach Modus:
- Statisch am Edge. Cloudflare Pages liefert reines HTML mit kaum CPU pro Anfrage aus. Günstigster Modus.
- ISR. Die erste Anfrage nach einer Invalidierung zahlt die vollen Renderkosten; gecachte Anfragen fast nichts. Workers deckt beides ab.
- SSR. Jede Anfrage zahlt auf Workers die vollen Renderkosten. Pro Anfrage vorhersehbar, im großen Maßstab teuer.
Der Kostenunterschied zählt bei hohem Traffic. Bei geringem Traffic entscheidet die Korrektheit, nicht die Kosten.
Beispiele für ISR und SSR an echten WordPress-Routen
Marketing-Startseite. Statisch, bei jeder redaktionellen Veröffentlichung per Webhook neu gebaut. 24 Stunden Cache am Edge mit manueller Purge-Möglichkeit. SSR als Ausweichlösung nur, wenn ein länderspezifisches Banner hinzukommt.
WooCommerce-Produktdetailseite. ISR mit der Produkt-ID als Cache-Schlüssel. Webhook aus WooCommerce bei Bestandsänderung, Preisänderung oder inhaltlicher Aktualisierung. Cache-Fenster: 1 Stunde als Absicherung. SSR nur, wenn eine Echtzeit-Bestandsanzeige eine UX-Anforderung ist.
Bestellhistorie des Kunden. SSR. Pro Nutzer, sitzungsabhängig, kein Caching am Edge.
Dieselbe Architektur, drei verschiedene Rendering-Modi, eine Entscheidungsregel.
Weitere Leitfäden zu Headless WordPress
Dieser Artikel gehört zum Leistungsbereich Headless WordPress. Für die Wahl auf Framework-Ebene lesen Sie die Entscheidungsmatrix Next.js oder Astro.
Die Umsetzung zu diesem Thema betreuen wir im Rahmen des Core-Web-Vitals-Audits.
