Crawling Dezember: HTTP-Caching

Montag, 9. Dezember 2024

Erlauben Sie uns das Caching, bitte.

Während das Internet im Laufe der Jahre wuchs, wuchs auch das Ausmaß, in dem Google crawlt. Obwohl die Crawling-Infrastruktur von Google heuristische Caching-Mechanismen unterstützt – und das eigentlich schon immer tat –, ist die Anzahl der Anfragen, die aus lokalen Caches zurückgegeben werden können, gesunken: Vor 10 Jahren waren etwa 0,026 % der gesamten Abrufe cachefähig, was bereits nicht besonders beeindruckend ist; heute liegt diese Zahl bei 0,017 %.

Warum ist Caching wichtig?

Caching ist ein entscheidendes Teil des großen Puzzles, das das Internet ist. Caching ermöglicht es, dass Seiten bei erneuten Besuchen blitzschnell geladen werden, es spart Rechenressourcen und damit auch natürliche Ressourcen und spart eine enorme Menge an teurer Bandbreite sowohl für Clients als auch für Server.

Besonders wenn Sie eine große Website mit selten ändernden Inhalten unter individuellen URLs haben, kann das lokale Caching dazu beitragen, dass Ihre Website effizienter gecrawlt wird. Die Crawling-Infrastruktur von Google unterstützt heuristisches HTTP-Caching, wie es durch den
HTTP-Caching-Standarddefiniert ist, insbesondere durch den ETag Antwort- und If-None-Match Anfrage-Header sowie den Last-Modified Antwort- und If-Modified-Since Anfrage-Header.

Wir empfehlen dringend die Verwendung von ETag , da es weniger anfällig für Fehler und Irrtümer ist (der Wert ist im Gegensatz zum Last-Modified Wert nicht strukturiert). Und wenn Sie die Option haben, setzen Sie beides: Das Internet wird es Ihnen danken. Vielleicht.

Was Sie als Änderung betrachten, die Clients dazu zwingt, ihre Caches zu aktualisieren, bleibt Ihnen überlassen. Unsere Empfehlung ist, dass Sie eine Cache-Aktualisierung bei signifikanten Änderungen an Ihrem Inhalt verlangen; wenn Sie nur das Copyright-Datum am Ende Ihrer Seite aktualisiert haben, ist das wahrscheinlich nicht signifikant.

ETag und If-None-Match

Die Crawler von Google unterstützen ETag basierte bedingte Anfragen genau so, wie es im
HTTP-Caching-Standarddefiniert ist. Das heißt, um Google-Crawlern die Caching-Präferenz zu signalisieren, setzen Sie den Etag Wert auf eine beliebige ASCII-Zeichenfolge (normalerweise ein Hash des Inhalts oder eine Versionsnummer, aber es könnte auch ein Teil von π sein, ganz wie Sie möchten), die für die Darstellung des Inhalts unter der aufgerufenen URL eindeutig ist. Wenn Sie beispielsweise verschiedene Versionen desselben Inhalts unter derselben URL hosten (z. B. mobile und Desktop-Version), könnte jede Version ihren eigenen eindeutigen ETag Wert haben.

Google-Crawler, die Caching unterstützen, senden den ETag Wert, der bei einem vorherigen Crawl 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 Ihr Server einen HTTP 304 (Nicht modifiziert) Statuscode ohne HTTP-Body zurückgeben. Dieser letzte Teil, kein HTTP-Body, ist aus ein paar Gründen wichtig:

• Ihr Server muss keine Rechenressourcen für die tatsächliche Generierung von Inhalten aufwenden; das heißt, Sie sparen Geld
• Ihr Server muss den HTTP-Body nicht übertragen; das heißt, Sie sparen Geld

Auf der Client-Seite, wie bei einem Benutzerbrowser oder Googlebot, wird der Inhalt unter dieser URL aus dem internen Cache des Clients abgerufen. Da keine Datenübertragung stattfindet, geschieht dies blitzschnell, was die Benutzer glücklich macht und möglicherweise auch für sie Ressourcen spart.

Last-Modified und If-Modified-Since

Ähnlich wie bei ETagunterstützen Google-Crawler auch Last-Modified basierte
bedingte Anfragen, genau wie im HTTP-Caching-Standard definiert. Dies funktioniert aus semantischer Sicht genauso wie ETag – ein Identifikator wird verwendet, um zu entscheiden, ob die Ressource cachefähig ist –, und bietet die gleichen Vorteile wie ETag auf der Client-Seite.

Wir haben nur ein paar Empfehlungen, wenn Sie Last-Modified als Caching-Direktive verwenden:

1. Das Datum im Last-Modified Header muss gemäß dem
   HTTP-Standardformatiert sein. Um Parsing-Probleme zu vermeiden, empfehlen wir die Verwendung des folgenden Datumsformats: “Wochentag, DD Mon YYYY HH:MM:SSZeitzone”. Zum Beispiel,“.
2. ” Fri, 4 Sep 1998 19:15:56 GMT Obwohl nicht erforderlich, sollten Sie auch in Betracht ziehen, das
   max-age Feld des Cache-Control Headers zu setzen, um Crawlern zu helfen, zu bestimmen, wann die spezifische URL erneut gecrawlt werden soll. Setzen Sie den Wert des.

max-age

Feldes auf die erwartete Anzahl von Sekunden, in denen der Inhalt unverändert bleibt. Zum Beispiel, Cache-Control: max-age=94043/If-None-Match und eines für
Last-Modified/If-Modified-Since — um zu visualisieren, wie es funktionieren soll:

Wenn Sie Ihre Nutzer glücklich machen und vielleicht auch ein paar Euro bei Ihrer Hosting-Rechnung sparen möchten, sprechen Sie mit Ihrem Hosting- oder CMS-Anbieter oder Ihren Entwicklern darüber, wie Sie HTTP-Caching für Ihre Website aktivieren können. Zumindest werden Ihre Nutzer Sie ein wenig mehr mögen.

Wenn Sie über Caching chatten möchten, besuchen Sie Ihre nächste
Search Central-Hilfe-Community, und wenn Sie Kommentare dazu haben, wie wir cachen, hinterlassen Sie Feedback in
der Dokumentation über Caching
, die wir zusammen mit diesem Blogbeitrag veröffentlicht haben.

Gepostet von Gary Illyes

Möchten Sie mehr über das Crawling erfahren? Sehen Sie sich die gesamte Crawling December-Serie an: