Le cache serveur et la fraîcheur des pages vues par Google

Mettre en cache les pages produites transforme les performances d'un site de contenu : le temps de réponse passe de plusieurs centaines de millisecondes à quelques dizaines, et le serveur supporte des charges sans commune mesure. Ce gain a une contrepartie qui reçoit beaucoup moins d'attention : la page servie n'est plus celle qui serait produite maintenant, mais celle qui l'a été il y a un certain temps. Pour un visiteur humain, un décalage de quelques minutes passe inaperçu. Pour un robot d'exploration qui vient constater qu'un article a été mis à jour, ou qu'un prix a changé, ce décalage peut durer des jours si la configuration est mauvaise. Nous détaillons ici comment concilier les deux exigences.

Ce que reçoit réellement le robot d'exploration

Le robot est un client comme un autre du point de vue du serveur, ce qui a des conséquences précises.

Il reçoit la version en cache

Aucun mécanisme ne distingue par défaut le robot d'un visiteur ordinaire, et il reçoit donc exactement la même page conservée. Si cette page a été générée il y a six heures et qu'un contenu a changé depuis, le robot ne voit pas ce changement. Il repartira avec une version périmée et il ne reviendra pas nécessairement avant plusieurs jours. Ce décalage se cumule : une modification faite juste après une visite peut rester invisible très longtemps. Sur un site publiant régulièrement, cette latence a un coût réel. Elle explique certains retards d'indexation inexpliqués.

La fréquence de passage dépend de ce qu'il observe

Un moteur ajuste sa fréquence de visite selon ce qu'il constate : un site qui change souvent est visité souvent, un site figé l'est moins. Un cache trop long donne l'impression d'un site figé, ce qui réduit progressivement la fréquence de passage. Ce cercle est peu visible et il se corrige lentement une fois la cause traitée. Les mécanismes en jeu sont détaillés dans notre article sur le budget de crawl de Google. Sur un petit site, l'effet reste théorique. Sur un site volumineux publiant beaucoup, il devient sensible.

Le temps de réponse joue dans l'autre sens

Un serveur qui répond vite permet au robot d'explorer davantage de pages dans le temps qu'il alloue au site. Le cache améliore donc nettement ce point, ce qui constitue son principal apport en matière d'exploration. Le compromis est donc réel : le cache aide sur le volume exploré et il peut nuire sur la fraîcheur. Bien réglé, il apporte le premier sans coûter le second. Mal réglé, il produit l'inverse exact de l'effet recherché. Ce réglage constitue tout l'objet du sujet.

Les en-têtes de conservation

Une page peut annoncer au client la durée pendant laquelle elle reste valable, information que les robots prennent en compte. Une durée longue annoncée sur une page d'article décourage les revisites. Une durée nulle, à l'inverse, n'empêche pas le cache serveur de fonctionner mais indique que le contenu peut avoir changé. Ces en-têtes sont indépendants du cache serveur et ils sont souvent configurés sans réflexion. Les régler distinctement pour les pages et pour les fichiers statiques constitue le bon réflexe. Les pages méritent une durée courte, les fichiers versionnés une durée très longue.

La réponse de non-modification

Un mécanisme permet de répondre qu'une page n'a pas changé depuis la dernière visite, sans renvoyer son contenu. Cette réponse économise de la bande passante et elle indique au robot qu'il peut passer à autre chose. Son fonctionnement et ses effets sont exposés dans notre article sur les codes 304 et leur effet sur la fréquence de crawl. Un cache de pages doit être configuré pour la produire correctement, ce qui n'est pas systématique. Une réponse complète renvoyée pour une page inchangée gaspille du budget d'exploration. Ce point mérite une vérification explicite.

Le cas des pages de liste

Les pages d'archive, de catégorie et la page d'accueil changent à chaque publication, contrairement aux articles eux mêmes. Leur cache doit donc être purgé bien plus souvent, sous peine que le robot ne découvre pas les nouveaux contenus. C'est par ces pages que l'exploration circule, ce qui rend leur fraîcheur déterminante. Beaucoup de configurations appliquent une durée uniforme et négligent cette distinction. La corriger produit un effet mesurable sur le délai de découverte. Elle demande simplement une règle spécifique.

Régler les durées de conservation

La durée appropriée dépend entièrement de la nature de la page et de la fréquence réelle de ses modifications.

Les articles publiés

Un article rarement modifié après publication supporte une durée longue, de plusieurs heures à une journée. La contrainte n'est pas la fraîcheur du contenu mais la propagation d'une correction lorsqu'une erreur est signalée. Une purge déclenchée à l'enregistrement règle ce point et permet donc de conserver une durée longue. Cette combinaison, durée longue et purge événementielle, constitue la configuration de référence. Elle donne le maximum de performance sans aucune perte de fraîcheur. Elle demande que le mécanisme de purge fonctionne réellement, ce qui se vérifie.

