Le code 304 Not Modified change-t-il la fréquence de crawl ?

Parmi les leviers techniques discutés en référencement, le code 304 occupe une place particulière : très cité, rarement mis en place, et presque jamais mesuré. Il désigne une réponse par laquelle le serveur indique qu'une ressource n'a pas changé depuis la dernière fois que le demandeur l'a récupérée, et qu'il n'y a donc rien à renvoyer. Le code 304 Not Modified économise la bande passante, le temps de génération de la page et une part du travail du robot, ce qui explique l'intérêt qu'on lui porte. Reste à savoir ce qu'il change réellement pour un site de contenu, dans quelles conditions il fonctionne, et pourquoi une mise en place approximative peut faire plus de mal que de bien.

Ce que le mécanisme fait exactement

Le protocole HTTP prévoit depuis longtemps des requêtes dites conditionnelles, dont l'exécution dépend d'une condition posée par le demandeur. C'est un mécanisme d'économie, pas un mécanisme de référencement, et c'est en le comprenant comme tel qu'on évite les fausses attentes. Il complète utilement les notions abordées dans la rubrique référencement naturel sur le comportement des robots d'exploration.

Les deux validateurs disponibles

Le serveur peut accompagner une réponse de deux indications permettant plus tard de savoir si la ressource a changé. La première est une date de dernière modification, la seconde est une empreinte, souvent appelée étiquette d'entité, qui identifie une version précise du contenu. Le demandeur mémorise l'une ou l'autre, et les renvoie lors de sa visite suivante dans un en tête de condition. Le serveur compare, et répond soit le document complet avec un code 200, soit une réponse vide avec un code 304. Les deux validateurs peuvent coexister, l'empreinte étant considérée comme la plus fiable des deux quand elle est présente.

Une réponse sans corps

La particularité du code 304 est qu'il ne transporte aucun contenu. Le serveur renvoie uniquement des en têtes, ce qui représente quelques centaines d'octets contre plusieurs dizaines de kilooctets pour une page complète. L'économie porte donc sur le transfert, mais aussi et surtout sur la génération : un site correctement conçu répond un code 304 sans jamais construire la page, sans interroger la base de données et sans exécuter le moteur de gabarits, ce qui divise le temps de réponse par un facteur important.

Ce que le robot en fait

Google indique explicitement traiter le code 304 comme une confirmation que la version qu'il détient reste valable, et considère cette réponse comme réussie (documentation Google Search Central). La page reste indexée avec son contenu précédent, et le robot ne perd pas de temps à réanalyser un document identique. Il est en revanche important de comprendre que le robot ne cesse pas de revenir pour autant : il continue de vérifier, simplement à moindre coût pour les deux parties.

La différence avec la mise en cache navigateur

Le code 304 se confond souvent avec les directives de cache, alors que les deux mécanismes sont distincts et complémentaires. Les directives de cache disent pendant combien de temps une ressource peut être réutilisée sans même demander au serveur ; la requête conditionnelle intervient une fois ce délai écoulé, pour savoir s'il faut retélécharger. Un site bien réglé utilise les deux, avec des durées longues sur les ressources statiques et une revalidation conditionnelle sur les documents HTML, qui ne se mettent pas en cache longtemps.

Le cas particulier des ressources statiques

Images, feuilles de style et scripts se prêtent parfaitement à ce mécanisme, et la plupart des serveurs web le mettent en place tout seuls à partir de la date du fichier sur le disque. C'est déjà beaucoup, et cela explique une bonne part des réponses 304 que l'on trouve dans les journaux sans avoir rien fait. Pour ces ressources, la meilleure stratégie reste cependant différente : leur donner une adresse qui change à chaque nouvelle version, en y intégrant une empreinte, puis déclarer une durée de mise en cache très longue. On supprime alors complètement la requête de revalidation au lieu de l'alléger, ce qui est encore mieux, et on réserve le mécanisme conditionnel aux documents HTML, dont l'adresse doit rester stable.

Mettre en place la revalidation correctement

La théorie est simple, la mise en œuvre comporte quelques pièges qui expliquent que beaucoup de sites annoncent des validateurs sans jamais répondre le moindre code 304. Le travail se contrôle par la mesure, exactement comme pour le comptage d'exploration décrit dans notre article sur la manière de calculer son budget d'exploration à partir des journaux serveur.

Produire une date de modification qui a du sens

La date annoncée doit correspondre au dernier changement du contenu affiché, ce qui exclut deux erreurs fréquentes : annoncer la date du jour, qui rend la condition toujours fausse et le mécanisme inopérant, et annoncer la date de modification du fichier de gabarit, qui change à chaque intervention technique sans que le contenu bouge. Sur un système de gestion de contenu, la bonne source est la date de dernière modification de l'article, éventuellement combinée à celle des éléments annexes affichés dans la page.

