Table des matières de l'article :
Lorsqu'on aborde la question de la vitesse des sites web, le cache web est l'un des premiers sujets qui revient presque systématiquement . La raison est simple : éviter de régénérer une page entière à chaque requête réduit considérablement la charge de travail du serveur et, par conséquent, permet de fournir le contenu à l'utilisateur beaucoup plus rapidement.
Le principe sous-jacent est relativement intuitif. Lorsqu'un CMS dynamique comme WordPress génère une page, il peut exécuter du code PHP, interroger la base de données, charger les configurations, traiter les extensions, récupérer les informations et enfin assembler le document HTML à envoyer au navigateur. Si la page résultante est mise en cache, de nombreuses requêtes ultérieures peuvent s'affranchir d'une grande partie de ce traitement et recevoir directement une copie prête à l'emploi.
Au fil des ans, ce concept est devenu accessible à un public non technique. Aujourd'hui, il existe des serveurs et des architectures intégrant des systèmes de cache, des solutions comme LiteSpeed , des extensions WordPress telles que WP Rocket et FlyingPress , ainsi que de nombreux autres outils permettant d'obtenir des résultats intéressants sans nécessairement maîtriser le fonctionnement d'un proxy inverse.
À l'autre extrême, on trouve des technologies comme Varnish (notre choix préféré), qui ont historiquement été largement utilisées dans les environnements et infrastructures d'entreprise où un contrôle extrêmement précis des politiques de mise en cache, de l'invalidation du contenu et du comportement des requêtes est requis.
Tout cela est très bien. Mais il y a un problème.
Configurer un cache web ne garantit pas automatiquement un site web toujours rapide.
C’est précisément là qu’il faut cesser de se concentrer uniquement sur le temps de chargement d’une seule URL et commencer à s’intéresser à une mesure bien plus significative : combien de requêtes parviennent réellement à trouver le contenu mis en cache lors d’une navigation normale sur le site ?
Une page très rapide ne signifie pas forcément un site rapide.
L'une des erreurs les plus fréquentes dans l'évaluation des performances consiste à prendre une page, à l'ouvrir plusieurs fois, à la tester avec un outil de test et à conclure que le système de cache fonctionne correctement.
La page d'accueil répond peut-être très rapidement. La page produit aussi. La page catégorie semble parfaite.
Alors là, vous commencez vraiment à naviguer.
Vous ouvrez un autre produit et le temps de réponse est nettement plus long. Vous passez à la catégorie suivante et le chargement s'accélère à nouveau. Vous ouvrez un article et le chargement ralentit encore. Vous revenez en arrière, accédez à une autre section, et soudain, tout semble à nouveau rapide.
Le résultat est ce que l'on pourrait appeler une navigation saccadée : certaines pages s'affichent instantanément, d'autres se comportent comme si le cache n'existait pas.
D'un point de vue technique, il est parfaitement possible que ce soit exactement le cas.
Lorsqu'une requête trouve une copie en cache de la page, on parle généralement d'une réponse au cache . Le serveur peut alors fournir le contenu sans avoir à reconstruire entièrement la page via l'application.
Lorsque cette copie est indisponible, on parle d'une erreur MISS . La requête doit alors atteindre les couches inférieures de la pile et, selon l'architecture, peut impliquer un traitement PHP, des requêtes SQL, des appels à des services externes, et toutes les autres opérations normalement nécessaires à la génération de cette page.
C’est pourquoi les données vraiment intéressantes ne consistent pas simplement à savoir si le cache est actif.
Il est important de connaître son taux de réussite (HIT Ratio ), c'est-à-dire la proportion de requêtes pouvant être satisfaites directement à partir du cache par rapport à celles qui doivent repasser par le serveur d'arrière-plan.
Un cache ultra-rapide avec un faible taux de HIT peut offrir une expérience utilisateur pire qu'un cache de taille appropriée conçu pour maintenir un taux de HIT constamment élevé.
L'analyse comparative sur une seule URL ne permet de comprendre que la moitié de l'histoire, voire moins.
Le problème est particulièrement évident lorsqu'on utilise des benchmarks synthétiques.
Supposons que nous testions la même page dix fois. Lors de la première requête, le système génère le contenu et le met en cache. Les neuf requêtes suivantes constatent que la page est déjà disponible.
Le résultat peut sembler excellent.
Mais un utilisateur réel ne visite pas la même URL dix fois de suite.
L'utilisateur accède à la page d'accueil, ouvre une catégorie, consulte un produit, retourne à la catégorie, applique un filtre, ouvre un deuxième produit, lit une page d'information et poursuit sa navigation.
Sur un site éditorial, vous pouvez passer de la page d'accueil à un article, puis à un dossier connexe, puis à une catégorie ou à un contenu publié plusieurs mois auparavant.
C’est dans ce contexte que la véritable qualité de la stratégie de mise en cache se révèle.
Si seules les pages les plus visitées sont mises en cache tandis qu'une grande partie des URL dites de longue traîne nécessitent une régénération continue, l'expérience réelle peut être très différente de celle montrée par le test de performance effectué sur la page d'accueil.
L'objectif n'est pas d'obtenir une capture d'écran avec un temps de réponse exceptionnel.
L'objectif est de faire en sorte que la plupart des systèmes de navigation du monde réel se comportent de manière cohérente et prévisible.
Le problème des purges complètes du cache
L'une des raisons pour lesquelles le taux de réussite peut chuter soudainement est la façon dont certains systèmes gèrent l'invalidation du cache.
Dans certaines configurations, un événement relativement courant peut entraîner l'effacement d'une très grande partie du cache, voire de la totalité de son contenu.
Cela peut se produire, par exemple, suite à une mise à jour d'un plugin, à la modification de certains paramètres, à la publication de contenu, à des interventions administratives ou tout simplement lorsque l'utilisateur appuie sur le bouton classique « Vider tout le cache ».
Depuis, le site dispose toujours officiellement d'un système de mise en cache, mais celui-ci est vide.
Chaque URL demandée pour la première fois devient alors un échec.
La page d'accueil est en cours d'actualisation. Le premier produit est en cours d'actualisation. La première catégorie est en cours d'actualisation. Le deuxième produit est en cours d'actualisation. Un ancien article est en cours d'actualisation.
Au fur et à mesure que les utilisateurs naviguent, le cache se remplit progressivement. Cependant, ce sont les visiteurs eux-mêmes qui supportent le coût de sa reconstruction.
La situation est particulièrement délicate car, après quelques minutes ou quelques heures, les pages les plus populaires seront de nouveau disponibles dans le cache, et une vérification superficielle pourrait laisser croire que tout fonctionne parfaitement.
Le problème persiste sur les URL moins fréquentées et réapparaît après la prochaine purge.
Préchauffage du cache : pourquoi nous essayons de remplir le cache avant les utilisateurs
L’une des techniques utilisées pour limiter ce comportement est ce qu’on appelle le préchauffage du cache.
Le concept est simple : au lieu d’attendre que le premier visiteur demande une page qui n’est pas déjà dans le cache, un processus automatique visite de manière proactive les URL du site et génère des copies.
En théorie, c'est une solution élégante.
Le cache est vidé, le processus de préchauffage démarre et les pages sont progressivement reconstruites avant l'arrivée des utilisateurs.
Le problème survient lorsqu'on passe d'un petit site comportant quelques centaines d'URL à un portail, un magazine ou un site de commerce électronique comptant des dizaines, voire des centaines de milliers, ou même des millions de pages.
Imaginez un site avec un million d'URL potentiellement mémorables. Un préchauffage complet nécessite un nombre considérable de requêtes et, surtout, chaque page qui n'est pas encore disponible doit être générée par le serveur.
Cela inclut la consommation du processeur, l'utilisation de la base de données, les E/S, la mémoire, les processus PHP et le temps.
En pratique, un échauffement réalisé avec négligence risque paradoxalement de se comporter comme un petit test de résistance lancé contre votre site.
Et il y a un autre problème : pendant que le robot d’exploration chargé de l’initialisation reconstruit les pages, les utilisateurs continuent de naviguer.
Si le processus prend beaucoup de temps pour couvrir l'ensemble du site, une part importante des URL sera tout de même découverte par de vrais visiteurs en premier.
La taille d'un cache doit être adaptée au site qu'il est censé servir.
C’est là que l’expertise en systèmes entre en jeu.
L'installation d'un système de cache est relativement simple. Concevoir un cache adapté au volume, au type de contenu et au trafic d'un site est une tout autre affaire.
Un cache qui doit gérer quelques milliers de pages a des besoins totalement différents de ceux d'un site de commerce électronique comportant des centaines de milliers de produits, filtres, catégories et variantes.
Il nous faut déterminer l'espace à réserver aux objets, les critères de stockage, la durée de leur disponibilité, les requêtes à exclure et, surtout, comment empêcher les objets moins utiles de chasser sans cesse les objets vraiment importants du cache.
Une erreur fréquente consiste par exemple à utiliser les précieuses ressources du cache d'application ou du cache de page pour stocker des fichiers statiques très volumineux comme des images et des vidéos.
Cela ne signifie pas que les images, les fichiers CSS, JavaScript ou autres ressources ne doivent pas être stockés. Au contraire, il existe des mécanismes spécifiques très efficaces pour ces ressources : le cache du navigateur, le cache du serveur web, le CDN et le stockage d’objets sont des exemples de couches permettant de gérer cela.
L'objectif est d'éviter de remplir sans discernement un espace conçu pour stocker des objets de valeur avec des fichiers qui pourraient être gérés plus judicieusement ailleurs.
Sur les très grands sites, la capacité réelle du cache et la politique de conservation ou de suppression des objets deviennent des éléments essentiels des performances.
Le véritable problème de la navigation intermittente dans le commerce électronique
Sur un blog, une page qui traîne parfois peut être agaçante.
Sur un site de commerce électronique, cela peut devenir beaucoup plus grave.
Lorsqu'un utilisateur compare des produits, des couleurs, des modèles, des caractéristiques ou des prix, il effectue généralement de nombreuses navigations successives. La vitesse perçue ne dépend donc pas du chargement d'une seule page d'accueil, mais de la continuité de toute la session.
Une catégorie de produits qui répond immédiatement, suivie d'un produit lent, puis d'un autre produit rapide, puis d'une nouvelle attente, crée un sentiment d'instabilité.
L'utilisateur ignore qu'en coulisses, certaines requêtes aboutissent et d'autres échouent.
Il constate simplement que « le site est parfois rapide et parfois non ».
Et c'est l'une des expériences les plus frustrantes car elle rend chaque clic imprévisible.
Lors d'un parcours d'achat, ces frictions peuvent s'ajouter à d'autres petites incertitudes et entraîner l'abandon de la navigation ou de la conversion. Un site e-commerce devrait donc s'efforcer d'offrir une expérience aussi cohérente que possible tout au long de la consultation du catalogue.
TTFB, LCP et Vitaux Web de basePourquoi la continuité est importante
La mise en cache d'une page a un effet particulièrement notable sur le temps de réponse initial (TTFB) , c'est-à-dire le temps nécessaire au navigateur pour commencer à recevoir la réponse demandée.
Il est important de noter que le TTFB n'est pas un paramètre essentiel du Web en soi . Cependant, il intervient tôt dans la chaîne de chargement de la page : si le document HTML met longtemps à être renvoyé, le navigateur mettra également plus de temps à découvrir et à traiter de nombreuses ressources nécessaires à l'affichage.
En conséquence, un TTFB élevé peut avoir un impact sur les indicateurs suivants, notamment le Largest Contentful Paint (LCP).
Et c'est une fois de plus ce comportement discontinu qui est intéressant.
Disposer d'un excellent TTFB (Time To First Byte) sur la page d'accueil n'est pas suffisant si une part importante de la navigation réelle doit constamment atteindre un serveur dorsal beaucoup plus lent.
C’est pourquoi, lorsque nous analysons une infrastructure, nous ne nous intéressons pas seulement à la vitesse d’exécution optimale d’une requête HIT . Nous cherchons également à comprendre sa fréquence d’exécution réelle.
Notre approche : invalider le contenu sans répercuter le problème sur le premier visiteur.
Chez Managed Server, nous avons développé une approche différente pour gérer ces scénarios.
L’objectif est d’éviter qu’une opération normale de mise à jour ou de nettoyage ne transforme soudainement des milliers d’URL rapides en autant de requêtes lentes.
La logique consiste à distinguer le moment où un contenu est considéré comme mis à jour du moment où sa dernière copie utilisable est effectivement abandonnée.
Lorsqu'une page doit être régénérée, le système peut continuer à utiliser une représentation précédemment stockée via une couche intermédiaire. Pendant ce temps, une nouvelle version est générée et remplace la précédente.
Autrement dit, au lieu d'avoir cette séquence :
- vider la page du cache ;
- arrivée du premier utilisateur ;
- en attente de la génération PHP et des requêtes de base de données ;
- création d'un nouveau cache ;
- Réponse enfin disponible ;
Nous pouvons garantir à l'utilisateur une copie immédiatement fonctionnelle pendant que le contenu est mis à jour en arrière-plan.
Le résultat pratique est important car le processus d'actualisation ne se traduit plus automatiquement par un ralentissement perceptible pour le visiteur.
Ce principe peut également être appliqué lorsqu'une purge de cache très importante est nécessaire : l'architecture évite, autant que possible, que la purge logique coïncide avec la destruction immédiate de la dernière réponse prête à être fournie.
L'avantage n'est pas de battre le record de vitesse, mais d'éliminer les pics de lenteur.
Cela introduit un changement de perspective.
Dans le monde de la performance, on a souvent tendance à rechercher le nombre le plus bas possible : 100 millisecondes, 80 millisecondes, 50 millisecondes.
Mais pour un utilisateur, il peut être beaucoup plus important d'avoir vingt pages consécutives qui répondent de manière uniforme que d'avoir dix pages instantanées alternant avec dix autres qui nécessitent des temps d'attente beaucoup plus longs.
La performance réelle, c'est aussi la prévisibilité.
Une architecture de mise en cache efficace doit viser non seulement à abaisser la moyenne, mais aussi à réduire l'écart entre le meilleur et le pire comportement.
Cela signifie maintenir un TTFB plus stable lors de la navigation, réduire le nombre de requêtes qui retournent soudainement au serveur d'application et limiter les pics de charge qui surviennent après des invalidations massives.
L'avantage est donc double.
D'une part, l'utilisateur bénéficie d'un site plus fluide et réactif. D'autre part, le système est protégé des vagues de régénérations simultanées qui peuvent survenir au pire moment, par exemple après une modification du cache en période de forte affluence.
Un taux de réussite élevé protège également PHP et les bases de données.
Le cache Web ne sert pas uniquement à afficher rapidement une page.
Cela permet également d' éviter des travaux inutiles sur l'infrastructure sous-jacente.
Toute requête pouvant être satisfaite par un niveau de mise en cache adéquat est potentiellement une requête qui ne devrait pas être adressée à WordPress, PHP ou à la base de données.
Cependant, lorsque le taux de requêtes (HIT Ratio) diminue, le serveur doit absorber une plus grande quantité de trafic.
Ce phénomène peut engendrer un cercle vicieux.
Le cache est vidé. Les erreurs de requête augmentent. Le nombre de processus PHP augmente. Les requêtes à la base de données augmentent. Le serveur utilise davantage de ressources. Les pages dynamiques deviennent encore plus lentes au moment même où le système tente de reconstruire le cache.
Sur les sites à fort trafic, le problème peut être particulièrement aigu car plusieurs utilisateurs peuvent simultanément demander des éléments qui n'ont pas encore été reconstruits.
C’est pourquoi une stratégie professionnelle doit s’intéresser non seulement à la création du cache , mais aussi à la gestion de son cycle de vie, son actualisation, son invalidation et sa reconstruction.
Les robots d'exploration bénéficient également d'une infrastructure toujours réactive
Des performances constantes ont également un impact sur les robots d'exploration des moteurs de recherche.
Un site comportant un grand nombre d'URL peut recevoir des requêtes continues de Googlebot et d'autres robots d'exploration. Si une part importante de ces requêtes peut être traitée rapidement sans solliciter fortement le serveur, l'infrastructure peut supporter plus facilement l'activité d'exploration.
Google prend lui-même en compte la capacité du serveur à répondre aux requêtes : lorsqu’une infrastructure ralentit considérablement ou rencontre des erreurs, les robots d’exploration peuvent réduire la pression afin d’éviter de la surcharger.
Cela ne signifie pas qu'un meilleur cache garantit automatiquement un meilleur classement, ni qu'une vitesse d'exploration accrue constitue en soi un facteur de classement.
Cependant, cela signifie qu'un serveur rapide et stable, capable de gérer l'exploration sans saturation, crée de meilleures conditions techniques pour une analyse efficace , notamment sur les très grands sites.
Ne vous contentez pas de vous demander : « Ai-je du cache ? », demandez-vous plutôt : « À quelle fréquence l'utilise-je ? »
Le cache Web reste l'un des outils les plus importants pour améliorer les performances d'un site dynamique.
Mais la simple présence de LiteSpeed, Varnish, d'un plugin WordPress ou de tout autre système ne suffit pas à déterminer si la stratégie fonctionne réellement.
Il convient d'observer le comportement de l'ensemble du site.
Nous devons comprendre ce qui se passe après une purge.
Vous devez vérifier combien de temps il faut pour reconstruire les URL.
Vous devez évaluer si le cache dispose d'un espace suffisant pour le volume réel de contenu et si ses politiques de rétention sont compatibles avec le projet.
Avant tout, il convient d'observer le taux de réussite dans le trafic réel.
Car le résultat important n'est pas de démontrer qu'une page peut être extrêmement rapide lorsque toutes les conditions sont favorables.
L'essentiel est de s'assurer que cette vitesse est disponible sur la plupart des pages, la plupart du temps.
Le cache web est bien. Le taux de réussite est meilleur.
Un cache web bien configuré peut considérablement améliorer les performances de WordPress, WooCommerce et de toute application dynamique. Cependant, à mesure que votre site se développe, l'activation du cache ne suffit plus.
Le problème est de maintenir son efficacité dans le temps.
Un système complètement démantelé à chaque modification et progressivement reconstruit grâce aux utilisateurs peut atteindre des performances spectaculaires sur des URL déjà très fréquentées, tout en offrant une expérience utilisateur déplorable sur le reste du site.
C’est pourquoi, chez Managed Server, nous préférons raisonner en termes de continuité, de taux de réussite et de protection du système dorsal.
En utilisant une architecture qui conserve une copie intermédiaire utilisable pendant la régénération du contenu, nous pouvons éviter que les actualisations normales du cache ne provoquent soudainement une navigation saccadée.
Cela signifie un TTFB plus constant, moins de requêtes coûteuses vers PHP et les bases de données, moins de pics de charge, une meilleure expérience de navigation et des conditions plus favorables pour les indicateurs de charge et l'activité des robots d'exploration.
Car une cache ne devrait pas être jugée uniquement sur sa rapidité d'accès.
Il convient avant tout de la juger à sa capacité à être prête à une certaine fréquence.
