Siehst du die Warnung „Specify a cache validator” („Cache-Validator angeben“) in Pingdom, GTmetrix oder Google PageSpeed Insights? Dies bezieht sich auf fehlende HTTP-Caching-Header, die in jeder Antwort des Ursprungsservers enthalten sein sollten, da sie die Länge des Caches validieren und festlegen. Wenn die Header nicht gefunden werden, wird jedes Mal eine neue Anforderung für die Ressource generiert, was die Belastung deines Servers erhöht. Durch die Verwendung von Cache-Headern wird sichergestellt, dass nachfolgende Anforderungen nicht vom Server geladen werden müssen. Dadurch wird Bandbreite gespart und die Leistung für den User verbessert.
Die Warnung von Pingdom besagt:
Bei den folgenden Ressourcen fehlt ein Cache-Validator. Ressourcen, die keinen Cache-Validator angeben, können nicht effizient aktualisiert werden. Gib einen Last-Modified- oder ETag-Header an, um die Cache-Überprüfung für die folgenden Ressourcen zu aktivieren.
Führe die folgenden Schritte aus um die Warnung „Specify a Cache Validator” zu beheben.
Behebe die Warnung „Specify a Cache Validator”
Wichtig zu dieser Warnung ist zunächst Folgendes: du kannst dies nur für Anfragen beheben, die sich auf deinem Server befinden. Wenn du Anfragen von Drittanbietern siehst, kannst du dies nicht tun, da du keine Kontrolle über ihre Webserver hast. Fühle dich jedoch frei, diesen Artikel mit ihnen zu teilen. Und denke daran, mit Pingdom musst du den Test möglicherweise einige Male ausführen. Es kann sein, dass die Warnung beim ersten Mal angezeigt wird und beim zweiten Mal nicht mehr angezeigt wird. Wenn du das Tool zum ersten Mal ausführst, wird der Cache der Assets vom Server geladen.
Es gibt vier verschiedene Arten von Headern, die auf verschiedene Arten verwendet werden können, um diese Warnung zu beheben. Hier kann es etwas verwirrend werden, aber wir werden versuchen, es so einfach wie möglich zu erklären.
Header, die den Cache überprüfen
Die ersten beiden Header sind last-modified und ETag. Diese Header helfen dem Browser zu bestimmen, ob sich seit der letzten Anforderung die Datei geändert hat. Oder sie validieren den Cache.
1. Last-Modified
Der last-modified (zuletzt geänderter) Header wird im Allgemeinen automatisch vom Server gesendet. Dies ist ein Header, den du im Allgemeinen nicht manuell hinzufügen musst. Er wird gesendet, um zu sehen, ob die Datei im Cache des Browsers seit der letzten Anforderung geändert wurde. Du kannst die Header-Anfrage in Pingdom anzeigen oder Chrome DevTools verwenden, um den Wert des last-modified (zuletzt geänderten) Headers anzuzeigen.
2. ETag
Der ETag-Header ist dem last-modified (zuletzt geänderten) Header sehr ähnlich. Er wird auch verwendet, um den Cache einer Datei zu überprüfen. Wenn du Apache 2.4 oder höher ausführst, wird der ETag-Header bereits automatisch mit der FileETag directive hinzugefügt. Und was NGINX angeht, ist der ETag-Header seit 2016 standardmäßig aktiviert.
Du kannst in NGINX den ETag-Header manuell aktivieren, indem du folgenden Code verwendest.
etag onHeader, welche die Cache-Länge bestimmen
Die nächsten beiden Header sind Cache-Control und Expires. Diese Header helfen zu bestimmen, wie lange die Datei im Cache gehalten werden soll, bevor eine neue Kopie vom Server abgerufen wird. Denke daran, um die in Pingdom oder GTmetrix angezeigten Warnungen zu beheben, musst du sicherstellen, dass du über einen Header verfügst, der sowohl den Cache überprüft, als auch einen, der die Cache-Länge bestimmt.
3. Cache-Control
Cache-Control ist ein Header, der aus verschiedenen Anweisungen besteht, mit denen du die Länge des Caches definieren kannst. Einige der häufigsten Richtlinien sind:
- max-age: Definiert die Zeitdauer, für die eine Datei zwischengespeichert werden soll.
- public: Der Cache kann die Antwort öffentlich speichern.
- private: Nur zwischengespeichert, wenn der Browser auf die Datei zugreift.
In unserem obigen Beispiel kannst du sehen, dass das Asset die Max-Age-Direktive verwendet. 604800 Sekunden würden einem Cache von sieben Tagen entsprechen. Um dies in Apache zu konfigurieren, füge deiner .htaccess-Datei einfach den folgenden Code hinzu.
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=604800, public"
Um dies in NGINX zu konfigurieren, füge einfach den folgenden Code in deine Konfigurationsdatei ein. Alle NGINX-Konfigurationsdateien befinden sich im Verzeichnis /etc/nginx/. Die primäre Konfigurationsdatei lautet /etc/nginx/nginx.conf.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
add_header Cache-Control "public";
}Um mehr über die verschiedenen Richtlinien zu erfahren, lies diesen ausführlichen Artikel über Cache-Control.
4. Expires
Und zuletzt hast du den Header „Expires“. In diesem Artikel von Google Developers heißt HTTP Caching: Der Cache-Control-Header wurde als Teil der HTTP / 1.1-Spezifikation definiert und ersetzt vorherige Header (in diesem Fall den Expires-Header), die zum Definieren von Richtlinien für das Zwischenspeichern von Antworten verwendet werden. Alle modernen Browser unterstützen Cache-Control, das ist alles, was du brauchst. Es wird jedoch nichts schaden, wenn du beide hast. Denke jedoch daran, dass nur einer verwendet wird. Der Expires-Header verwendet ein tatsächliches Datum, während du mit dem Cache-Control-Header eine Zeit vor dem Ablauf angeben können.
Um Expires-Header in Apache zu konfigurieren, füge deiner .htaccess-Datei einfach den folgenden Code hinzu.
## 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 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 7 days"
## EXPIRES HEADER CACHING ##Stelle sicher, dass du deinen Expires-Header-Block unter Dingen wie mod_rewrite, GZIP usw. hinzufügen. Am Ende der Datei ist am sichersten.
Um Expires-Header in NGINX zu konfigurieren, füge einfach den folgenden Code in deine Konfigurationsdatei ein.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 7d;
}In vielen Fällen werden bei NGINX sowohl der Cache-Control-Header als auch der Expires-Header einfach zusammen verwendet, auch wenn dies technisch nicht erforderlich ist:
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 7d;
add_header Cache-Control "public";
}Alle oben genannten Header werden standardmäßig auf allen Kinsta-Servern hinzugefügt. Wenn du ein Kinsta-Kunde bist, wirst du diese Warnung nicht sehen und musst dir keine Sorgen machen. Die meisten CDN-Drittanbieter, wie KeyCDN und Cloudflare, fügen diese Header bei der Bereitstellung deiner Assets automatisch hinzu. Wenn du die Warnungen siehst, kann es sein, dass dein Hoster nicht mehr aktuell ist oder der Server falsch konfiguriert ist. Normalerweise sehen wir dies auf Shared Hostern. Oder du richtest deinen eigenen Server ein. In diesem Fall werden einige der Header möglicherweise noch nicht hinzugefügt.
Und wenn alles gut geht und du keine Drittanbieteranfragen hast, bei denen der Header nicht korrekt verwendet wird, solltest du eine Verbesserung deines Score mit Website-Geschwindigkeitstest-Tools wie Pingdom (siehe unten) sehen.
