Headless WordPress, ISR oder SSR: den Rendering-Modus nach Änderungsrhythmus wählen

#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 kann über den Framework-Adapter beide Modi ausliefern; eine Seite aus dem Cache 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.

#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. Der WordPress-Origin 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. Ein Intervall von 60 Sekunden baut nicht jede Seite 60 Mal pro Stunde neu: Next.js regeneriert eine Seite erst, wenn nach Ablauf des Fensters eine Anfrage eintrifft. Die echten Kosten entstehen dadurch, dass jede vielbesuchte Seite bis zu einmal pro Minute im Hintergrund neu erzeugt werden kann, und auf Plattformen mit Abrechnung pro Anfrage zählt diese Hintergrundarbeit als zusätzliche Rechenzeit.

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 erreicht Workers über seinen offiziellen Cloudflare-Adapter. Next.js dokumentiert ISR für die Node.js-Laufzeit und führt die Unterstützung durch Adapter als plattformabhängig, deshalb sollten Sie den Adapter prüfen, bevor Sie ISR auf Workers einplanen. 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. Auf Workers hängt das vom Cache des Adapters ab, nicht vom Framework allein.
• 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.

#Wie revalidate in Next.js für WordPress-Seiten funktioniert

Eine Route mit export const revalidate = 3600 liefert ihr gecachtes HTML an jede Anfrage innerhalb des Fensters aus. Der aktuelle ISR-Leitfaden von Next.js beschreibt, was danach passiert: Die erste Anfrage nach Ablauf des Fensters bekommt noch die veraltete Seite, diese Anfrage startet eine Regenerierung im Hintergrund, und sobald sie erfolgreich ist, erhält die nächste Anfrage die neue Version. Ein Beitrag, den niemand aufruft, wird nie regeneriert. Das Intervall begrenzt, wie oft eine Seite neu gebaut werden kann; es plant keine Rebuilds.

Vier Details aus demselben Leitfaden entscheiden, ob das an einem WordPress-Frontend funktioniert:

• Wenn eine Route mehrere fetch-Aufrufe mit unterschiedlichen revalidate-Werten macht, bestimmt der niedrigste das ISR-Intervall der Seite. Eine Seitenleiste, die neueste Beiträge mit einem Fenster von 60 Sekunden lädt, zieht den ganzen Artikel auf 60 Sekunden herunter.
• Ein einziger fetch mit revalidate: 0 oder cache: 'no-store' macht die Route dynamisch. Ein ungecachter Aufruf eines WordPress-Endpunkts, etwa eines Aufrufzählers, verschiebt die Seite unbemerkt von ISR zu SSR.
• Schlägt die Regenerierung fehl, zum Beispiel weil der WordPress-Origin einen Fehler liefert, liefert Next.js weiter die letzte funktionierende Version aus und versucht es bei der nächsten Anfrage erneut. Ein Ausfall des Origins leert das Frontend nicht.
• Der Leitfaden empfiehlt ein langes Intervall, eher eine Stunde als eine Sekunde, und On-Demand-Revalidierung, wenn Präzision nötig ist. Das ist die Webhook-zuerst-Regel aus dem Abschnitt oben.

Der Response-Header x-nextjs-cache meldet den Zustand jeder Anfrage als HIT, STALE, MISS oder REVALIDATED. Ihn direkt nach einer Veröffentlichung zu lesen, ist der schnellste Weg, um zu bestätigen, dass ein Webhook das Frontend erreicht hat.

#Wie man Next.js-Seiten per WordPress-Webhook revalidiert

Die Empfangsseite ist ein Route Handler, etwa app/api/revalidate/route.ts, der ein gemeinsames Secret prüft und eine von zwei Funktionen aus next/cache aufruft.