La page d'accueil et les listes

Ces pages changent à chaque publication et leur durée doit rester courte, de quelques minutes à une heure. Elles doivent également être purgées à chaque publication, en même temps que l'article concerné. La liste des pages à purger comprend l'accueil, la catégorie, les archives par date et les pages de pagination. Cette liste est plus longue qu'il n'y paraît et elle est souvent incomplète dans les configurations par défaut. La vérifier explicitement fait partie de la mise en place. Une page de pagination oubliée retarde la découverte des contenus qu'elle liste.

Les pages de service

Les mentions légales, la page de contact et les pages institutionnelles ne changent presque jamais et supportent une durée de plusieurs jours. Elles représentent peu de trafic et leur mise en cache apporte donc peu. Les traiter avec une durée longue simplifie la configuration sans risque. Elles doivent néanmoins être purgeables manuellement, une correction sur les mentions légales devant être immédiate. Cette possibilité doit exister dans l'outil de cache retenu. Elle est disponible dans toutes les solutions sérieuses.

Les pages à contenu dynamique

Une page affichant un stock, un prix variable ou un compteur ne doit pas être mise en cache dans son intégralité. Deux approches existent : l'exclure entièrement, ce qui coûte en performance, ou mettre en cache la page et charger la partie variable par une requête séparée. La seconde approche conserve l'essentiel du bénéfice et elle demande un développement. Elle constitue la bonne réponse sur un site marchand. Le fragment dynamique doit être suffisamment léger pour ne pas annuler le gain. Cette technique est mal connue et très efficace.

Les pages personnalisées

Toute page affichant un état de connexion, un panier ou un nom d'utilisateur doit être exclue sans exception. Servir une telle page depuis le cache expose les données d'un visiteur à un autre, incident grave et parfaitement évitable. Les règles d'exclusion doivent être définies explicitement et testées avec deux navigateurs distincts. Ce test doit figurer dans la recette de toute mise en place de cache. Son omission a produit des incidents documentés sur des sites importants. Il prend cinq minutes.

Les paramètres d'adresse

Une même page appelée avec des paramètres de suivi différents produit autant d'entrées de cache distinctes, ce qui sature l'espace disponible. Configurer le cache pour ignorer les paramètres qui ne changent pas le contenu résout ce point. La liste de ces paramètres comprend les marqueurs de campagne et les identifiants de session de certains outils. Cette configuration réduit parfois de moitié la taille du cache. Elle améliore également le taux de réutilisation. Elle est disponible dans la plupart des solutions et rarement activée.

Purger au bon moment

La qualité d'un dispositif de cache se juge à sa purge bien plus qu'à sa mise en place.

Purger précisément plutôt que tout vider

Vider l'intégralité du cache à chaque publication oblige le serveur à reconstruire toutes les pages, ce qui produit un pic de charge et une période de lenteur. Une purge ciblée ne concerne que la page modifiée et les pages qui la référencent. Cette précision demande un peu de configuration et elle évite le comportement en dents de scie. Sur un site publiant plusieurs fois par jour, la différence est nette. La plupart des extensions proposent les deux modes et retiennent le plus brutal par défaut. Le changer prend deux minutes.

Identifier les pages liées

Publier un article modifie l'accueil, la catégorie, les archives, le plan de site et parfois les pages listant les contenus similaires. Toutes doivent être purgées ensemble, faute de quoi le robot découvre le nouvel article avec retard. Établir cette liste demande de comprendre la structure du site et elle est spécifique à chaque projet. Un test simple consiste à publier un article et à vérifier, en navigation privée, où il apparaît immédiatement. Les emplacements où il n'apparaît pas signalent une purge manquante. Ce test prend cinq minutes et il révèle presque toujours un oubli.

Traiter le plan de site

Le plan de site est le document que le robot consulte pour découvrir les nouvelles adresses, et il est souvent mis en cache comme n'importe quelle page. Un plan périmé annule l'intérêt de sa mise à jour à la publication. Il doit donc être exclu du cache ou purgé systématiquement. Ce point est fréquemment oublié et il produit exactement le retard de découverte que l'on cherchait à éviter. Le contrôle consiste à consulter le plan de site après publication et à y chercher la nouvelle adresse. Il prend trente secondes.

Prévoir la purge des modifications indirectes

Modifier un menu, un pied de page ou un élément partagé change toutes les pages du site sans qu'aucune ne soit enregistrée individuellement. Ces modifications doivent déclencher une purge globale, seul cas où elle se justifie. Sans ce mécanisme, un changement de coordonnées reste invisible pendant des heures. La liste des éléments concernés doit être établie et le déclenchement configuré. Cette configuration est disponible dans les extensions sérieuses et elle demande d'être vérifiée. Elle est souvent partielle par défaut.

Vérifier que la purge fonctionne

Un mécanisme de purge configuré n'est pas nécessairement un mécanisme de purge opérant. Le contrôle consiste à modifier un contenu et à mesurer le délai avant que la modification n'apparaisse depuis une session anonyme. Ce test doit être refait après chaque mise à jour du système ou de l'extension de cache. Il révèle régulièrement une purge devenue inopérante après une modification sans rapport. Sa réalisation prend deux minutes et il constitue le seul contrôle qui compte. Il mérite une place dans la liste des vérifications de mise en ligne.

Attention au navigateur de l'administrateur

Une personne connectée reçoit généralement une version non mise en cache, ce qui lui donne une vision complètement différente de celle des visiteurs. Tester une modification depuis sa propre session administrateur ne prouve donc rien. Tous les contrôles doivent se faire en navigation privée ou depuis un autre appareil. Cette erreur est extrêmement fréquente et elle conduit à croire qu'un problème est résolu alors qu'il persiste. La règle est simple et elle mérite d'être rappelée à toute l'équipe. Elle explique une part importante des faux diagnostics.

Concilier fraîcheur et performance

Les deux exigences ne sont pas contradictoires dès lors que la configuration distingue les cas.

La configuration de référence

Une durée longue sur les articles, courte sur les listes, une purge événementielle précise et une exclusion stricte des pages personnalisées couvrent l'essentiel des besoins d'un site de contenu. Cette configuration se met en place en une demi journée et elle tient pendant des années. Elle apporte le gain de performance maximal sans coût de fraîcheur. Elle doit être documentée pour survivre aux changements d'intervenant. Sa complexité apparente se réduit à cinq règles. Les écrire une fois évite de les redécouvrir.

Le préchauffage après purge

Une page purgée sera reconstruite lors de la prochaine visite, qui paiera donc le prix de la génération. Un mécanisme de préchauffage reconstruit les pages importantes immédiatement après la purge, ce qui évite qu'un visiteur ou un robot ne tombe sur une page lente. Il doit rester limité aux pages principales, préchauffer un catalogue entier saturant le serveur. Cette fonction est proposée par plusieurs solutions et elle demande un réglage prudent. Elle apporte un confort réel sur les sites à forte fréquentation. Elle est superflue sur les sites modestes.

Les signaux de fraîcheur du contenu

Indiquer clairement la date de dernière mise à jour d'un article, dans le balisage et dans les données structurées, aide les moteurs à apprécier l'actualité du contenu. Cette information n'a de valeur que si elle est exacte et si elle correspond à une modification réelle. Les enjeux liés à la fraîcheur perçue sont développés dans notre article sur la requête de fraîcheur chez Google. Modifier une virgule pour actualiser une date ne trompe personne et dégrade la confiance. Une mise à jour substantielle mérite en revanche d'être signalée. Cette honnêteté sert le site sur la durée.

Surveiller les statistiques d'exploration

Le nombre de pages explorées par jour et le temps de réponse moyen constaté par le moteur figurent dans les outils dédiés. Ces deux courbes réagissent à la mise en place d'un cache et permettent d'en mesurer l'effet. Une hausse du volume exploré accompagnée d'une baisse du temps de réponse confirme un réglage réussi. Une baisse du volume signale au contraire un problème. Consulter ces courbes un mois après la mise en place fait partie du travail. Elles constituent le seul retour objectif disponible.

Mesurer le délai de découverte

Le temps écoulé entre la publication d'un article et sa première visite par le robot constitue l'indicateur le plus direct. Il se relève dans les journaux du serveur ou dans les outils du moteur. Sur un site correctement configuré, il se compte en minutes ou en heures. Un délai de plusieurs jours signale un problème de découverte, souvent lié au cache des pages de liste ou du plan de site. Cette mesure, relevée sur une dizaine d'articles, donne une image fiable. Elle mérite d'être refaite après chaque modification de la configuration.

Revoir la configuration périodiquement

Le rythme de publication change, la structure du site évolue, une extension de cache est remplacée. Une revue annuelle de la configuration, avec les mêmes tests qu'à la mise en place, évite la dérive silencieuse. Elle prend une heure et elle révèle presque toujours une règle devenue inadaptée. Elle constitue également l'occasion de vérifier que la documentation correspond à la réalité. Cette discipline vaut pour toute configuration technique structurante. Elle évite de découvrir un problème au moment où il coûte le plus cher.