Décider ce qui compte comme un changement

C'est la vraie difficulté, et elle est éditoriale autant que technique. Une page d'article affiche le contenu de l'article, mais aussi un menu, un pied de page, une liste d'articles récents et parfois des commentaires. Si l'un de ces blocs change, la page change. Inclure tous ces éléments dans le calcul rend la date presque toujours fraîche et annule le bénéfice ; les ignorer tous fait servir des versions périmées. Le compromis raisonnable consiste à retenir le contenu principal et les éléments de navigation, et à exclure les blocs purement dynamiques, quitte à les charger séparément.

Générer une empreinte stable

L'empreinte se calcule habituellement à partir du contenu servi, ce qui garantit sa justesse mais suppose d'avoir généré ce contenu, donc de perdre l'essentiel du gain. La bonne pratique consiste à la calculer à partir des éléments qui déterminent la page, identifiant du contenu, date de modification, version du gabarit et éventuellement identifiant de la version du site, sans construire la page. Un serveur qui ajoute lui même une empreinte à partir du corps de la réponse ne fait économiser que la bande passante, pas le temps de calcul.

Répondre avant de construire la page

Le point décisif est l'emplacement de la vérification dans le code. Elle doit intervenir le plus tôt possible, avant toute requête de contenu et avant le rendu, et interrompre l'exécution immédiatement si la condition est satisfaite. Placée en fin de traitement, la vérification économise le transfert et rien d'autre, ce qui n'a d'intérêt que sur des pages très lourdes. Sur un système de gestion de contenu, cette vérification précoce demande de disposer d'un index léger des dates de modification, consultable sans charger le contenu lui même.

Ne pas casser la mise en cache en aval

Les en têtes de contrôle du cache et les validateurs doivent être cohérents. Un site qui annonce une interdiction totale de mise en cache et fournit malgré tout des validateurs envoie un message contradictoire, et la plupart des intermédiaires cessent alors de faire des requêtes conditionnelles. De même, un en tête qui varie selon des critères instables oblige à considérer chaque réponse comme unique, ce qui rend la revalidation inutile. La cohérence de ces trois familles d'en têtes se vérifie d'un coup en observant une réponse réelle.

Servir aussi les visiteurs, pas seulement les robots

Le sujet est presque toujours présenté sous l'angle du référencement, alors que la revalidation profite d'abord aux visiteurs qui reviennent. Un lecteur qui rouvre une page consultée la veille peut la recevoir en quelques dizaines de millisecondes au lieu de quelques centaines, ce qui se ressent immédiatement. La condition est que le document HTML ne soit pas déclaré comme non stockable : une directive courante, souvent copiée sans réflexion, interdit toute conservation et empêche donc toute revalidation ultérieure. Autoriser la conservation avec obligation de revalider donne le comportement recherché, à savoir un document toujours à jour et rarement retéléchargé.

Mesurer le gain réel plutôt que l'espérer

Le sujet attire les affirmations générales, et la seule manière d'en sortir est de regarder ses propres journaux avant et après. Trois chiffres suffisent, et ils se comptent avec les mêmes outils que les codes de réponse ordinaires, dont nous rappelons la signification dans notre article sur les codes HTTP.

La part de réponses conditionnelles

Le premier chiffre est la proportion des requêtes du robot qui arrivent avec un en tête de condition. Si elle est nulle, le mécanisme ne fonctionne pas du tout, en général parce que le serveur n'a jamais fourni de validateur exploitable. Cette proportion monte progressivement après la mise en place, le robot devant d'abord repasser une fois sur chaque adresse pour mémoriser le validateur, ce qui explique qu'une mesure faite deux jours après ne montre rien.

La part de réponses 304 effectivement servies

Le deuxième chiffre est le rapport entre les réponses 304 et les requêtes conditionnelles reçues. Un site de contenu stable devrait atteindre une proportion élevée sur ses archives ; une proportion faible signale que la date annoncée change plus souvent que le contenu, ce qui ramène au calcul de la date. C'est le principal indicateur de bon fonctionnement, et il se surveille dans la durée plutôt qu'une seule fois.

L'évolution du volume d'exploration

Le troisième chiffre est le nombre d'adresses distinctes visitées par mois, comparé avant et après. C'est là que les attentes sont souvent déçues : la revalidation ne fait pas mécaniquement augmenter ce nombre, elle réduit le coût de chaque visite. Sur un site dont l'exploration était limitée par la capacité du serveur, l'effet peut être net ; sur un site dont l'exploration est limitée par l'intérêt que le moteur lui porte, l'effet sera nul, et le gain restera du côté de la charge serveur.

Ne pas confondre corrélation et effet

Toute mesure prise sur quelques semaines subit les variations normales du comportement du robot, qui peuvent atteindre vingt pour cent sans aucune cause identifiable. Attribuer à la revalidation une hausse observée le mois suivant sa mise en place demande donc de la prudence, et surtout de vérifier qu'aucune autre modification n'a eu lieu au même moment. La comparaison la plus honnête reste celle des indicateurs de coût, transfert et temps de génération, qui sont directement imputables et non sujets à interprétation.

Vérifier que rien ne s'est figé

Le dernier contrôle est un contrôle de sécurité : s'assurer qu'une page réellement modifiée est bien servie à nouveau. Il suffit de modifier un article, puis de refaire une requête conditionnelle avec l'ancien validateur et de vérifier qu'on obtient un code 200. Ce test doit faire partie de la recette de la mise en place, car l'erreur symétrique, celle d'un site qui répond 304 alors que le contenu a changé, est bien plus grave que l'absence de revalidation. Ce test gagne à être automatisé et rejoué à chaque déploiement, au même titre que les contrôles de disponibilité, car il porte sur un comportement qu'aucune navigation ordinaire ne révèle.

Les cas où il vaut mieux s'abstenir

Comme tout mécanisme d'optimisation, celui ci a un coût de complexité et des contextes où il n'apporte rien. Les identifier évite de consacrer une semaine à un chantier dont le bénéfice sera invisible.

Les sites de petite taille

Un site de deux cents pages est entièrement exploré très régulièrement, sans que cela pose la moindre difficulté au serveur. La revalidation n'y apportera aucun gain perceptible, et la complexité ajoutée au code n'est pas justifiée. Le seuil à partir duquel la question se pose sérieusement se situe plutôt vers plusieurs milliers de pages, et surtout quand les journaux montrent que le robot représente une part significative de la charge.

Les pages dont le contenu dépend du visiteur

Une page personnalisée selon la session, le panier ou la position géographique ne peut pas être revalidée simplement, puisqu'il n'existe pas une version unique de la page. Les tentatives de contournement, en faisant varier la réponse selon des critères multiples, aboutissent en général à un mécanisme qui ne se déclenche jamais. Sur ces pages, la bonne réponse consiste à isoler la partie personnalisée et à la charger séparément, ce qui rend le document principal revalidable.

Les architectures avec cache en amont

Quand une couche de mise en cache se situe devant le serveur, c'est elle qui répond à la majorité des requêtes, y compris à celles du robot, et la revalidation applicative ne sert plus à grand chose. Le sujet se déplace alors vers la configuration de cette couche, qui sait généralement gérer les requêtes conditionnelles pour son propre compte. Mettre en place les deux sans coordination produit des comportements difficiles à diagnostiquer, notamment des pages servies périmées après une publication.

Les sites qui publient beaucoup

Sur un site dont les pages de liste changent plusieurs fois par jour, l'essentiel des adresses n'a de toute façon pas la même version d'une visite à l'autre, et le taux de réponses 304 restera faible là où le crawl se concentre. Le mécanisme garde son intérêt sur les archives, qui représentent souvent l'essentiel du volume, mais le gain global sera plus modeste que ne le laisse espérer un calcul fait sur le nombre total de pages. Une variante utile consiste alors à n'activer la revalidation que sur les contenus dont la date de dernière modification remonte à plus de quelques mois, en la laissant désactivée ailleurs : on obtient l'essentiel du bénéfice avec un risque de contenu périmé pratiquement nul.

Le coût de maintenance à ne pas sous estimer

Un mécanisme de revalidation est du code qui décide si une page doit être servie ou non, et c'est à ce titre une pièce sensible du système. Toute évolution du site qui ajoute un élément affiché dans les pages, un bandeau, un encart, un fil d'actualité, oblige à se demander si le calcul de la date doit en tenir compte. Cette question sera oubliée un jour, et le symptôme sera une modification qui ne s'affiche pas, signalée par un client et attribuée à tout sauf à la bonne cause. La parade tient en deux choses : un commentaire explicite à l'endroit du calcul, et un moyen simple de désactiver globalement le mécanisme le temps d'un diagnostic. Sans cette porte de sortie, le premier incident conduit à retirer le code entier dans l'urgence. Ce commutateur doit être accessible sans déploiement, par une constante de configuration ou une variable d'environnement, sinon il ne servira pas au moment où l'on en aura précisément besoin.