Crawling im Dezember: HTTP-Caching

Montag, 9. Dezember 2024

Bitte erlaubt uns, den Cache zu verwenden.

Mit dem Wachstum des Internets hat auch das Crawling durch Google zugenommen. Die Crawling-Infrastruktur von Google unterstützt heuristische Caching-Mechanismen, was schon immer der Fall war. Die Anzahl der Anfragen, die aus lokalen Caches zurückgegeben werden können, ist jedoch gesunken: Vor 10 Jahren waren etwa 0,026% der gesamten Abrufe im Cache speicherbar, was schon nicht besonders beeindruckend ist. Heute liegt diese Zahl bei 0,017%.

Warum ist das Caching wichtig?

Das Caching ist ein wichtiger Teil des großen Puzzles, das das Internet ist. Durch das Caching können Seiten bei wiederholten Besuchen blitzschnell geladen werden. Außerdem werden Rechenressourcen und damit auch natürliche Ressourcen gespart. Außerdem wird eine enorme Menge an teurer Bandbreite sowohl für die Clients als auch für die Server gespart.

Vor allem bei einer großen Website mit selten wechselnden Inhalten unter einzelnen URLs kann das lokale Caching dazu beitragen, dass eure Website effizienter gecrawlt wird. Die Crawling-Infrastruktur von Google unterstützt heuristisches HTTP-Caching gemäß dem HTTP-Caching-Standard, insbesondere über die ETag-Antwort- und If-None-Match-Anfrageheader sowie die Last-Modified-Antwort- und If-Modified-Since-Anfrageheader.

Wir empfehlen dringend die Verwendung von ETag, da dieser Wert weniger anfällig für Fehler ist (im Gegensatz zum Wert Last-Modified). Wenn ihr die Möglichkeit habt, solltet ihr beides festlegen. Das Internet wird es euch danken. Vielleicht.

Was ihr als Änderung betrachtet, die dazu führt, dass Clients ihre Caches aktualisieren müssen, liegt ganz bei euch. Wir empfehlen, den Cache bei wesentlichen Änderungen an euren Inhalten zu aktualisieren. Wenn ihr nur das Urheberrechtsdatum unten auf der Seite aktualisiert habt, ist das wahrscheinlich nicht wesentlich.

ETag und If-None-Match

Die Crawler von Google unterstützen ETag-basierte bedingte Anfragen genau wie im HTTP-Caching-Standard definiert. Wenn ihr den Crawlern von Google die Caching-Vorgaben signalisieren möchtet, legt den Wert für Etag auf einen beliebigen ASCII-String fest (normalerweise ein Hashwert der Inhalts- oder Versionsnummer, aber es kann auch etwas anderes sein). Dieser String muss eindeutig für die Darstellung der Inhalte sein, die über die aufgerufene URL gehostet werden. Wenn ihr beispielsweise verschiedene Versionen derselben Inhalte unter derselben URL hostet (z. B. eine mobile und eine Desktopversion), kann jede Version einen eigenen eindeutigen ETag-Wert haben.

Die Crawler von Google, die das Caching unterstützen, senden den ETag-Wert, der bei einem vorherigen Crawling dieser URL zurückgegeben wurde, im If-None-Match header. Wenn der vom Crawler gesendete ETag-Wert mit dem aktuellen Wert übereinstimmt, den der Server generiert hat, sollte der Server den HTTP-Statuscode 304 (Nicht geändert) ohne HTTP-Hauptteil zurückgeben. Dieser letzte Teil, kein HTTP-Hauptteil, ist aus mehreren Gründen wichtig:

  • Euer Server muss keine Rechenressourcen für die Erstellung von Inhalten aufwenden. Das spart Geld.
  • Euer Server muss den HTTP-Hauptteil nicht übertragen, d. h., ihr spart Geld.

Auf der Clientseite, z. B. im Browser eines Nutzers oder im Googlebot, werden die Inhalte unter dieser URL aus dem internen Cache des Clients abgerufen. Da keine Daten übertragen werden, geschieht dies blitzschnell, was die Nutzer zufriedenstellt und auch ihnen möglicherweise Ressourcen spart.

Last-Modified und If-Modified-Since

Ähnlich wie bei ETag unterstützen die Crawler von Google auch bedingte Last-Modified based-Anfragen, genau wie im HTTP-Caching-Standard definiert. Aus semantischer Sicht funktioniert das genauso wie ETag – anhand einer Kennung wird entschieden, ob die Ressource im Cache gespeichert werden kann. Außerdem bietet es die gleichen Vorteile wie ETag auf der Clientseite.

