Ohne Full Page Cache verarbeitet WordPress jede Anfrage dynamisch – PHP, Datenbank und Plugins laufen für jeden Aufruf und begrenzen damit die Skalierung großer Seiten. So steigen TTFB, Serverlast und Fehlerraten bei Trafficspitzen sprunghaft, während SEO-Signale und Conversion leiden, bis die Seite unter hoher Last aussteigt.
Zentrale Punkte
Bevor ich tiefer einsteige, fasse ich die zentralen Aussagen kurz zusammen, damit die wichtigsten Fakten direkt klar sind.
- Serverlast: Dynamisches Rendering bei jedem Request führt schnell zu CPU-Spitzen und Timeouts.
- TTFB: Ohne Cache steigt die Wartezeit massiv, mit Full Page Cache sinkt sie auf wenige Millisekunden.
- SEO: Schlechte Ladezeiten zerstören Core Web Vitals und Rankings.
- Skalierung: Erst Full Page Cache macht hohe gleichzeitige Zugriffe tragfähig.
- Strategie: Page-, Object-, OPcache und Browser-Cache greifen im Paket.
Warum dynamisches Rendering nicht skaliert
WordPress generiert HTML bei jedem Aufruf neu, lädt Plugins, führt Hooks aus und fragt die Datenbank ab – das klappt bei wenig Traffic, bricht bei Anstürmen aber weg. Jeder zusätzliche Besucher erhöht die Zahl der Queries und die PHP-Laufzeit, was die CPU in die Knie zwingt. Große Themes, Builder und SEO-Plugins verstärken die Arbeit pro Request. Kommen 1.000 gleichzeitige Nutzer, vervielfacht sich die Last exponentiell, bis der Webserver Anfragen ablehnt. Ich sehe in Audits oft TTFB von 300–500 ms im Leerlauf, die unter Last auf Sekunden anschwellen und die UX ruinieren.
Was Full Page Cache leistet
Full Page Cache speichert die vollständig gerenderte Seite als statisches HTML ab und beantwortet Folgeanfragen ohne PHP und ohne Datenbank. Serverseitige Varianten wie Nginx fastcgi_cache liefern Inhalte schon vor der PHP-Schicht aus und reduzieren die TTFB auf wenige Millisekunden. Für anonyme Nutzer – das sind oft 90–95 % des Traffics – kommt fast jede Seite aus dem Cache. Ich steuere Gültigkeit (TTL), Purge-Regeln und Ausnahmen mit Cookies oder URL-Varianten, damit dynamische Bereiche korrekt bleiben. So senke ich die CPU-Zeit pro Request dramatisch und gewinne echte Skalierbarkeit.
Ohne Cache: harte Zahlen und Folgen
Ungecachte WordPress-Instanzen erzeugen pro Aufruf Dutzende bis Hunderte Queries und laufen unter Last in 100 % CPU-Auslastung. Ab 3 Sekunden Ladezeit steigt die Absprungrate deutlich, was Umsätze und Leads direkt trifft. Core Web Vitals wie LCP fallen ab, weil der Server zu lange braucht, um das erste Byte zu senden. Ich beobachte bei 10.000 Nutzern pro Stunde häufig Fehlerraten und Queue-Build-up. Die folgende Tabelle zeigt typische Unterschiede, die ich in Projekten regelmäßig messe:
| Aspekt | Ohne Full Page Cache | Mit Full Page Cache |
|---|---|---|
| TTFB | 200–500 ms | < 50 ms |
| Serverlast bei 10k User | 100 % CPU, Fehler | 20–30 % CPU |
| Skalierbarkeit | bis ca. 1k gleichzeitig | hohe Gleichzeitigkeit |
| SEO-Impact | schwache Werte | starke Werte |
Mehrstufiges Caching sinnvoll kombinieren
Ich setze Full Page Cache als erste Stufe ein und ergänze ihn mit Object Cache (Redis oder Memcached), damit wiederkehrende Datenbankergebnisse im RAM liegen. OPcache hält PHP-Bytecode bereit und spart Ausführungszeit, was die Backend-Performance spürbar senkt. Browser-Caching reduziert Requests für statische Assets wie CSS, JS und Bilder. Ohne Full Page Cache bleiben diese Maßnahmen limitiert, weil HTML weiterhin dynamisch erzeugt wird. Wer die Unterschiede und Einsatzgebiete verstehen will, findet unter Cache-Arten eine klare Abgrenzung der Mechanismen, die ich täglich nutze.
Serverseitiges Caching mit Nginx fastcgi_cache
Nginx liefert gecachte Seiten direkt aus dem Speicher oder von SSD, bevor PHP überhaupt startet – das ist die Königsdisziplin. Ich definiere Keys mit Host, Pfad und relevanten Cookies, setze sinnvolle TTLs und „bypass“-Regeln für eingeloggte Nutzer. Ein Plugin wie Nginx Helper steuert Purges nach Veröffentlichungen und Updates verlässlich. Zusammen mit sauber konfiguriertem Cache-Control auf Asset-Ebene verschwinden Lastspitzen selbst bei Kampagnen. Wer tiefer einsteigen möchte, nutzt den Leitfaden zu serverseitiges Caching und setzt die Schritte zügig um.
Edge-Caching und CDN sinnvoll nutzen
Bei globaler Reichweite reduziere ich die Distanz zum Nutzer mit Edge-Caching über ein CDN. Cloudflare APO kann HTML am Rand cachen und so TTFB weltweit drücken. Wichtig ist sauberes Routing bei Cookies und dynamischen Bereichen, damit personalisierte Teile korrekt bleiben. Für News, Magazine und Blogs bringt APO messbare Vorteile beim Erstaufruf. Ein praktischer Einstieg ist der Cloudflare APO Test, der die Wirkung auf Ladezeiten und Last zeigt.
WooCommerce und eingeloggte Nutzer gezielt beschleunigen
Shops leben von personalisierten Bereichen wie Warenkorb, Checkout und „Mein Konto“, die ich bewusst nicht vollseitig cache. Stattdessen bedient der Object Cache teure Queries, während ich für Kategorieseiten und Produktlisten aggressiven Full Page Cache nutze. Über Cookie-Vary und Fragment-Techniken lassen sich einzelne Widgets dynamisch halten. Ich achte darauf, keine Cart-Cookies auf jedem Seitenaufruf zu setzen, damit der Page Cache nicht versehentlich umgangen wird. So bleibt der Checkout reaktionsfähig und die Kategorieseiten liefern trotz Trafficspitzen blitzschnell aus.
Typische Cache-Fehler und wie ich sie vermeide
Ein häufiger Fehler ist das Cachen von Seiten mit personenbezogenen Inhalten, was falsche Ausgaben erzeugt. Ebenso kritisch sind zu kurze TTLs, die den Cache kaum treffen lassen, oder zu lange TTLs, die Aktualisierungen verzögern. Ich definiere klare Purge-Ereignisse bei Publish, Update und Delete, um Inkonsistenzen zu verhindern. Auch Query-Strings, die unnötige Varianten erzeugen, halte ich im Zaum. Gegen Cache-Stampedes nutze ich Locking oder Microcaches, damit nicht tausende Prozesse dieselbe Seite neu bauen.
Umsetzungsschritte ohne Umwege
Ich starte mit einer Host-Umgebung, die Nginx, PHP-FPM, OPcache und Redis bereitstellt, damit alle Ebenen zusammenspielen. Danach aktiviere ich Full Page Cache serverseitig und prüfe mit curl und Response-Headern, ob „HIT“ zuverlässig erscheint. Anschließend richte ich das Purging über ein passendes Plugin ein und teste Updates an Beiträgen, Menüs und Widgets. Für den Object Cache setze ich Redis mit persistentem Speicher auf und kontrolliere die Trefferquote mit Monitoring. Zum Schluss härte ich Cache-Control für Assets, prüfe HTTP/2 oder HTTP/3 und halte TTFB und LCP im Blick.
Kosten, Hosting-Wahl und echte Skalierung
Shared Hosting teilt Ressourcen und bremst große, ungecachte Seiten sofort aus. Ein VPS oder Managed Server mit dedizierter CPU und schneller NVMe-SSD erlaubt echtes serverseitiges Caching und planbare Performance. Mit Full Page Cache sinken Infrastrukturkosten häufig, weil weniger Rohleistung nötig ist. Ich beobachte oft, dass ein sauber gecachter Stack Peaks aushält, die zuvor nur mit teuren Upgrades möglich waren. So bleibt das Budget kalkulierbar und die User Experience verlässlich schnell.
Cache-Invalidierung in der Praxis
Cache ist nur so gut wie seine Invalidierung. Ich arbeite mit Ereignissen (Publish, Update, Delete), um gezielt die betroffenen URLs zu purgen: den Beitrag selbst, die Startseite, Kategorie-, Tag- und Autorenseiten sowie relevante Paginierungen. Bei WooCommerce kommen Produkt-, Kategorie- und ggf. Up-/Cross-Selling-Seiten dazu. Statt global „alles“ zu löschen, nutze ich Muster (z. B. Pfade einer Taxonomie) und halte die Invalidierung eng. Das verhindert Cache-Wüsten und reduziert den Druck auf den Origin. Nach Purges wärme ich kritische Routen automatisiert vor (Sitemap- oder Menü-basiert), damit Hot-Pfade sofort als HIT kommen. Für High-Churn-Content setze ich kurze TTLs und verlängere mit Stale-Strategien (siehe unten), um ein gutes Gleichgewicht aus Aktualität und Stabilität zu erreichen.
Vary, Cookies und sichere Ausnahmen
Die Cache-Keys definiere ich so, dass sie nur relevante Varianten enthalten: Host, Pfad, Query-String-Whitelist und wenige Cookies. Standard-Ausnahmen sind wp_logged_in, wordpress_logged_in, comment_author, admin_bar und WooCommerce-spezifische Cart/Session-Cookies. Übermäßige Marketing- oder A/B-Test-Cookies zerstören die Trefferquote – ich blocke sie für anonyme Seiten oder normalisiere sie aus dem Key heraus. Außerdem ignoriere ich UTM-, fbclid- oder gclid-Parameter, damit nicht pro Kampagne neue Varianten entstehen. POST-Requests, Previews, Admin, XML-RPC und REST-Endpunkte mit Session-Bezug laufen grundsätzlich am Cache vorbei. Wenn Personalisierung nötig ist, isolierte ich sie: kleine Ajax-Fragmenten, Edge-Includes oder Cookie-gesteuerte Widget-Snippets, ohne die ganze Seite uncached zu machen.
Prewarming und Stale-Strategien
Nach Deploys oder großen Purges will ich keine kalten Caches. Ich setze auf Prewarming mit einer Prioritätenliste (Top-URLs, Kategorieseiten, Navigation, Sitemaps), damit die ersten Nutzer nicht die volle PHP-Last tragen. Ergänzend nutze ich „stale-while-revalidate“ und „stale-if-error“-Semantik: Abgelaufene Seiten dürfen für einen kurzen Zeitraum noch dient werden, während im Hintergrund ein Refresh läuft oder der Origin unter Last steht. Das stabilisiert Kampagnenstarts und verhindert Fehlerwellen. Bei API-ähnlichen Endpunkten oder stark frequentierten Seiten helfen Microcaches (einige Sekunden), um Stampedes zu verhindern, ohne die Aktualität zu verlieren.
Monitoring, KPIs und Header-Checks
Skalierung ohne Messung ist Blindflug. Ich tracke Cache-Hit-Rate (global und pro Route), TTFB P50/P95, Origin-QPS, CPU, Speicher, I/O, Evictions und Purge-Volumen. In den Response-Headern hinterlasse ich klare Statuswerte (z. B. X-Cache oder FastCGI-Cache: HIT/BYPASS/MISS/STALE) und nutze Server-Timing, um Zeitanteile sichtbar zu machen. Logseitig werte ich Kombinationen aus Statuscode, Upstream-Response-Time und Cache-Status aus, um Engpässe zu identifizieren. Auf Client-Seite kombiniere ich synthetische Tests mit RUM-Daten, damit echte Nutzerpfade (Erstaufruf, Navigation, Checkout) abgedeckt sind. Ziele: >90 % HIT bei anonymem Traffic, TTFB < 50 ms für gecachte Seiten, stabiler P95 auch bei Peak-Last.
Code- und Plugin-Antipatterns
Viele Performance-Probleme entstehen im Code. Ich vermeide PHP-Sessions, randomisierte Ausgaben bei jedem Request und „nocache“-Header ohne Not. Statt Transients in der Datenbank nutze ich den Object Cache (Redis) mit sinnvollen TTLs und invalidate selektiv. wp-admin-ajax sollte nicht zur Allzweckwaffe werden – teure Aktionen kapsle ich in gecachte REST-Endpunkte, deren Antworten ich kurzzeitig im RAM halte. Heartbeat-Intervalle reduziere ich, Cron-Jobs bündele ich und lasse sie asynchron laufen. Feeds, Sitemaps und GraphQL/REST-Aggregate bekommen einen eigenen Microcache. Wichtig: Nonces und personenbezogene Daten dürfen nicht in gecachte HTML-Fragmente wandern – dafür setze ich kleine, dynamische Inseln oder ersetze Werte clientseitig.
Multisite, Mehrsprachigkeit und Query-Strings
Bei Multisite- oder Mehrsprachen-Setups gehört die Variante (Domain/Subdomain/Pfad) zwingend in den Key. Sprach-Parameter (lang, locale) oder Pfadpräfixe definiere ich explizit als Vary, damit Übersetzungen nicht vermischt werden. Mobile-Varianten per User-Agent-Detection vermeide ich – responsive Markup und CSS sind meist die bessere Lösung, weil ein UA-Vary die Cache-Fläche aufbläst. Für Filter- und Suchseiten arbeite ich mit Query-String-Allowlists, damit nur relevante Parameter den Key beeinflussen. Tracking-Parameter werden entfernt oder normalisiert. Paginierungen bekommen ein separates, aber aggressives Caching mit kürzerer TTL, um Crawl- und Nutzlast zu senken.
Sicherheit, Datenschutz und Compliance
Ich cache niemals Seiten mit personenbezogenen Daten, Kontoinformationen oder Tokens. Für Formulare setze ich „no-store“ oder gezielte Bypässe, wenn CSRF-Nonces im Spiel sind. Die Admin-Bar, Vorschau-Modi und private Beiträge bleiben aus dem Cache heraus – entsprechende Cookies sind harte Ausschlusskriterien. Auf Serverebene verhindere ich, dass Privat- oder Draft-URLs versehentlich in Edge- oder Origin-Caches landen. Logs und Header maskiere ich, damit keine sensiblen Cookie-Werte oder IDs ausgespielt werden. Gerade im EU-Kontext ist wichtig, dass der Cache keine personenbezogenen Inhalte persistiert und alle Purges verlässlich greifen.
Lasttests, Rollout und Betrieb
Bevor ich große Kampagnen fahre, simuliere ich Last realistisch: Cold-Start, Traffic-Rampen, Peaks und Langläufer. Ich messe HIT-Raten und TTFB unter Last und überprüfe, ob Purges die Stabilität beeinträchtigen. Rollouts erfolgen bevorzugt Blue/Green oder als Canary mit konservativen TTLs – so kann ich bei Bedarf sofort zurückschalten, ohne die Cache-Hierarchie zu verwirren. Für den Betrieb definiere ich klare Runbooks: Wie purge ich selektiv? Wie wärme ich vor? Welche Schwellen lösen Alarme aus? Und wann skaliere ich horizontal (mehr PHP-Worker) vs. vertikal (schnellere CPU/IO)? Ein sauber konfigurierter Stack hält so berechenbar auch plötzliche Trafficspitzen aus.
Feinabstimmung der Asset-Strategie
Damit HTML-Caching richtig durchschlägt, müssen Assets mithalten. Ich arbeite mit Cache-Busting über Dateinamen-Hashes, setze lange TTLs (Monate) und sorge bei Deploys für konsistente Referenzen. Gzip oder Brotli sind Pflicht, HTTP/2/3 reduziert Latenzen, und kritische CSS/JS-Split-Punkte verhinderen Render-Blocking. Wichtig ist, dass Asset-Header nicht unbedacht Overrides durch Plugins bekommen – ich halte Cache-Control und ETag konsistent und verzichte auf aggressive Rewrites, die Caches umgehen.
Operative Checks und Qualitätssicherung
Zum Schluss prüfe ich regelmäßig die Basics: Ist der Admin-Login garantiert ein BYPASS? Kommt für Anonyme auf allen Hauptpfaden ein HIT? Bleiben Previews uncached? Verhalten sich Feeds, Sitemaps, Suche und 404-Seiten korrekt? Stimmen die TTLs zwischen Edge und Origin? Wie hoch ist die EVICTION-Rate und gibt es Hot-Keys, die den Cache verdrängen? Diese Routine-Checks sparen in der Praxis die meisten Eskalationen, weil sie Probleme entdecken, bevor Traffic sie sichtbar macht.
Kurz zusammengefasst
Ohne Full Page Cache prügelt jede Anfrage auf PHP und Datenbank ein, was unter Last in Sekunden zu Zeitüberschreitungen, schlechter TTFB und wegbrechenden Conversions führt. Mit Full Page Cache beantworte ich die meisten Seitenaufrufe aus dem Speicher und senke die CPU-Last drastisch. Erst die Kombination aus Full Page, Object Cache, OPcache und sinnvollem Browser-Caching macht große WordPress-Seiten wirklich tragfähig. Nginx fastcgi_cache plus sauberes Purging liefert die HTML-Antworten rasch und fehlerfrei an anonyme Nutzer. Wer hohe Reichweiten plant oder bereits erlebt, kommt an serverseitigem Caching nicht vorbei, wenn die Seite verlässlich skalieren soll.
