Browser-Caching aktivieren

Wenn PageSpeed Insights oder Lighthouse „Statische Assets mit einer effizienten Cache-Richtlinie bereitstellen" meldet (die genaue Formulierung kann je nach Lighthouse-Version abweichen), wurden Dateien wie CSS, JavaScript, Schriften und Bilder gefunden, die mit einer kurzen oder gar keiner Cache-Lebensdauer ausgeliefert werden. Ohne eine passende Cache-Richtlinie lädt der Browser diese Assets bei jedem Besuch erneut, obwohl sie sich selten ändern. Eine lange, explizite Cache-Lebensdauer lässt wiederkehrende Besucher die lokale Kopie nutzen und den Download ganz überspringen. Dieser Leitfaden erklärt, wie Sie Browser-Caching aktivieren und die Warnung beheben, von Cache-Control bis zur .htaccess.

Was eine effiziente Cache-Richtlinie bedeutet

Browser-Caching speichert beim ersten Laden eine Kopie jedes statischen Assets auf dem Gerät des Besuchers. Beim nächsten Seitenaufruf oder beim nächsten Besuch kann der Browser diese Datei aus dem lokalen Cache liefern, statt sie erneut anzufordern. Welche Dateien wie lange gecacht werden, steuern HTTP-Antwort-Header, vor allem Cache-Control und, auf älteren Setups, Expires. Lighthouse prüft diese Header und meldet jedes statische Asset, dessen Cache-Lebensdauer zu kurz ist, denn jedes davon steht für einen Download, der sich hätte vermeiden lassen.

Cache-Control, Expires und ETag

Drei Header steuern das Caching, und sie greifen ineinander. Cache-Control ist der moderne, wichtigste Header, er legt mit max-age fest, wie lange eine Datei als frisch gilt, und mit public oder private, wer sie cachen darf. Expires ist der ältere Weg mit einem festen Ablaufdatum, überall noch verstanden, aber von Cache-Control überschrieben, wenn beide vorhanden sind. Der ETag ist eine Kennung des Dateiinhalts, mit der der Browser nach Ablauf effizient nachfragen kann, ob sich etwas geändert hat, statt die Datei blind neu zu laden. Für statische, versionierte Assets genügt ein langes Cache-Control, der ETag ist vor allem für Dateien nützlich, die sich unter gleicher URL ändern.

Warum es für die Performance zählt

Diese Prüfung betrifft weniger den ersten Besuch als jeden weiteren, dazu die Navigation zwischen den Seiten Ihrer Website. Sind Assets mit langer Lebensdauer gecacht, lädt ein wiederkehrender Besucher die Seite mit weit weniger Netzwerkanfragen, was sie nahezu sofort wirken lässt. Es entlastet außerdem Ihren Server, weil er seltener nach denselben Dateien gefragt wird. Das verbindet die Aufgabe mit Ihrer Serverantwortzeit: weniger wiederholte Anfragen bedeuten weniger Arbeit für den Ursprung. Den allerersten, ungecachten Aufruf ändert es meist nicht, behandeln Sie es also als Gewinn für Wiederholbesuche und Effizienz, nicht als Fix für den ersten Farbauftrag. Weil die Core Web Vitals reale Erfahrungen über Sitzungen hinweg abbilden, stützt eine solide Cache-Richtlinie sie über die Zeit. Auf Seiten mit vielen wiederkehrenden Besuchern, etwa Blogs, Shops und Web-Apps, ist der Effekt am größten, weil dort dieselben Assets über viele Sitzungen hinweg wiederverwendet werden.

Eine effiziente Cache-Richtlinie setzen

1. Eine lange Cache-Control-Lebensdauer festlegen

Statischen Assets ein langes max-age in Sekunden geben und sie als öffentlich markieren, damit sie gecacht werden dürfen. Ein Jahr ist die übliche Wahl für Assets, die eine Version im Namen tragen:

Cache-Control: public, max-age=31536000, immutable

Die Direktive immutable sagt dem Browser, dass sich die Datei unter dieser URL nie ändert, sodass er nicht einmal eine Rückfrage stellt. Für private, nutzerspezifische Antworten private statt public verwenden, und für Dateien, die sich unter gleicher URL ändern können, eine kürzere Lebensdauer oder eine Revalidierung wählen.

2. Auf Apache über die .htaccess konfigurieren

Auf einem Apache-Server lassen sich Ablauf und Header direkt setzen:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType application/javascript "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch "\.(css|js|webp|avif|jpg|png|woff2)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

3. Dateinamen versionieren, damit langes Caching sicher ist