Wenn ihr Last-Modified als Caching-Richtlinie verwendet, haben wir ein paar Empfehlungen:

  1. Das Datum im Last-Modified-Header muss gemäß dem HTTP-Standard formatiert sein. Zur Vermeidung von Problemen beim Parsen empfehlen wir das folgende Datumsformat: „Wochentag, DD Mon YYYY HH:MM:SS Zeitzone“. Beispiel: "Fri, 4 Sep 1998 19:15:56 GMT".
  2. Es ist zwar nicht erforderlich, aber ihr könnt auch das Feld max-age des Cache-Control-Headers festlegen, damit Crawler besser bestimmen können, wann die jeweilige URL noch einmal gecrawlt werden soll. Legt den Wert des Felds max-age auf die voraussichtliche Anzahl von Sekunden fest, für die der Inhalt unverändert bleibt. Beispiel: Cache-Control: max-age=94043.

Beispiele

Vielleicht geht es euch wir mir: Ich finde es schwierig, mir vorzustellen, wie heuristisches Caching funktioniert. Ein Beispiel für die Abfolge von Anfragen und Antworten hilft mir jedoch dabei, es zu verstehen. Hier sind zwei Ketten – eine für ETag/If-None-Match und eine für Last-Modified/If-Modified-Since –, die veranschaulichen, wie das Ganze funktionieren soll:

ETag/If-None-Match Last-Modified/If-Modified-Since
Die Antwort eines Servers auf einen Crawling-Vorgang: Dies ist die Antwort, aus der ein Crawler die Vorbedingungs-Header-Felder ETag und Last-Modified speichern kann. 
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Fri, 4 Sep 1998 19:15:50 GMT
ETag: "34aa387-d-1568eb00"
...
 
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Fri, 4 Sep 1998 19:15:50 GMT
Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT
Cache-Control: max-age=94043
...
Bedingte Folgeanfrage des Crawlers: Die bedingte Anfrage basiert auf den Vorbedingungs-Headerwerten, die aus einer vorherigen Anfrage gespeichert wurden. Die Werte werden zur Validierung in den Anfrageheadern If-None-Match und If-Modified-Since an den Server zurückgesendet. 
GET /hello.world HTTP/1.1
Host: www.example.com
Accept-Language: en, hu
User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html)
If-None-Match: "34aa387-d-1568eb00"
...
 
GET /hello.world HTTP/1.1
Host: www.example.com
Accept-Language: en, hu
User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html)
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT
...
Serverantwort auf die bedingte Anfrage: Da die vom Crawler gesendeten Vorbedingungs-Headerwerte auf Serverseite validiert werden, gibt der Server einen 304-HTTP-Statuscode (ohne HTTP-Hauptteil) an den Crawler zurück. Dies geschieht bei jeder nachfolgenden Anfrage, bis die Vorbedingungen nicht mehr erfüllt sind (das ETag- oder das Last-Modified-Datum ändert sich auf der Serverseite). 
HTTP/1.1 304 Not Modified
Date: Fri, 4 Sep 1998 19:15:50 GMT
Expires: Fri, 4 Sep 1998 19:15:52 GMT
Vary: Accept-Encoding
If-None-Match: "34aa387-d-1568eb00"
...
 
HTTP/1.1 304 Not Modified
Date: Fri, 4 Sep 1998 19:15:50 GMT
Expires: Fri, 4 Sep 1998 19:15:51 GMT
Vary: Accept-Encoding
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT
...

Wenn ihr eure Nutzer zufriedenstellen und möglicherweise auch ein paar Euro bei eurer Hostingrechnung sparen möchtet, fragt euren Hosting- oder CMS-Anbieter oder eure Entwickler, wie ihr das HTTP-Caching für eure Website aktiviert. Zumindest werden eure Nutzer euch ein bisschen mehr mögen.

Wenn ihr über Caching sprechen möchtet, besucht das Search Central-Hilfeforum. Wenn ihr Kommentare zum Caching habt, könnt ihr uns Feedback zur Dokumentation zum Caching geben, die wir zusammen mit diesem Blogpost veröffentlicht haben.

Gepostet von Gary Illyes

Möchten Sie mehr über das Crawling erfahren? Hier finden Sie die gesamte Crawling-Dezember-Reihe: