Lundi 9 décembre 2024
Autorisez la mise en cache, s'il vous plaît.
Le développement d'Internet s'est accompagné d'une explosion du volume de pages explorées par Google. Bien que l'infrastructure de Google pour l'exploration des sites Web prenne en charge les mécanismes de mise en cache heuristiques, et ce depuis toujours, le nombre de requêtes pouvant être renvoyées à partir des caches locaux a diminué.Il y a 10 ans, environ 0,026% du total des récupérations pouvait être 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 un élément essentiel d'Internet. Le cache permet de charger les pages à une vitesse fulgurante lorsque vous visitez de nouveau un site, d'économiser des ressources informatiques et donc des ressources naturelles, et d'économiser une quantité considérable de bande passante coûteuse pour les clients et les serveurs.
En particulier si vous disposez d'un site volumineux dont le contenu change rarement sous des URL individuelles, autoriser la mise en cache en local peut permettre d'explorer votre site plus efficacement. L'infrastructure d'exploration de Google prend en charge la mise en cache HTTP heuristique telle que définie par la norme de mise en cache HTTP, en particulier via l'en-tête de réponse ETag et de requête If-None-Match, ainsi que l'en-tête de réponse Last-Modified et de requête If-Modified-Since.
Nous vous recommandons vivement d'utiliser ETag, car il est moins sujet aux erreurs (la valeur n'est pas structurée, contrairement à la valeur Last-Modified). Et si vous avez la possibilité d'utiliser les deux, faites-le. Internet vous en sera reconnaissant. Peut-être.
C'est à vous de décider ce que vous considérez comme une modification nécessitant l'actualisation du cache par les clients. Nous vous recommandons d'exiger l'actualisation du cache en cas de modifications importantes de votre contenu. Si vous n'avez modifié que la date du copyright en bas de la page, il ne s'agit probablement pas d'une modification importante.
ETag et If-None-Match
Les robots d'exploration Google acceptent les requêtes conditionnelles basées sur ETag, exactement comme défini dans la norme de mise en cache HTTP.
Autrement dit, pour indiquer une préférence de mise en cache aux robots d'exploration Google, définissez la valeur Etag sur une chaîne ASCII arbitraire (généralement un hachage du contenu ou du numéro de version, mais il peut également s'agir d'une partie du π, à vous de voir) propre à la représentation du contenu hébergé par l'URL consultée.
Par exemple, si vous hébergez différentes versions du même contenu sous la même URL (par exemple, la version mobile et la version classique), chaque version peut avoir sa propre valeur ETag.
Les robots d'exploration Google qui prennent en charge la mise en cache envoient la valeur ETag renvoyée lors d'un précédent exploration de cette URL dans If-None-Match header. Si la valeur ETag envoyée par le robot d'exploration correspond à la valeur actuelle générée par le serveur, votre serveur doit renvoyer un code d'état HTTP 304 (Non modifié) sans corps HTTP. Ce dernier élément, l'absence de corps HTTP, est important pour plusieurs raisons:
- votre serveur n'a pas besoin de consommer de ressources de calcul pour générer du contenu. Autrement dit, vous économisez de l'argent ;
- votre serveur n'a pas besoin de transférer le corps HTTP, ce qui vous permet d'économiser de l'argent.
Côté client, comme le navigateur d'un utilisateur ou Googlebot, le contenu sous cette URL est récupéré à partir du cache interne du client. Comme aucun transfert de données n'est effectué, l'opération est extrêmement rapide, ce qui réjouit les utilisateurs et leur permet d'économiser des ressources.
Last-Modified et If-Modified-Since
Comme pour ETag, les robots d'exploration Google acceptent également les requêtes conditionnelles Last-Modified based, exactement comme défini dans la norme de mise en cache HTTP. D'un point de vue sémantique, cela fonctionne comme ETag : un identifiant est utilisé pour déterminer si la ressource peut être mise en cache. Cette approche présente les mêmes avantages que ETag côté client.
Nous avons quelques recommandations si vous utilisez Last-Modified comme directive de mise en cache:
-
Le format de la date dans l'en-tête
Last-Modifieddoit respecter la norme HTTP. Pour éviter les problèmes d'analyse, nous vous recommandons d'utiliser le format de date suivant : "Jour de la semaine, DD Mon YYYY HH:MM:SS Fuseau horaire" (par exemple, "Fri, 4 Sep 1998 19:15:56 GMT"). -
Bien que cela ne soit pas obligatoire, vous pouvez également définir le champ
max-agede l'en-têteCache-Controlpour aider les robots d'exploration à déterminer quand réexplorer l'URL spécifique. Définissez la valeur du champmax-agesur la durée prévue, en secondes, pendant laquelle le contenu ne changera pas. Exemple :Cache-Control: max-age=94043.
Exemples
Si vous avez un peu de mal à comprendre le fonctionnement de la mise en cache heuristique, voici un exemple de la chaîne de requêtes et de réponses pour vous aider. Voici deux chaînes, l'une pour ETag/If-None-Match et l'autre pour Last-Modified/If-Modified-Since, qui permettent de visualiser le fonctionnement de cette méthode de mise en chache :
ETag/If-None-Match |
Last-Modified/If-Modified-Since |
|
|---|---|---|
Réponse d'un serveur à une exploration : il s'agit de la réponse à partir de laquelle un robot d'exploration peut enregistrer les champs d'en-tête de condition préalable ETag et Last-Modified.
|
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 ... |
Requête conditionnelle du robot d'exploration ultérieure : la requête conditionnelle est basée sur les valeurs d'en-tête de condition préalable enregistrées à partir d'une requête précédente. Les valeurs sont renvoyées au serveur pour validation dans les en-têtes de requête If-None-Match et If-Modified-Since.
|
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 ... |
Réponse du serveur à la requête conditionnelle : étant donné que les valeurs d'en-tête de condition préalable envoyées par le robot d'exploration sont validées côté serveur, le serveur renvoie un code d'état HTTP 304 (sans corps HTTP) au robot d'exploration. Cela se produit pour chaque requête ultérieure jusqu'à ce que les conditions préalables ne puissent plus être validées (la date de ETag ou de Last-Modified change côté serveur).
|
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 ... |
Si vous souhaitez satisfaire vos utilisateurs et peut-être même réduire votre facture d'hébergement, demandez à votre fournisseur d'hébergement ou de CMS, ou à vos développeurs, comment activer la mise en cache HTTP pour votre site. Vos utilisateurs vous en seront reconnaissants.
Si vous souhaitez discuter de la mise en cache, rejoignez la communauté d'aide Search Central. Si vous avez des commentaires sur notre mise en cache, laissez-les dans la documentation sur la mise en cache que nous avons publiée avec cet article de blog.