revalidateTag(tag, 'max') markiert jeden gecachten fetch mit diesem Tag als veraltet, auf allen Seiten, die ihn nutzen (Referenz zu revalidateTag). Mit dem Profil 'max' bekommen Besucher weiter die veraltete Kopie, während die frische geladen wird. Für ein Veröffentlichungsereignis in WordPress ist das meist der richtige Kompromiss: fetch-Aufrufe mit post-8421 und posts taggen, und ein Webhook aktualisiert Beitrag, Archiv und Startseite. Wenn die veraltete Kopie nie wieder ausgeliefert werden darf, etwa bei einem zurückgezogenen Artikel, verlangt die Referenz von Webhook-Aufrufern { expire: 0 }, weil updateTag nur in Server Actions funktioniert. Die Form mit einem Argument, revalidateTag(tag), ist veraltet. Tags unterscheiden Groß- und Kleinschreibung und sind auf 256 Zeichen begrenzt.

revalidatePath(path) arbeitet mit Routen statt mit Daten (Referenz zu revalidatePath). Ein wörtlicher Pfad wie /blog/my-post aktualisiert eine Seite; ein Muster wie /blog/[slug] braucht das zweite Argument, 'page' oder 'layout'. Zwei Fallen sind in Headless WordPress häufig. Mit Rewrites in next.config.js übergeben Sie den Zielpfad, nicht die URL, die der Besucher sieht. Und Proxy läuft bei On-Demand-ISR-Anfragen nicht, deshalb muss ein dort umgeschriebener Pfad in seiner endgültigen Form revalidiert werden.

Beide Funktionen markieren Einträge nur; regeneriert wird beim nächsten Aufruf. Läuft die App auf mehreren Instanzen mit dem standardmäßigen Dateisystem-Cache, invalidiert ein Webhook nur die Instanz, die ihn empfangen hat. On-Demand-Revalidierung braucht dann einen gemeinsamen Cache-Handler, bevor man sich auf sie verlassen kann.

#Wie Route Caching in Astro 7 ISR ersetzt

Astro rendert standardmäßig jede Seite vorab. Eine Route wechselt mit export const prerender = false zum Rendering bei Bedarf, was einen Server-Adapter voraussetzt. output: 'server' kehrt den Standard um, und die Dokumentation rät, bei 'static' zu bleiben, bis die meisten Seiten wirklich einen Server brauchen (On-Demand-Rendering in Astro). Eine bei Bedarf gerenderte Seite kann ihren eigenen Cache-Control-Header über Astro.response.headers setzen.

Astro 7 bringt Route Caching, das den größten Teil der Lücke zu ISR in Next.js schließt (Route Caching in Astro). Eine On-Demand-Seite ruft Astro.cache.set({ maxAge: 3600, swr: 60, tags: ['post-8421'] }) auf. Der Endpunkt, der den WordPress-Webhook empfängt, ruft context.cache.invalidate({ tags: ['post-8421'] }) oder invalidate({ path: '/blog/my-post' }) auf. Die Invalidierung per Pfad greift nur bei exakter Übereinstimmung, ohne Platzhalter. routeRules in astro.config.mjs legen Standardwerte für Gruppen von Routen fest, etwa ein maxAge für /blog/[...slug], und eine Seite kann sie überschreiben oder sich mit Astro.cache.set(false) abmelden, wenn die Antwort personalisiert ist.

Der Cache selbst kommt von einem Provider. Das eingebaute memoryCache() passt zu einem einzelnen Node-Server. Die Adapter für Netlify, Vercel und Cloudflare liefern CDN-Provider, die noch experimentell sind und von Hand aktiviert werden müssen. Der Cloudflare-Provider, ab @astrojs/cloudflare 14, setzt die Header Cloudflare-CDN-Cache-Control und Cache-Tag und schaltet den Workers-Cache ein. In der Entwicklung tut die Cache-API nichts, testen Sie sie also mit einem Build und einer Vorschau.

#Wie man statische und dynamische Teile auf einer WordPress-Seite mischt

Viele Routen sind bis auf ein einziges Live-Element stabil: eine Produktseite mit Lagerbestand, ein Artikel mit dem Avatar des angemeldeten Lesers. Die ganze Seite für dieses eine Element bei jeder Anfrage zu rendern, ist die teure Lösung. Server Islands in Astro sind die günstigere (Server Islands in Astro). Ergänzen Sie server:defer an der Komponente, die frische Daten braucht. Der Rest der Seite bleibt vorab gerendert oder gecacht, und die Insel wird nach dem Laden der Seite von einem eigenen Endpunkt geholt. Ein Kindelement mit slot="fallback" steht bis dahin an ihrer Stelle, und jede Insel lädt unabhängig, sodass eine langsame Bestandsabfrage nichts anderes aufhält.

