Comprendre le cache d’un site web et les pages qui restent anciennes

Le cache d’un site web consiste à conserver une copie déjà prête d’un contenu pour éviter de tout reconstruire à chaque visite. Cette copie peut se trouver dans le navigateur du visiteur, sur le serveur, dans l’application ou plus près de l’utilisateur grâce à un CDN. L’idée de base est simple: si la même réponse doit être servie plusieurs fois, il est plus logique de la réutiliser que de la recalculer à chaque requête.

Ce qu’est vraiment une copie en cache

Une copie en cache n’est pas un autre contenu. C’est une réponse déjà assemblée et enregistrée pour être réutilisée. Si une page d’accueil ressemble à la même chose pour la plupart des visiteurs, le site peut garder cette version prête et la renvoyer sans répéter tout le travail de construction. Le cache ne transforme pas le contenu; il change la manière dont il est livré.

C’est utile parce que beaucoup de pages sont consultées de façon répétée. Un article, une page de présentation ou une fiche produit peut être vu des dizaines de fois sans changer entre deux visites. Le cache évite de refaire la même opération à chaque demande et réduit la quantité de travail nécessaire pour répondre.

Où le cache peut se trouver

On parle souvent du cache comme s’il n’y en avait qu’un, mais il existe plusieurs couches.

• Cache du navigateur: le navigateur du visiteur stocke des fichiers comme les images, les CSS et certains scripts pour ne pas les retélécharger immédiatement.
• Cache de page: une page HTML complète, déjà construite, est conservée et servie telle quelle.
• Cache côté serveur: le serveur ou l’application garde des résultats préparés pour éviter des traitements répétés.
• Cache d’objets: de petites données, comme des résultats de requêtes ou des calculs répétés, sont stockées pour être réutilisées.
• Cache du CDN: des copies sont placées sur des nœuds proches des visiteurs dans différentes zones géographiques.

Si vous voulez comprendre comment cette logique se relie à la distribution du contenu, lisez ce qu’est un CDN et pourquoi il travaille souvent avec des copies en cache. Le CDN n’est pas le cache au sens strict, mais il en utilise souvent les mécanismes.

Chaque couche a un rôle précis. Le cache du navigateur aide un même visiteur à revenir plus vite sur un site. Le cache de page permet de servir une page déjà prête à de nombreux visiteurs. Le cache d’objets évite de répéter des requêtes ou des calculs. Le cache du CDN rapproche le contenu de l’utilisateur.

Contenu statique et contenu dynamique

Le contenu statique est presque identique pour tout le monde. Le contenu dynamique change selon l’utilisateur, sa session, son panier ou son état de connexion. Le cache fonctionne très bien quand le contenu reste stable. Il devient plus délicat dès qu’une page dépend d’un contexte personnel ou d’une action en cours.

Un article de blog peut souvent être mis en cache sans risque particulier. Un espace client, un panier ou une page de commande doivent être traités avec plus de prudence. Même une page d’accueil peut mélanger des blocs stables et des éléments qui changent souvent. Le site doit donc savoir quelle partie peut être réutilisée et quelle partie doit rester dynamique.

Pourquoi une mise à jour peut apparaître en retard

Quand un prix change, qu’une image est remplacée ou qu’un texte est corrigé, la nouvelle version n’apparaît pas toujours immédiatement partout. Une copie plus ancienne peut encore être présente dans le cache du navigateur, le cache de page ou le cache du CDN. Cela ne veut pas forcément dire que la mise à jour a échoué. Cela signifie souvent que la copie stockée n’a pas encore expiré ou qu’elle n’a pas été purgée.

Le TTL, ou durée de vie, joue ici un rôle central. Une entrée peut rester valable pendant un certain temps avant d’être considérée comme obsolète. Certains systèmes la renouvellent automatiquement à la fin de cette période. D’autres ont besoin d’un purge ou d’une invalidation pour supprimer l’ancienne version et en recréer une nouvelle. C’est souvent à ce moment qu’un site semble afficher une page “ancienne”.

Il est donc utile de distinguer un contenu réellement erroné d’une copie pas encore renouvelée. Dans beaucoup de cas, le système fonctionne correctement, mais avec une version qui n’a pas encore été remplacée.

Comptes connectés, panier et commande

Le cache est plus simple quand tout le monde voit la même chose. Les utilisateurs connectés, eux, peuvent voir des informations personnelles, des paramètres différents ou des messages liés à leur compte. Si une page personnalisée est traitée comme une page publique, la mauvaise information pourrait être affichée au mauvais visiteur. C’est pourquoi les zones de compte sont généralement gérées avec des règles spécifiques.

Dans l’e-commerce, la prudence est encore plus importante. Le panier, la session et la commande doivent rester liés à l’utilisateur actif. Une fiche produit peut souvent bénéficier du cache; le panier, beaucoup moins. L’objectif n’est pas de tout mettre en cache, mais de mettre en cache ce qui peut l’être sans casser l’expérience ni mélanger les sessions.

• Les pages publiques sont les meilleures candidates au cache.
• Le panier, le compte et la commande doivent rester sensibles à la session.
• Il est normal qu’un site mélange du contenu en cache et du contenu dynamique.

Quand le cache aide, et quand il brouille la lecture

Le cache aide quand la même ressource est demandée plusieurs fois et que le contenu change rarement. Il brouille la lecture quand on attend une mise à jour immédiate mais qu’une copie plus ancienne est encore servie. Dans ce cas, le problème n’est pas que le cache soit mauvais. Le problème est qu’une couche intermédiaire répond encore avec l’ancienne version.

Pour mieux distinguer la lenteur générale du comportement du cache, vous pouvez lire pourquoi un site peut sembler lent même lorsqu’il utilise du cache. Une page trop lente et une page trop ancienne ne renvoient pas toujours à la même cause.

Le cache n’est ni une sauvegarde ni une optimisation de base de données

Ces notions sont souvent confondues, mais elles n’ont pas le même rôle. Une sauvegarde sert à restaurer des données après un incident. Elle n’existe pas pour accélérer le site. L’optimisation de base de données améliore la façon dont les données sont stockées et retrouvées, ce qui peut aider, mais cela ne remplace pas une réponse en cache. Un CDN, de son côté, distribue les contenus à partir d’emplacements plus proches des visiteurs et peut utiliser du cache, sans être identique au cache du site lui-même.

Bien séparer ces outils évite de mauvais diagnostics. Une sauvegarde ne rend pas une page plus rapide. Un CDN ne corrige pas à lui seul une base mal structurée. Le cache ne répare pas un contenu cassé et ne remplace pas une architecture saine. Chaque outil a sa fonction propre.

Quand le CMS ajoute une couche de complexité

Dans un CMS, plusieurs niveaux de cache peuvent coexister: navigateur, page, objet et parfois infrastructure intermédiaire. Cette superposition est utile, mais elle demande de savoir quelle couche sert encore une version ancienne. Sans cela, on peut confondre le problème de publication avec le comportement d’une copie conservée temporairement.

Pour replacer ces mécanismes dans le contexte du contenu publié, vous pouvez aussi consulter ce qu’est WooCommerce et pourquoi le panier exige une gestion particulière. Cela aide à distinguer les pages publiques des zones qui ne doivent pas être servies comme des pages fixes.

Le cache d’un site réduit les calculs répétés, mais il faut aussi surveiller le premier délai de réponse. C’est pourquoi TTFB et Core Web Vitals complètent bien ce sujet.

Quand le contenu dépend d’un site dynamique, Redis object cache devient pertinent, tout comme WordPress. Ensemble, ils aident à distinguer le cache de page, le cache applicatif et la diffusion globale.