Crawling de décembre : mise en cache HTTP

Lundi 9 décembre 2024

Autorisez-nous à mettre en cache, s’il vous plaît.

À mesure qu’Internet s’est développé au fil des ans, l’ampleur du crawling de Google a également augmenté. Bien que l’infrastructure de crawling de Google prenne en charge des mécanismes de mise en cache heuristique, et ce depuis toujours, le nombre de requêtes pouvant être renvoyées à partir de caches locaux a diminué : il y a 10 ans, environ 0,026 % du total des récupérations étaient mises en cache, ce qui n’est déjà pas très impressionnant ; aujourd’hui, ce chiffre est de 0,017 %.

Pourquoi la mise en cache est-elle importante ?

La mise en cache est une pièce essentielle du grand puzzle qu’est Internet. La mise en cache permet aux pages de se charger à la vitesse de l’éclair lors des visites répétées, elle économise des ressources informatiques et donc aussi des ressources naturelles, et économise une quantité énorme de bande passante coûteuse pour les clients comme pour les serveurs.

Surtout si vous avez un grand site avec du contenu changeant rarement sous des URL individuelles, autoriser la mise en cache localement peut aider votre site à être crawlé plus efficacement. L’infrastructure de crawling de Google prend en charge la mise en cache HTTP heuristique telle que définie par le
standard de mise en cache HTTP, spécifiquement via l’en-tête de réponse ETag et l’en-tête de requête If-None-Match , ainsi que l’en-tête de réponse Last-Modified et l’en-tête de requête If-Modified-Since .

Nous recommandons fortement d’utiliser ETag car il est moins sujet aux erreurs et aux fautes (la valeur n’est pas structurée contrairement à la valeur Last-Modified ). Et, si vous en avez la possibilité, configurez les deux : Internet vous remerciera. Peut-être.

Quant à ce que vous considérez comme un changement nécessitant que les clients rafraîchissent leurs caches, c’est à vous de décider. Notre recommandation est que vous exigiez un rafraîchissement du cache lors de changements significatifs de votre contenu ; si vous avez seulement mis à jour la date de copyright au bas de votre page, ce n’est probablement pas significatif.

ETag et If-None-Match

Les crawlers de Google prennent en charge les requêtes conditionnelles basées sur ETag exactement comme défini dans le
standard de mise en cache HTTP. C’est-à-dire, pour signaler la préférence de mise en cache aux crawlers de Google, définissez la valeur Etag sur n’importe quelle chaîne ASCII arbitraire (généralement un hash du contenu ou un numéro de version, mais cela pourrait aussi être un morceau de π, c’est à vous de voir) unique à la représentation du contenu hébergé par l’URL accédée. Par exemple, si vous hébergez différentes versions du même contenu sous la même URL (disons, version mobile et version bureau), chaque version pourrait avoir sa propre valeur ETag unique.

Les crawlers de Google qui prennent en charge la mise en cache enverront la valeur ETag renvoyée pour un crawling précédent de cette URL dans l’en-tête If-None-Match header. Si la valeur ETag
envoyée par le crawler correspond à la valeur actuelle générée par le serveur, votre serveur devrait renvoyer un code d’état HTTP 304 (Non modifié) sans corps HTTP. Ce dernier point, l’absence de corps HTTP, est important pour plusieurs raisons :

• votre serveur n’a pas à dépenser de ressources informatiques pour générer réellement du contenu ; c’est-à-dire que vous économisez de l’argent
• votre serveur n’a pas à transférer le corps HTTP ; c’est-à-dire que vous économisez de l’argent

Côté client, comme le navigateur d’un utilisateur ou Googlebot, le contenu sous cette URL est récupéré depuis le cache interne du client. Comme il n’y a pas de transfert de données, cela se produit à la vitesse de l’éclair, ce qui rend les utilisateurs heureux et économise potentiellement des ressources pour eux aussi.

Last-Modified et If-Modified-Since

De manière similaire à ETag, les crawlers de Google prennent également en charge les requêtes conditionnelles basées sur Last-Modified based
, exactement comme défini dans le standard de mise en cache HTTP. Cela fonctionne de la même manière que ETag d’un point de vue sémantique — un identifiant est utilisé pour décider si la ressource est mise en cache — et offre les mêmes avantages que ETag côté client.

Nous n’avons que quelques recommandations si vous utilisez Last-Modified comme directive de mise en cache :

1. La date dans l’en-tête Last-Modified doit être formatée conformément au
   standard HTTP. Pour éviter les problèmes d’analyse, nous recommandons d’utiliser le format de date suivant : “Jour de la semaine, DD Mon YYYY HH:MM:SSFuseau horaire”. Par exemple,“.
2. ” Fri, 4 Sep 1998 19:15:56 GMT Bien que non obligatoire, envisagez également de définir le champ
   max-age de l’en-tête Cache-Control pour aider les crawlers à déterminer quand recrawler l’URL spécifique. Définissez la valeur du champ.

max-age

sur le nombre de secondes attendu pendant lequel le contenu restera inchangé. Par exemple, Cache-Control: max-age=94043/If-None-Match et un pour
Last-Modified/If-Modified-Since — pour visualiser comment cela est censé fonctionner :

Si vous avez pour objectif de rendre vos utilisateurs heureux et peut-être aussi d’économiser quelques euros sur votre facture d’hébergement, parlez à votre fournisseur d’hébergement ou CMS, ou à vos développeurs sur la façon d’activer la mise en cache HTTP pour votre site. Au moins, vos utilisateurs vous apprécieront un peu plus.

Si vous voulez discuter de la mise en cache, rendez-vous dans votre
communauté d’aide Search Centralla plus proche, et si vous avez des commentaires sur la façon dont nous mettons en cache, laissez un avis sur
la documentation sur la mise en cache
que nous avons publiée avec cet article de blog.

Publié par Gary Illyes

Vous voulez en savoir plus sur le crawl ? Consultez toute la série Crawling December :