Effiziente Cache-Richtlinie für statische Inhalte

Wieso zeigt Google PageSpeed Insights schlechte Ergebnisse beim Test meiner Website?

Testet man seine Seite per Google PageSpeed Insights, wundert man sich oft, wieso die Ergebnisse so schlecht dargestellt werden, obwohl die Seite eine gute Performance hat.

Hierbei ist es wichtig zu wissen, dass Google PageSpeed Insights einige Ergebnisse bemängel, welche in der Praxis als “gut” beziehungsweise “absolut ausreichend” zu bewerten sind. Dementsprechend schlägt das Tool auch Änderungen vor, welche sich auf die Zeit mancher Daten im „Browser Caching“ beziehen. Dies kann für unerfahrene Webseiten-Betreiber im Testergebnis natürlich sehr verwirrend sein.

Was ist dieses „Caching“ und warum ist es so wichtig?

Im Prinzip ist es nicht schwer, „Caching“ zu verstehen und für seine Webseite zu verwenden.
Durch ein wenig Optimierung lässt sich hierdurch die Ladezeit verkürzen und die PageSpeed-Punktzahl verbessern. Hierbei ist jedoch zu unterscheiden, wo der Cache liegt. Beim Kunden im Browser oder auf dem Server.

Was ist nun aber „Caching für statische Inhalte“?
Kurz und einfach erklärt, handelt es sich dabei um die Lebensdauer von statischen Dateien und Skripten, welche der Browser eines Nutzers speichert. Diese erzeugten Kopien und Inhalte können somit beim späteren Besuch eines Nutzers schneller geladen werden, da der Browser die Daten nicht erst vom Server deiner Webseite anfragen muss.

Deshalb ist es wichtig, den statischen Inhalten, welche im Browser des Users zwischengespeichert werden, eine bestimmte Ablauffrist zu geben. Durch diese kann der Browser prüfen, ob die gecachte Kopie veraltet ist und diese dann durch einen aktualisierte Version der Webseite ersetzen.

Grundsätzlich gilt in der Regel je länger die Lebenszeit von statischen Inhalten, desto besser. In der Praxis gelten 30 Tage als absolut ausreichende Lebensdauer für Skripte.
Die Google PageSpeed Insights bewerten jedoch bis zu 30 Tage „alte“ Skripte als in der Lebensdauer zu gering.

Wie richte ich die „Cache Control“ für die effiziente Cachenutzung in WordPress ein?

Zum einrichten der „Cache Control“ und zur effizienten Nutzung gibt es mehrere Lösungswege.

Cache-Control und Expires-Header zur Webseite hinzufügen

Damit das Browser Caching funktioniert, gibt es zwei Header, den Cache-Control und Expires-Header. Diese werden benötigt, um das Caching bei deinem Webseitenbesucher zu steuern, da der Browser durch diese bestimmen kann, wie langer er die Ressourcen speichert, bevor diese aktualisiert werden sollen.

Am einfachsten lässt sich dies kontrollieren, indem man sich in Google PageSpeed Insights die Details zu jeder Ressource anschaut. Findet man unter dem Punkt „Cache TTL“ keine Angabe, sind die Header nicht aktiv.

Die Aufgabe des Cache-Control-Headers ist das einschalten des Client-seitigen Cachings, also das Caching des Browsers, welcher der Kunde nutzt. Der Expires-Header dagegen gibt den Zeitpunkt an, ab wann eine Ressource nicht mehr als aktuell gilt und erneuert werden muss.

Derweil kann es aber überflüssig sein, hier beide Header zu benutzen. Der Cache-Control-Header ist neuer und aktueller und wird somit am meisten verwendet.

Cache Control und Expire Headers bei HostPress

Durch unsere Rocket Config, welche standardmäßig auf unseren Servern aktiv ist, sowie dem Zusammenspiel zwischen WP-Rocket und Nginx, brauchst du dich um nichts zu kümmern. Die Einstellungen werden dadurch von uns korrekt gesetzt und pflegen die Header automatisch in den HTTP-Header deiner Seite ein. Bei der Verwendung eines Content Delivery Networks (CDN) sollte man diese jedoch noch einmal manuell prüfen.

Sonderfall: Cookie-Consent-Plugin verhindert CDN-Caching der HTML-Seite

Nutzt du zusätzlich ein Content Delivery Network (CDN), kann es vorkommen, dass deine Website für Besucher aus entfernten Regionen trotz CDN weiterhin sehr langsam lädt – manchmal im Bereich von mehreren Sekunden bis Minuten statt der erwarteten schnellen Auslieferung. Eine mögliche, leicht zu übersehende Ursache dafür sind die HTTP-Header Cache-Control und Vary, die von Cookie-Consent- bzw. DSGVO-Plugins gesetzt werden können.

Woran du dieses Szenario erkennst

• Die Ladezeit ist nur für bestimmte Seiten oder Sprachversionen extrem hoch, während andere Bereiche der Website normal schnell laden.
• In den Entwickler-Werkzeugen deines Browsers (Netzwerk-Tab) zeigt die HTML-Antwort einen Header wie cache-control: no-cache, no-store, must-revalidate in Kombination mit vary: Cookie.
• Ein Performance-Test aus der Nähe deines Serverstandorts zeigt gute Werte, während Tests aus weit entfernten Regionen deutlich schlechter ausfallen.

Warum das passiert

Der Header Vary: Cookie teilt einem CDN mit, dass der Inhalt der Seite je nach gesetztem Cookie unterschiedlich ausfallen kann. Da nahezu jeder Besucher zunächst einen individuellen oder noch gar keinen Consent-Cookie besitzt, kann das CDN die HTML-Seite in der Praxis nicht sinnvoll zwischenspeichern – jede Anfrage wird stattdessen an den Ursprungsserver durchgereicht. In Kombination mit Cache-Control: no-store wird die Zwischenspeicherung zusätzlich vollständig unterbunden. Für Besucher in der Nähe des Serverstandorts fällt das kaum auf, für weit entfernte Besucher addiert sich die volle Latenz zum Ursprungsserver bei jeder einzelnen Anfrage.

Was du tun kannst

1. Prüfe die Antwort-Header deiner Seite (z. B. über die Entwickler-Werkzeuge deines Browsers oder ein Online-Tool) auf Vary: Cookie und einen restriktiven Cache-Control-Wert.
2. Prüfe in den Einstellungen deines Cookie-Consent-Plugins, ob es eine Option gibt, den Consent-Status nicht direkt in die HTML-Auslieferung einfließen zu lassen (z. B. durch rein clientseitiges Einblenden des Consent-Banners statt serverseitiger Auslieferung unterschiedlicher HTML-Varianten).
3. Kontaktiere unseren Support, wenn du unsicher bist, welches Plugin den Header setzt oder wie sich das CDN-Caching wiederherstellen lässt, ohne die DSGVO-Konformität deiner Cookie-Einwilligung zu beeinträchtigen.

Beachte: Diese Einschränkung betrifft ausschließlich das Caching der HTML-Seite selbst. Statische Inhalte wie Bilder, CSS- oder JavaScript-Dateien sind von Vary: Cookie in der Regel nicht betroffen und werden weiterhin regulär über das CDN zwischengespeichert.