Qu’est-ce que la mise en cache pour un site web ?

La mise en cache consiste à garder une copie d’une donnée déjà calculée ou téléchargée dans un endroit plus rapide d’accès, pour ne pas refaire le travail à chaque visite. Sur un site internet, le cache intervient à plusieurs niveaux : le navigateur du visiteur, le réseau de diffusion (CDN), le serveur (cache de page, cache objet, OPcache) et même la résolution DNS. Bien réglé, il accélère nettement l’affichage, allège le serveur et contribue au référencement ; mal réglé, il affiche des pages périmées ou, pire, les données d’un autre utilisateur.

On voit ici comment un site est servi, les différents types de cache, la notion de taux de réussite, les en-têtes HTTP qui pilotent le cache, le lien avec le SEO, ce qu’il ne faut jamais mettre en cache, la mise en place sur WordPress et la façon de vider le cache quand une modification n’apparaît pas.

• Qu’est-ce que le cache et pourquoi compte-t-il pour la vitesse d’un site ?
• Comment un site internet est-il servi au visiteur ?
• Quels sont les différents types de cache ?
• Qu’est-ce qu’un cache hit et un cache miss ?
• Comment contrôler le cache avec les en-têtes HTTP ?
• Quel est le lien entre cache et référencement ?
• Que ne faut-il pas mettre en cache ?
• Comment mettre en place le cache sur un site WordPress ?
• Comment vider le cache ?
• Quelles erreurs éviter ?
• Questions fréquentes
• Sources

Qu’est-ce que le cache et pourquoi compte-t-il pour la vitesse d’un site ?

En informatique, la mise en cache désigne le stockage temporaire de données dans une ressource rapide et facilement accessible, afin de réduire le temps nécessaire pour les récupérer. L’idée vient du matériel : dès les années 1960, des ordinateurs comme l’Atlas 2 ou l’IBM System/360 Model 85 intègrent une petite mémoire rapide, parce que le processeur calculait plus vite qu’il ne pouvait lire ses instructions et ses données en mémoire principale, et restait donc inactif en attendant.

Le web a repris le même principe. Chaque fois qu’un visiteur ouvre une page, plusieurs acteurs doivent chercher, calculer et transférer des données. Si la réponse a déjà été produite récemment, autant la réutiliser. C’est aujourd’hui un paramètre important de la réalisation d’un site, et un bon critère pour juger le sérieux technique d’un prestataire.

Comment un site internet est-il servi au visiteur ?

Quand un utilisateur saisit une adresse dans son navigateur, voici, au minimum, ce qui se passe :

1. La résolution DNS : le navigateur demande à un serveur de noms de domaine l’adresse IP du serveur qui héberge le site.
2. La requête HTTP : le navigateur envoie une requête au serveur web (en HTTP/1.1, HTTP/2 ou HTTP/3 selon le serveur).
3. La réponse du serveur : le serveur exécute le code du site (par exemple PHP pour WordPress), interroge la base de données et renvoie la page HTML.
4. Le rendu : le navigateur lit la page, découvre les feuilles de style, scripts, polices et images nécessaires, et lance de nouvelles requêtes pour chacun.

Chacune de ces étapes consiste à récupérer une donnée auprès d’une ressource qui met un certain temps à trouver la réponse, puis à la transmettre. Le problème est donc analogue à celui du processeur qui attend sa mémoire, et la même solution fonctionne : garder les réponses fréquentes à portée de main.

Quels sont les différents types de cache ?

Type de cache	Où il se trouve	Ce qu’il garde	Qui le règle
Cache DNS	Navigateur, système, box, résolveur du fournisseur d’accès	L’adresse IP associée au nom de domaine	La durée de vie (TTL) de l’enregistrement DNS
Cache du navigateur	L’appareil du visiteur	Images, CSS, JavaScript, polices, parfois pages	Les en-têtes HTTP envoyés par le serveur
Cache CDN	Serveurs répartis dans le monde	Fichiers statiques, parfois pages HTML	La configuration du CDN et les en-têtes HTTP
Cache de page	Le serveur (extension, Varnish, reverse proxy)	La page HTML déjà générée	L’hébergeur ou une extension
Cache objet	Le serveur (Redis, Memcached)	Résultats de requêtes et calculs réutilisables	Le développeur ou l’hébergeur
OPcache	Le serveur PHP	Le code PHP déjà compilé	La configuration PHP
Cache de base de données	Le moteur MySQL ou MariaDB	Les données et index les plus utilisés en mémoire	La configuration de la base

