Browser-Caching nutzen

Diese Regel gilt, wenn PageSpeed Insights feststellt, dass die Antwort von Ihrem Server keine expliziten Caching-Header enthält, oder wenn die Ressourcen den Angaben gemäß nur für kurze Zeit zwischengespeichert werden sollen.

Übersicht

Durch Browser-Caching für statische Ressourcen können Nutzer Zeit sparen, wenn sie Ihre Website mehr als einmal besuchen. Caching-Header sollten für sämtliche zwischenspeicherbaren statischen Ressourcen gelten, nicht nur für eine kleine Teilmenge davon, wie z. B. für Bilder. Zu den zwischenspeicherbaren Ressourcen gehören unter anderem JavaScript- und CSS-Dateien, Bilddateien und andere binäre Objektdateien wie z. B. Mediendateien und PDFs. HTML ist im Allgemeinen nicht statisch und sollte standardmäßig nicht als zwischenspeicherbar betrachtet werden. Überlegen Sie, welche Caching-Richtlinien für den HTML-Code Ihrer Website geeignet sind.

Empfehlungen

Aktivieren Sie das Browser-Caching für Ihren Server. Statische Ressourcen sollten eine Cache-Lebensdauer von mindestens einer Woche haben. Bei Drittanbieter-Ressourcen wie Werbeanzeigen oder Widgets sollte die Cache-Lebensdauer mindestens einen Tag betragen. Wir empfehlen für alle zwischenspeicherbaren Ressourcen die folgenden Einstellungen:

  • Legen Sie für Expires mindestens eine Woche fest, vorzugsweise bis zu ein Jahr. Wir bevorzugen Expires gegenüber Cache-Control: max-age, weil es breiter unterstützt wird. Legen Sie aber nicht mehr als ein Jahr fest, da dies gegen die RFC-Richtlinien verstößt.
  • Wenn Sie genau wissen, wann eine Ressource geändert wird, können Sie auch eine kürzere Ablauffrist angeben. Wenn Sie vermuten, dass eine Ressource bald geändert werden könnte, aber nicht den genauen Zeitpunkt wissen, sollten Sie eine lange Ablauffrist festlegen und URL-Fingerprinting verwenden. Letzteres wird weiter unten beschrieben.

Header der Typen "Expires" und "Cache-Control: max-age"

Diese Header geben den Zeitraum an, während dessen der Browser die zwischengespeicherte Ressource verwenden kann, ohne zu prüfen, ob auf dem Webserver eine neue Version verfügbar ist. Bei ihnen handelt es sich um starke Caching-Header, die ohne Bedingungen gelten. Nach ihrer Festlegung und dem Herunterladen der Ressource sendet der Browser erst dann wieder GET-Anforderungen für die Ressource, wenn das Ablaufdatum oder der maximale Zeitraum erreicht ist oder wenn der Cache vom Nutzer gelöscht wurde.

Header der Typen "Last-Modified" und "ETag"

Diese Header geben an, wie der Browser zum Zweck des Cachings prüfen soll, ob die Dateien identisch sind. Beim Last-Modified-Header ist es das Datum. Beim ETag-Header kann es ein beliebiger Wert sein, der eine Ressource eindeutig identifiziert. Hierfür werden oft Dateiversionen oder Inhalts-Hashes verwendet. Last-Modified ist insofern ein schwacher Caching-Header, als der Browser anhand einer Heuristik bestimmt, ob das Element aus dem Cache abgerufen wird oder nicht.

Diese Header ermöglichen dem Browser ein effizientes Aktualisieren seiner zwischengespeicherten Ressourcen. Dabei werden beim expliziten Neuladen der Seite durch den Nutzer bedingte GET-Anforderungen gesendet. Bedingte GET-Anforderungen erhalten nur dann eine vollständige Antwort, wenn die Ressource auf dem Server geändert wurde. Daher ist die Latenz geringer als bei vollständigen GET-Anforderungen.

Welche Caching-Header sollte ich verwenden?

Es ist wichtig, für alle zwischenspeicherbaren Ressourcen entweder Expires oder Cache-Control max-age und entweder Last-Modified oder ETag anzugeben. Es bringt nichts, sowohl Expires als auch Cache-Control: max-age oder sowohl Last-Modified als auch ETag anzugeben.

URL-Fingerprinting verwenden

Bei Ressourcen, die gelegentlich geändert werden, können wir den Browser die Ressource zwischenspeichern lassen, bis sie auf dem Server geändert wird. Im Fall einer Änderung teilt der Server dem Browser mit, dass eine neue Version verfügbar ist. Dazu weisen wir jeder Version der Ressource eine eindeutige URL zu. Wenn wir z. B. eine Ressource namens "my_stylesheet.css" haben, können wir die Datei in "my_stylesheet_fingerprint.css" umbenennen. Wenn die Ressource geändert wird, wird auch ihre ID und damit ihre URL geändert. Bei einer Änderung der URL ist der Browser gezwungen, die Ressource erneut abzurufen. Mithilfe von IDs können wir selbst für Ressourcen, die häufiger geändert werden, ein Ablaufdatum festlegen, das weit in der Zukunft liegt.

Oft wird für die IDs eine 128-Bit-Hexadezimalzahl verwendet, die den Hash des Dateiinhalts codiert.

Eine weitere Möglichkeit besteht darin, für jede neue Version der Anwendung ein neues Veröffentlichungsverzeichnis zu erstellen und die Assets jeder Version im mit der Version gekennzeichneten Verzeichnis zu platzieren. Dies hat folgenden Nachteil: Wenn ein Asset bei einem Versionswechsel unverändert bleibt, ändert sich trotzdem seine URL und es wird ein erneuter Download erzwungen. Bei der Verwendung von Inhalts-Hashes besteht dieses Problem nicht. Dafür ist das Verfahren aber ein wenig komplexer.