Google PageSpeed Insights ist eines von mehreren nützlichen Tools zur Messung der Leistung von Webseiten. Einige seiner Vorschläge – wie die Warnung „Browser-Caching nutzen“ – können jedoch für unerfahrene Webseiten-Betreiber verwirrend sein.

Wenn man es herunterbricht, ist das Caching gar nicht so schwer zu verstehen. Mit ein paar Optimierungen kannst du diese Best Practice auf deiner Webseite implementieren, um die Ladezeiten zu verkürzen und deine PageSpeed-Punktzahl zu verbessern.

In diesem Beitrag fangen wir mit einer Einführung in die Warnung zum Leverage Browser Caching an. Dann werden wir einige Tipps zur Behebung dieses Problems auf deiner WordPress Webseite geben.

Lasst uns einsteigen!

Was ist die Leverage Browser Caching Warnung?

Um die Leverage Browser Caching Warnung zu verstehen, hilft es, zuerst ein wenig über Google PageSpeed Insights zu wissen. Wenn du neu auf der Plattform bist, empfehlen wir dir, unseren kompletten Leitfaden, Google PageSpeed Insights, zu lesen: Mit WordPress 100/100 Punkte erzielen.

Die Leverage Browser Caching Warnung ist eine von vielen ‚Diagnosen‘, die Google PageSpeed als Vorschlag zur Verbesserung deiner Punktzahl wie die folgende zurückgibt:

Nutze die Browser-Caching-Warnung in Google PageSpeed Insights
Nutze die Browser-Caching-Warnung in Google PageSpeed Insights

In Version 5 von Google PageSpeed Insights wurde diese Nachricht durch die Warnung „Statische Assets mit einer effizienten Cache-Richtlinie bedienen“ ersetzt:

Bediene statische Assets mit einer effizienten Cache-Richtlinien-Warnung in Google PageSpeed Insights
Bediene statische Assets mit einer effizienten Cache-Richtlinien-Warnung in Google PageSpeed Insights

Trotz der Änderung von Sprache und Aussehen ist die Lösung für diese Warnungen dieselbe.

Google schlägt vor, das Browser-Caching zu verwenden, um die Ladezeiten der Seiten zu reduzieren und die Leistung zu verbessern. Kurz gesagt, Caching ist, wenn die Browser der Nutzer statische Kopien der Seiten deiner Webseite speichern. Dann können diese Inhalte bei späteren Besuchen schneller wieder geladen werden, da der Browser nicht den Server deiner Webseite kontaktieren muss, um auf die angeforderten Ressourcen zuzugreifen.

Allerdings benötigt jede zwischengespeicherte Ressource eine bestimmte Ablauffrist. Diese teilt dem Browser mit, wenn der Inhalt deiner Webseite veraltet ist, so dass er seine gecachte Kopie durch eine aktualisierte Version ersetzen kann.

  • Die Cache-Control- oder Expires-Header fehlen auf dem Server deiner Webseite oder dem eines Dritten.
  • Die notwendigen Header sind zwar vorhanden, aber die Verfallszeit ist sehr kurz und hat daher keinen großen Einfluss auf die Performance.

Die Lösungen für diese Warnung bestehen darin, eines oder beide dieser Probleme zu beheben.

Wie man die Leverage Browser Caching Warnung in WordPress behebt (3 Methoden)

Es gibt ein paar verschiedene Möglichkeiten, wie man die Leverage Browser Caching Warnung in WordPress beheben kann, je nachdem, was es verursacht. Hier sind drei Lösungen, die du ausprobieren kannst.

1. Cache-Kontrolle und Expires-Header hinzufügen

Es gibt zwei Header, die mit dem Browser-Caching zu tun haben: Cache-Control und Expires. Mindestens eine davon muss vorhanden sein, um das Browser-Caching für deine Webseite zu aktivieren, da die Browser auf diese Weise bestimmen, wie lange sie die Ressourcen behalten sollen, bevor sie sie aktualisieren.

Ein einfacher Weg, um festzustellen, ob dies der Grund für die Leverage Browser Caching Warnung ist, ist, sich die Details für jede Ressource anzusehen. In Google PageSpeed Insights Version 5 siehst du unter Cache TTL stattdessen „Keine“ aufgelistet:

Cache TTL-Einträge in Google PageSpeed Insights zwischenspeichern
Cache TTL-Einträge in Google PageSpeed Insights zwischenspeichern

Als praktische Referenz zeigten frühere Versionen von Google PageSpeed Insights die Meldung „Ablaufdatum nicht angegeben“, wenn die Kopfzeilen fehlten:

Ressourcen, die in der Warnung Leverage Browser Caching aufgeführt sind
Ressourcen, die in der Warnung Leverage Browser Caching aufgeführt sind

Während der Cache-Control-Header das Client-seitige Caching einschaltet und das maximale Alter einer Ressource festlegt, wird der Expires-Header benutzt, um einen Zeitpunkt anzugeben, an dem die Ressource nicht mehr gültig ist.

Du musst nicht unbedingt beide hinzufügen, da dies überflüssig sein kann. Cache-Control ist neuer und ist normalerweise die empfohlene Methode. Einige Web-Performance-Tools, wie z.B. GTmetrix, suchen jedoch immer noch nach Expires-Headern.

Wenn du bei Kinsta als Host arbeitest, brauchst du dir keine Gedanken über das Setzen dieser Header zu machen. Alle unsere Nginx-Server enthalten diese Header bereits. Diejenigen, die ein Content Delivery Network (CDN) verwenden, sollten diese Header ebenfalls bereits eingerichtet haben.

Für den Fall, dass du einen anderen Hosting-Provider verwendest, solltest du unbedingt ein Backup deiner Webseite erstellen, bevor du die folgenden Schritte befolgst, da die Bearbeitung von .htaccess deine Webseite beschädigen könnte, wenn du nicht aufpasst.

Wie man Cache-Control-Header in Nginx hinzufügt

Um Cache-Control-Header in Nginx hinzuzufügen, kannst du Folgendes in die Konfigurationsdatei deines Servers einfügen:

location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
 expires 30d;
 add_header Cache-Control "public, no-transform";
}

Dies teilt deinem Server mit, dass sich die angegebenen Dateitypen mindestens 30 Tage lang nicht ändern werden. Es wird die entsprechenden Dateien für diese Zeitspanne speichern, bevor es sie aktualisiert.

Wie man Cache-Control-Header im Apache hinzufügt

Wenn du stattdessen einen Apache-Server hast, kannst du den folgenden Code in deine .htaccess-Datei einfügen:

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
</filesMatch>

Dieses Snippet sollte vor „#BEGIN WordPress“ oder nach „#END WordPress“ eingefügt werden. In diesem Fall ist der Cache so eingestellt, dass er nach 84.600 Sekunden abläuft.

Wie man ablaufende Header in Nginx hinzufügt

Du kannst Expires-Header in Nginx hinzufügen, indem du Folgendes zu deinem Serverblock hinzufügst. In diesem Beispiel kannst du sehen, wie du verschiedene Ablaufzeiten basierend auf Dateitypen angeben kannst:

    location ~*  \.(jpg|jpeg|gif|png|svg)$ {
        expires 365d;
    }

    location ~*  \.(pdf|css|html|js|swf)$ {
        expires 2d;
    }

Wie man Expires-Header in Apache hinzufügt

Du kannst Expires-Header in Apache hinzufügen, indem du Folgendes zu deiner .htaccess-Datei hinzufügst

## EXPIRES HEADER CACHING ##

ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"

## EXPIRES HEADER CACHING ##

Du kannst dann deine Header überprüfen, indem du deine Webseite erneut durch Google PageSpeed Insights laufen lässt und siehst, ob die Warnung weiterhin besteht.

2. Browser-Caching für Google Analytics nutzen

Ironischerweise ist Google Analytics manchmal die Ursache für die Leverage Browser Caching Warnung und eine unvollkommene PageSpeed-Punktzahl. Das liegt daran, dass es eine geringe Cache-Verfallszeit von nur zwei Stunden hat. Das war früher die alte Warnung:

Leverage Browser Caching Warnung für Google Analytics Skript
Leverage Browser Caching Warnung für Google Analytics Skript

In PageSpeed Insights Version 5 führt dieses Problem nicht mehr zu einer Warnung, aber Google Analytics wird möglicherweise immer noch als nicht optimierte Ressource aufgeführt:

Google PageSpeed Insights bestand Prüfungen mit Google Analytics-Skripteintrag
Google PageSpeed Insights bestand Prüfungen mit Google Analytics-Skripteintrag

Du kannst dies nicht mit Cache-Control oder Expires-Headern ändern, da die Ressource nicht auf deinem Server liegt. Es gibt jedoch einen Weg, das Browser-Caching für Google Analytics zu nutzen, indem das Skript lokal gehostet wird.

Bitte beachte aber, dass diese Methode von Google nicht unterstützt wird.

Browser-Caching für Google Analytics mit der vollständigen Analytics-Optimierungssuite nutzen

Wenn du das obige Problem lösen möchtest, gibt es ein kostenloses Plugin namens Complete Analytics Optimization Suite (CAOS), das von Daan van den Bergh entwickelt wurde und das du benutzen kannst:

CAOS WordPress-Plugin
CAOS WordPress-Plugin

Du kannst CAOS aus dem WordPress Plugin-Verzeichnis herunterladen oder indem du es unter Plugins > Neu hinzufügen in deinem WordPress Dashboard suchst.

Einige zusätzliche Vorteile des lokalen Hostings deines Analyseskripts sind, dass es deine externen HTTP-Anfragen an Google von zwei auf eine reduziert und es dir ermöglicht, die volle Kontrolle über das Caching der Datei zu erhalten. Das bedeutet, dass du die Cache-Header verwenden kannst, wie wir dir vorhin gezeigt haben.

Um anzufangen, installiere das Plugin und gib dann deine Google Analytics Tracking ID ein. Das Plugin fügt den notwendigen Tracking-Code für Google Analytics zu deiner WordPress-Webseite hinzu, lädt die Datei analytics.js herunter, speichert sie auf deinem Server und hält es mit einem geplanten Skript in wp_cron() auf dem neuesten Stand.

Wir empfehlen auch, es so einzustellen, dass es in der Fußzeile geladen wird:

Einstellungen für die Platzierung des CAOS-Tracking-Codes
Einstellungen für die Platzierung des CAOS-Tracking-Codes

Denke daran, dass CAOS nicht mit anderen Google Analytics WordPress Plugins funktioniert.

Nutze das Browser-Caching für Google Analytics mit WP-Rocket

Alternativ kannst du auch das WordPress Caching-Plugin WP-Rocket verwenden, um das gleiche Ziel zu erreichen:

WP-Rocket WordPress-Plugin
WP-Rocket WordPress-Plugin

Das Google Tracking Add-on dieses Plugins ermöglicht es dir, dein Analyseskript mit einem Klick lokal zu hosten. Schalte einfach den Status unter WP-Rocket > Add-ons ein.

WP-Rocket und sein Add-on sind mit anderen Google Analytics Plugins kompatibel. Als Premium Tool ist es zu einem fairen Preis erhältlich, die Lizenzen beginnen bei $49 pro Jahr.

3. Minimiere deinen Gebrauch von Skripten Dritter

Manchmal kann das Google Analytics-Skript Probleme für deinen Google PageSpeed Insights Score verursachen, weil es auf Googles Server gehostet wird und du somit keine Kontrolle über den Cache hast.

Dasselbe gilt für andere Skripte von Drittanbietern. Wenn du ein Unternehmen über deine WordPress Webseite verwaltest, hast du höchstwahrscheinlich zusätzliche Skripte von Drittanbietern laufen, um Konvertierungen, A/B-Tests und mehr zu tracken.

Dazu könnten Skripte wie Facebook-Konvertierungspixel, Crazy Egg, Hotjar und andere gehören. Wenn du keinen Weg findest, diese Skripte lokal zu hosten, kannst du leider nicht viel tun, um die Kontrolle über sie zu erlangen.

Eine Möglichkeit für Facebook-Pixel-Nutzer ist es, ein weiteres WP-Rocket-Add-on zu verwenden. Idealerweise solltest du die Verwendung von Skripten von Drittanbietern minimieren, wenn du deine Google PageSpeed-Punktzahl verbessern möchtest. Es könnte sich also lohnen, eine Überprüfung deiner Webseite durchzuführen und alle Skripte zu entfernen, die für den Betrieb nicht notwendig sind.

Zusammenfassung

Auch wenn Google PageSpeed Insights kein endgültiger Maßstab für die Leistung deiner Webseite ist, so ist es doch ein guter Indikator dafür, wie es läuft. Die Verbesserung deiner Punktzahl durch das Beheben von Warnungen, die unter „Statische Assets mit einer effizienten Cache-Richtlinie bedienen“ angezeigt werden, kann dazu beitragen, deine Webseite schneller und für die Besucher besser nutzbar zu machen.

Wenn du diese Warnung in Google PageSpeed Insights siehst, kannst du es lösen, indem du:

  1. Cache-Control oder Expires-Headern hinzufügst.
  2. Browser-Caching für Google Analytics nutzt.
  3. Die Verwendung von Skripten Dritter minimierst.

Hast du noch andere Tipps, wie man das Leverage Browser Caching reparieren kann? Lass es uns im Kommentarbereich unten wissen!

Jon Penland

Jon is the Chief Operating Officer at Kinsta and is involved with Kinsta's sales, customer service, and technical support teams on a daily basis. Jon's a family man. So when he isn't feverishly tapping the keys of his laptop he's usually helping one of his kids fix a bike or setting up Netflix for an impatient preschooler.