Le cache DNS

Le navigateur, le système d’exploitation et les résolveurs gardent en mémoire l’adresse IP d’un site pour ne pas la redemander à chaque visite. La durée de conservation est fixée par le TTL de l’enregistrement DNS, que l’on explique dans notre article sur le TTL DNS.

Le cache côté serveur

À chaque requête, le serveur calcule : il lit des données en base (les produits d’une catégorie, les derniers articles), puis exécute du code. Pour éviter de refaire ces calculs, plusieurs couches existent :

• OPcache stocke en mémoire partagée le code PHP déjà compilé (le bytecode), ce qui évite à PHP de relire et d’analyser les scripts à chaque requête. L’extension est livrée avec PHP depuis la version 5.5.
• Le cache objet garde le résultat de requêtes coûteuses dans Redis ou Memcached. La documentation de WordPress le décrit comme le fait de déplacer des données d’un endroit où leur récupération est lente et coûteuse vers un endroit rapide et bon marché.
• Le cache de page enregistre la page HTML finale. Les visiteurs suivants la reçoivent directement, sans exécuter PHP ni interroger la base : c’est le gain le plus spectaculaire pour un site vitrine.
• Le moteur de base de données garde lui-même en mémoire les données et index les plus sollicités.

Le cache du navigateur

Un développeur vous a déjà demandé de « vider le cache pour voir les modifications » ? Il parlait probablement du cache de votre navigateur. Celui-ci conserve feuilles de style, polices, images et scripts pour ne pas les retélécharger à chaque page. Les navigateurs disposent aussi d’un cache « précédent/suivant » (bfcache) qui garde une page entière en mémoire pour un retour arrière instantané, et les sites peuvent gérer leur propre cache hors ligne grâce à un service worker.

Le cache CDN

Un réseau de diffusion de contenu (CDN) comme Cloudflare place des copies de vos fichiers sur des serveurs proches de vos visiteurs. Attention aux réglages par défaut : selon sa documentation, Cloudflare met en cache selon l’extension des fichiers (images, CSS, JavaScript, polices, PDF) et ne met pas en cache le HTML ni le JSON par défaut. Il ne met pas non plus en cache une réponse qui contient un cookie (en-tête Set-Cookie) ou un Cache-Control private, no-store, no-cache ou max-age=0.

Qu’est-ce qu’un cache hit et un cache miss ?

On parle de succès de cache (cache hit) quand la ressource demandée est trouvée dans le cache et servie immédiatement. On parle d’échec de cache (cache miss) quand elle n’y est pas : la demande doit alors remonter jusqu’à la source (le serveur d’origine, la base de données), ce qui prend plus de temps, puis la réponse est généralement stockée pour les fois suivantes.

Le taux de succès (hit ratio) se calcule simplement : nombre de réponses servies depuis le cache, divisé par le nombre total de demandes. Si un CDN sert 900 requêtes sur 1 000 depuis son cache, son taux de succès est de 90 %.

Un système efficace cherche à augmenter le taux de succès sans servir de contenu périmé. Les tableaux de bord des CDN et de la plupart des extensions de cache affichent cet indicateur : un taux faible signale souvent des pages exclues à tort ou des durées de conservation trop courtes.

Comment contrôler le cache avec les en-têtes HTTP ?

Navigateurs, proxys et CDN mettent en cache selon des règles. Il faut donc leur dire quoi garder et combien de temps. Chaque plateforme a ses propres réglages, mais le dénominateur commun est HTTP : le cache y est défini par la norme RFC 9111 (juin 2022), et piloté principalement par l’en-tête Cache-Control.