Zwei Grenzen gelten. Server Islands brauchen einen Adapter, und ihre Props müssen serialisierbar sein: einfache Objekte, Strings, Zahlen, Arrays, Datumswerte und einige weitere Typen, aber keine Funktionen. Für eine WooCommerce-Produktseite heißt das: die Produkt-ID übergeben, nicht einen API-Client.

Das verfeinert die Tabelle oben. Die Route bleibt statisch oder ISR, und nur die Insel wird pro Anfrage gerendert.

#Wie man WordPress-Inhalte für statische und ISR-Builds abruft

Jeder Prerender-Schritt beginnt mit einer Liste von Slugs, und die WordPress-REST-API liefert sie seitenweise. per_page akzeptiert Werte von 1 bis 100, und jede Antwort enthält die Header X-WP-Total und X-WP-TotalPages, sodass ein Build-Skript die erste Seite liest und bis zur Seitenzahl aus dem Header weiterläuft (Paginierung in der REST-API). Next.js übergibt diese Liste an generateStaticParams. Nach dem Build veröffentlichte Beiträge werden bei ihrer ersten Anfrage gerendert, solange dynamicParams nicht auf false steht, und generateStaticParams wird während der Revalidierung nicht erneut aufgerufen (Referenz zu generateStaticParams).

Der Parameter _fields kürzt die Antwort auf das, was der Schritt braucht, zum Beispiel ?_fields=slug,modified_gmt für die Slug-Liste, und WordPress berechnet die weggelassenen Felder gar nicht erst. Seit WordPress 5.3 akzeptiert er auch verschachtelte Meta-Schlüssel, und seit 5.4 lässt sich _embed auf benannte Relationen wie author,wp:term begrenzen (globale Parameter der REST-API).

Zur Erkennung von Änderungen akzeptiert der Posts-Endpunkt modified_after mit einem Datum nach ISO 8601 und liefert modified_gmt bei jedem Beitrag (Referenz zum Posts-Endpunkt). Ein geplanter Job, der nach Beiträgen fragt, die seit seinem letzten Lauf geändert wurden, ist eine solide Absicherung gegen verlorene Webhooks und günstiger als ein kurzes revalidate-Fenster auf jeder Route.

#Wie man WordPress-Entwürfe auf einem ISR-Frontend in der Vorschau zeigt

Redakteure erwarten, dass die Vorschau den Entwurf zeigt, während ein gecachtes Frontend die veröffentlichte Version ausliefert. Der Draft Mode von Next.js löst das pro Besucher (Leitfaden zum Draft Mode). Ein Route Handler prüft ein gemeinsames Secret, ruft draftMode().enable() auf, was das Cookie __prerender_bypass setzt, und leitet auf die Seite weiter. Anfragen mit diesem Cookie umgehen den fetch-Cache und den ISR-Antwort-Cache und werden mit Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate ausgeliefert. Alle anderen Besucher bekommen weiter die gecachte Seite.

Auf der WordPress-Seite liefert der Posts-Endpunkt ohne weitere Angabe veröffentlichte Inhalte, weil status standardmäßig publish ist. Entwürfe werden daher mit authentifizierten Anfragen gelesen. Anwendungspasswörter, seit WordPress 5.6 im Kern enthalten und per Basic Auth über HTTPS gesendet, sind die Methode, die das Handbuch dokumentiert (Authentifizierung in der REST-API). Halten Sie diese Zugangsdaten auf dem Server, im Route Handler oder in einem rein serverseitigen fetch, und nie im Client-Code.

#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 Risiken einer Migration fasst die Checkliste mit SEO-Mustern zusammen, die Besonderheiten im Handel behandelt Headless WordPress für WooCommerce, und die Kostenseite steht im Artikel zur Wirtschaftlichkeit von Headless WordPress. Einen Vergleich der Frameworks Version für Version, einschließlich der Art, wie beide WordPress-Daten laden, bietet Astro 5 vs Next.js 15.

Die Umsetzung zu diesem Thema betreuen wir im Rahmen des Core-Web-Vitals-Audits.