Die naheliegende Sorge bei einem Jahres-Cache ist, wie man ein Update ausspielt. Die Antwort ist Fingerprinting: einen Inhalts-Hash in den Dateinamen aufnehmen, etwa app.9f2a1c.css. Ändert sich die Datei, ändert sich ihr Name, sodass der Browser die neue URL lädt, während er die alte weiterhin aggressiv cacht. Die meisten Build-Werkzeuge fügen diese Hashes automatisch hinzu, was eine aggressive Cache-Richtlinie völlig sicher macht.

4. Ein CDN nutzen

Ein Content Delivery Network wendet standardmäßig lange Cache-Lebensdauern auf statische Assets an und liefert sie aus einem Standort nahe dem Besucher. Wer bereits ein CDN nutzt, prüft dessen Cache-Header gegen die Schwelle, statt sie doppelt zu setzen. Viele CDNs erlauben zudem, die Lebensdauer je Dateityp zentral zu steuern, was die Pflege gegenüber verstreuten Server-Regeln vereinfacht.

5. Die Grenzen von Drittanbieter-Assets akzeptieren

Einige gemeldete Dateien sind Drittanbieter-Skripte von einer anderen Domain, deren Header Sie nicht setzen können. Diese lassen sich nicht direkt beheben. Konzentrieren Sie sich auf Ihre eigenen statischen Assets, und ziehen Sie für schwere Drittanbieter-Skripte, wo die Lizenz es erlaubt, das Selbst-Hosten in Betracht, was auch deren Caching unter Ihre Kontrolle bringt.

6. In WordPress ohne Code

Die meisten Caching-Plugins setzen die richtigen Cache-Header für statische Assets, ohne die .htaccess von Hand zu bearbeiten. Ein Plugin mit Browser-Caching-Funktion aktivieren und prüfen, dass Theme und weitere Plugins keine kürzeren Header überschreiben. Auf Servern ohne Apache übernimmt oft die Server- oder CDN-Konfiguration diese Aufgabe.

Den Fix prüfen

Die Antwort-Header inspizieren, um die Cache-Richtlinie zu bestätigen:

curl -I https://example.com/app.css

Auf einen Cache-Control-Header mit langem max-age achten. Dann PageSpeed Insights erneut ausführen und bestätigen, dass die gemeldeten Assets von der Liste verschwunden sind, wobei verbleibende Einträge meist Drittanbieter-Dateien außerhalb Ihrer Kontrolle sind. Im Netzwerk-Panel der DevTools sollte ein erneuter Aufruf die gecachten Assets aus dem Arbeitsspeicher- oder Festplatten-Cache zeigen, statt sie neu zu laden. Der zweite Aufruf sollte für die statischen Dateien den Status aus dem Cache und keine erneute Übertragung ausweisen.

Häufige Fragen

Was ist eine effiziente Cache-Richtlinie?

Ein Satz HTTP-Header, vor allem Cache-Control, der dem Browser sagt, statische Assets lange lokal zu speichern, damit wiederkehrende Besucher sie wiederverwenden, statt sie erneut zu laden.

Welche Cache-Lebensdauer sollte ich verwenden?

Ein Jahr, ausgedrückt als max-age=31536000, ist die übliche Wahl für statische Assets, kombiniert mit immutable. Das ist sicher, solange sich Dateinamen ändern, wenn sich der Inhalt ändert.

Verhindert ein langer Cache, dass Nutzer meine Updates sehen?

Nicht, wenn Sie Dateinamen versionieren. Ein Inhalts-Hash wie app.9f2a1c.css bedeutet, dass eine aktualisierte Datei eine neue URL hat, sodass der Browser sie sofort lädt, während er jede Version aggressiv cacht.

Wie setze ich Cache-Header auf Apache?

Über mod_expires und mod_headers in der .htaccess eine Expires-Zeit und einen Cache-Control-Header mit langem max-age für statische Dateitypen setzen.

Warum meldet die Prüfung nach dem Fix weiterhin einige Dateien?

Das sind meist Drittanbieter-Assets von einer anderen Domain, etwa Analyse- oder Werbeskripte, deren Header Sie nicht setzen können. Die eigenen Assets beheben und schwere Drittanbieter-Skripte, wo möglich, selbst hosten.

Welche Dateien sollte ich lange cachen?

Versionierte statische Assets wie CSS, JavaScript, Schriften und Bilder. Das HTML-Dokument selbst nur kurz oder gar nicht cachen, weil es sich bei jeder Änderung an Inhalt oder eingebundenen Dateien aktualisieren muss.