Directive	Ce qu’elle signifie	Usage typique
max-age=N	La réponse reste fraîche N secondes	Fichiers statiques, pages peu changeantes
s-maxage=N	Même chose, mais seulement pour les caches partagés (CDN, proxy)	Pages HTML mises en cache par le CDN
no-cache	Peut être stockée, mais doit être revalidée auprès du serveur avant chaque réutilisation	Pages HTML qui changent souvent
no-store	Ne jamais stocker	Données sensibles, espace client
private	Seul le navigateur de l’utilisateur peut stocker	Pages personnalisées
must-revalidate	Une fois périmée, la réponse ne doit plus être servie sans revalidation	Contenus où une version périmée pose problème
immutable	La ressource ne changera pas tant qu’elle est fraîche	Fichiers versionnés (app.3f9a2c.js)
stale-while-revalidate=N	Le cache peut servir une version périmée pendant N secondes, le temps de la rafraîchir	Pages où quelques secondes de retard sont acceptables

Une correction par rapport à une idée répandue : must-revalidate ne force pas une vérification à chaque visite. Pour qu’un contenu mis à jour souvent (une page d’actualités, un bloc des derniers articles) soit toujours revérifié, c’est no-cache qu’il faut utiliser, ou une durée max-age courte.

La revalidation s’appuie sur deux en-têtes : ETag (une empreinte de la ressource) et Last-Modified (sa date de modification). Le navigateur demande « la ressource a-t-elle changé ? », et si ce n’est pas le cas, le serveur répond 304 Not Modified sans renvoyer le contenu. Le transfert est minime.

La bonne pratique recommandée par la documentation MDN pour les fichiers statiques est le cache busting : inclure une version ou une empreinte dans le nom du fichier, lui donner une très longue durée de vie, et changer d’URL à chaque modification. Exemple de réglage courant :

# Fichiers versionnés (CSS, JS, polices, images) : un an, jamais revalidés
Cache-Control: public, max-age=31536000, immutable

# Pages HTML : stockées mais revérifiées à chaque visite
Cache-Control: no-cache

# Espace client, panier, compte : jamais stockés
Cache-Control: no-store

Sans aucun en-tête, les navigateurs appliquent un cache « heuristique » : la norme leur suggère de conserver une réponse environ 10 % du temps écoulé depuis sa dernière modification. Mieux vaut donc toujours déclarer explicitement ses règles.

Quel est le lien entre cache et référencement ?

Le cache n’est pas un critère de classement en soi, mais il agit sur deux choses qui comptent :

• La vitesse ressentie : un cache de page réduit le temps de réponse du serveur, et le cache navigateur accélère les visites suivantes. Ces gains se retrouvent dans les indicateurs d’expérience de Google, présentés dans notre article sur les Core Web Vitals. L’outil Lighthouse signale d’ailleurs explicitement les fichiers statiques servis sans politique de cache efficace.
• L’exploration par Googlebot : en décembre 2024, Google a rappelé que ses robots d’exploration prennent en charge le cache HTTP via les en-têtes ETag / If-None-Match et Last-Modified / If-Modified-Since, et recommande particulièrement ETag. Un site qui répond 304 aux pages inchangées fait économiser des ressources au robot comme au serveur.

Que ne faut-il pas mettre en cache ?

Tout mettre en cache est tentant, mais dangereux. Certaines pages doivent toujours être calculées en direct :

• Le panier, la commande et le compte client d’un site e-commerce : une page de panier mise en cache peut afficher à un visiteur le contenu du panier d’un autre.
• Les pages personnalisées et tout ce qui dépend d’une connexion.
• Les données en temps réel : stocks, cours, disponibilités, météo.
• Les formulaires qui contiennent un jeton de sécurité propre à chaque visite.
• Le code tiers mis à jour par son éditeur : si vous figez une copie d’une bibliothèque externe, vous ne recevrez pas ses correctifs de sécurité.

Les bonnes extensions de cache et les hébergeurs spécialisés excluent déjà ces pages par défaut pour WooCommerce, mais il faut le vérifier après chaque installation.

Comment mettre en place le cache sur un site WordPress ?

1. Vérifiez ce que fait déjà votre hébergeur : de nombreux hébergements WordPress intègrent un cache de page côté serveur. Ajouter une extension par-dessus fait alors doublon et complique le dépannage.
2. Sinon, installez une seule extension de cache de page. WP Super Cache, maintenue par Automattic, génère des fichiers HTML statiques servis à la grande majorité des visiteurs (ceux qui ne sont pas connectés et n’ont pas laissé de commentaire).
3. Ajoutez un cache objet (Redis ou Memcached) si votre site est dynamique : boutique, espace membre, beaucoup de requêtes en base.
4. Vérifiez qu’OPcache est actif dans la configuration PHP de votre hébergement.
5. Réglez les en-têtes des fichiers statiques avec une longue durée de vie, et assurez-vous que les fichiers sont versionnés.
6. Ajoutez un CDN si vos visiteurs sont répartis géographiquement ou si le trafic connaît des pics.
7. Testez : naviguez connecté et déconnecté, passez une commande test, vérifiez que les modifications apparaissent après une purge.

