HTTP-Caching kann die Seitenladezeit bei wiederholten Besuchen verkürzen.
Wenn ein Browser eine Ressource anfordert, teilt der Server, der die Ressource bereitstellt, dem Browser mit, wie lange er die Ressource vorübergehend speichern oder zwischenspeichern soll. Bei jeder nachfolgenden Anfrage für diese Ressource verwendet der Browser die lokale Kopie, anstatt sie aus dem Netzwerk abzurufen.
So schlägt die Prüfung der Lighthouse-Cache-Richtlinie fehl
Lighthouse kennzeichnet alle statischen Ressourcen, die nicht im Cache gespeichert sind:
Lighthouse betrachtet eine Ressource als im Cache speicherbar, wenn die folgenden Bedingungen erfüllt sind:
- Die Ressource ist eine Schriftart, ein Bild, eine Mediendatei, ein Skript oder ein Stylesheet.
- Die Ressource hat den HTTP-Statuscode
200,203oder206. - Die Ressource hat keine explizite No-Cache-Richtlinie.
Wenn eine Seite die Prüfung nicht besteht, listet Lighthouse die Ergebnisse in einer Tabelle mit drei Spalten auf:
| URL | Der Standort der im Cache speicherbaren Ressource |
| Cache-TTL | Die aktuelle Cache-Dauer der Ressource |
| Übertragungsgröße | Eine Schätzung der Daten, die Ihre Nutzer speichern würden, wenn die gemeldete Ressource im Cache gespeichert worden wäre |
Statische Ressourcen mit HTTP-Caching im Cache speichern
Konfigurieren Sie Ihren Server so, dass er den HTTP-Antwortheader Cache-Control zurückgibt:
Cache-Control: max-age=31536000
Die Anweisung max-age teilt dem Browser mit, wie lange die Ressource in Sekunden zwischengespeichert werden soll.
In diesem Beispiel wird die Dauer auf 31536000 festgelegt, was einem Jahr entspricht: 60 Sekunden × 60 Minuten × 24 Stunden × 365 Tage = 3.153.6000 Sekunden.
Sie sollten unveränderliche statische Assets für einen längeren Zeitraum im Cache speichern, z. B. für ein Jahr oder länger.
Verwenden Sie no-cache, wenn sich die Ressourcen ändern und die Aktualität der Ressourcen wichtig ist, Sie aber dennoch einige der Geschwindigkeitsvorteile des Cachings nutzen möchten.
Eine Ressource, die auf no-cache festgelegt ist, wird im Browser weiterhin im Cache gespeichert, aber zuerst wird vom Server geprüft, ob die Ressource noch aktuell ist.
Eine längere Cache-Dauer ist nicht immer besser. Letztendlich müssen Sie selbst entscheiden, wie die optimale Cache-Dauer für Ihre Ressourcen aussehen soll.
Es gibt viele Anweisungen, mit denen Sie anpassen können, wie der Browser verschiedene Ressourcen im Cache speichert. Weitere Informationen zum Caching von Ressourcen finden Sie unter HTTP-Cache: erste Maßnahme – Leitfaden und Codelab zum Konfigurieren des HTTP-Caching-Verhaltens.
Im Cache gespeicherte Antworten in den Chrome-Entwicklertools prüfen
Auf dem Tab Netzwerk in den Chrome-Entwicklertools können Sie sehen, welche Ressourcen der Browser aus seinem Cache erhält:
[Kommentar]: <> (Die folgende Liste war ein Kurzcode von web.dev, wurde aber in keine andere Sprache übersetzt.)
1. Drücken Sie Control+Shift+J (oder Command+Option+J auf einem Mac), um die Entwicklertools zu öffnen.
2. Klicken Sie auf den Tab Network (Netzwerk).
Anhand der Spalte Größe in den Chrome-Entwicklertools können Sie überprüfen, ob eine Ressource im Cache gespeichert wurde:
Chrome stellt die am häufigsten angeforderten Ressourcen aus dem Arbeitsspeicher-Cache bereit. Dies ist sehr schnell, wird jedoch gelöscht, wenn der Browser geschlossen wird.
Wenn Sie prüfen möchten, ob der Cache-Control-Header einer Ressource wie erwartet festgelegt ist, prüfen Sie die zugehörigen HTTP-Header-Daten:
- Klicken Sie in der Tabelle „Anfragen“ in der Spalte Name auf die URL der Anfrage.
- Klicken Sie auf den Tab Headers.
Cache-Control-Header auf dem Tab Headers.
Stackspezifische Anleitung
Drupal
Legen Sie auf der Seite Administration > Konfiguration > Entwicklung den Wert für Browser- und Proxy-Cache-Höchstalter fest. Siehe Drupal-Leistungsressourcen.
Joomla
Siehe Cache.
WordPress
Siehe Browser-Caching.