Le cache fait partie des réglages que l’on suit dans le cadre de la maintenance d’un site WordPress. Chez Osmova, nos formules d’hébergement et maintenance s’adaptent au niveau de suivi souhaité. Pour une question sur votre site, écrivez à contact@osmova.com ou passez par le formulaire de contact.

Comment vider le cache ?

Une modification n’apparaît pas ? Elle est probablement bloquée dans l’une des couches. Procédez dans l’ordre :

1. Le navigateur : rechargement forcé avec Ctrl + Maj + R (ou Ctrl + F5) sous Windows, Cmd + Maj + R sur Mac. Une fenêtre de navigation privée permet aussi de vérifier sans cache.
2. L’extension de cache : bouton « Vider le cache » ou « Purger » dans l’administration WordPress.
3. Le cache de l’hébergeur : souvent un bouton dédié dans le panneau d’hébergement.
4. Le CDN : purge complète ou purge de l’URL concernée depuis son tableau de bord.
5. Le DNS, seulement après un changement d’hébergement ou de serveur : la nouvelle adresse se propage à mesure que les caches expirent, au rythme du TTL.

Quelles erreurs éviter ?

• Empiler plusieurs extensions de cache : elles se contredisent et rendent les problèmes impossibles à diagnostiquer.
• Mettre en cache les pages de panier ou de compte.
• Donner une longue durée de vie à des fichiers non versionnés : vos visiteurs garderont l’ancienne feuille de style pendant des semaines.
• Confondre no-cache et no-store : le premier stocke et revérifie, le second ne stocke jamais.
• Tester uniquement en étant connecté à l’administration : la plupart des caches ne s’appliquent pas aux utilisateurs connectés, vous ne voyez donc pas ce que voient vos visiteurs.
• Oublier de purger après une mise à jour du thème ou d’une extension.

En résumé, la mise en cache peut créer des situations déroutantes (une modification invisible, une page périmée), mais elle offre un gain de vitesse et de stabilité considérable. Pour des besoins plus avancés, comme une application à forte charge, voir notre offre d’applications web sur mesure.

Questions fréquentes

Vider le cache de mon navigateur est-il dangereux ?

Non. Vous perdez seulement des copies locales, qui seront retéléchargées. Attention toutefois à ne pas supprimer en même temps les cookies et mots de passe enregistrés si vous ne le souhaitez pas : ce sont des options distinctes.

Combien de temps garder les fichiers en cache ?

Pour les fichiers versionnés (CSS, JavaScript, polices, images), un an est une valeur courante. Pour les pages HTML, une revalidation à chaque visite ou quelques minutes suffisent, selon la fréquence de mise à jour.

Cache et cookies, c’est la même chose ?

Non. Le cache stocke des copies de ressources pour aller plus vite. Les cookies stockent de petites informations liées au visiteur (session, préférences, consentement). Ils sont gérés séparément par le navigateur.

Faut-il une extension de cache sur WordPress ?

Seulement si votre hébergeur ne fournit pas déjà un cache de page. Dans les deux cas, une seule solution de cache de page doit être active.

Pourquoi mes modifications n’apparaissent-elles pas ?

Une copie ancienne est servie par l’une des couches de cache : navigateur, extension, hébergeur ou CDN. Videz-les dans cet ordre, puis vérifiez en navigation privée.

Sources

• IETF RFC 9111 : HTTP Caching (juin 2022)
• MDN : Cache-Control
• MDN : HTTP caching
• Google Search Central : Crawling December, HTTP caching (décembre 2024)
• Chrome for Developers : Serve static assets with an efficient cache policy
• Cloudflare : comportement de cache par défaut
• PHP : OPcache
• WordPress : documentation sur le cache
• WP Super Cache
• web.dev : Back/forward cache
• Wikipedia : CPU cache (historique)