Trois étages de cache, et lequel l'hébergeur vous doit

12 novembre 2026

Ou : la page la plus rapide est celle que personne n’a besoin de recalculer.

La réponse courte : un site web peut être mis en cache à trois étages. Le navigateur garde les fichiers qu’il a déjà téléchargés ; le serveur garde les pages ou le code qu’il a déjà préparés ; un CDN garde des copies sur des relais proches des visiteurs. Le navigateur et le CDN obéissent au même en-tête HTTP, Cache-Control, documenté par MDN, qui dit qui peut garder une réponse et pendant combien de temps. Un seul de ces étages dépend vraiment de l’hébergeur : le cache côté serveur, avec OPcache pour PHP et, selon l’offre, un cache de page. C’est souvent lui qui fait l’écart entre la vitesse promise et celle que vous mesurez, un point central de ce qui rend un hébergement rapide.

Les deux autres étages se règlent depuis le site : des en-têtes bien posés suffisent pour que le navigateur ne redemande pas une feuille de style à chaque page, et pour qu’un CDN sache ce qu’il peut garder. Le cache propre à WordPress, avec ses extensions, est un sujet à part ; cette page vaut pour un site PHP sur mesure, un CMS léger ou un site statique.

Pour qui : un site PHP hors WordPress, un CMS léger ou un site statique, qui veut un serveur bien réglé sans l’administrer lui-même.
À partir de : 5,75 € par mois hors taxes pour l’hébergement web Infomaniak, facturés à l’année (relevé du 12 novembre 2026).
Pour démarrer : choisir dans le panneau de l’hébergement la version de PHP la plus récente que le site supporte, puis lire les en-têtes de cache de la page d’accueil avec curl.

Mise en cache d’un site web : les trois étages et les en-têtes qui les trahissent

Étage	Où vit la copie	Qui la règle	Ce qui la trahit
Navigateur	l’appareil du visiteur	les en-têtes `Cache-Control`, `ETag` et `Last-Modified` envoyés par le serveur	`Cache-Control` : `max-age`, `no-cache`, `immutable`
Serveur	la mémoire ou le disque de l’hébergeur	l’hébergeur (OPcache, cache de page) et l’application	aucun en-tête standard : un temps de réponse (TTFB) qui chute
CDN ou proxy	un relais du réseau	`Cache-Control` (`s-maxage`) et les règles du CDN	`Age`, `CF-Cache-Status`, `X-Cache`

Une commande suffit pour lire les en-têtes de n’importe quelle page :

1
2
# Les en-têtes qui disent quel étage de cache a répondu
curl -sI https://exemple.be/ | grep -iE '^(cache-control|age|x-cache|cf-cache-status|etag|last-modified):'

Ce qu’ils signifient, d’après les documentations de référence :

cache-control: public, max-age=31536000, immutable sur une feuille de style versionnée : le navigateur la garde un an et ne la redemande pas, même au rechargement. C’est le réglage idéal pour les fichiers dont le nom change à chaque version.
cache-control: no-cache ne signifie pas « pas de cache » : MDN rappelle que la réponse peut être stockée, mais doit être revalidée auprès du serveur avant chaque réutilisation. Pour interdire tout stockage, c’est no-store.
age: 0 indique que l’objet vient probablement du serveur d’origine ; age: 524 qu’un cache partagé le garde depuis 524 secondes, selon la définition de l’en-tête Age.
cf-cache-status: HIT, MISS ou DYNAMIC chez Cloudflare : trouvé dans le cache, absent, ou non éligible. La documentation de Cloudflare précise que le HTML n’est pas mis en cache par défaut.
x-cache: HIT ou MISS : un en-tête non standard, que Fastly ajoute par défaut à toutes ses réponses ; d’autres relais posent un en-tête du même nom, dont la valeur se lit dans leur propre documentation.

Les en-têtes ne sont donc pas des détails réservés aux administrateurs : ce sont les étiquettes qui disent qui a gardé la réponse, et depuis combien de temps.

Les en-têtes de cache sont les étiquettes du colis : ils disent qui l'a gardé, et combien de temps.

Le cache côté serveur ne se voit pas dans les en-têtes, mais il se mesure. Le premier élément est OPcache : il « améliore les performances de PHP en stockant le bytecode des scripts pré-compilés en mémoire partagée », selon le manuel de PHP, ce qui évite de relire et d’analyser chaque script à chaque visite. Le second est un cache de page (Varnish, le cache de LiteSpeed ou celui de Nginx, selon le logiciel du serveur), qui sert une page déjà calculée sans exécuter PHP.

Ce qu’un hébergeur doit fournir, pour un site PHP qui n’est pas un WordPress :

une version de PHP maintenue, avec OPcache actif, ce qui se vérifie dans le panneau ou avec phpinfo() ;
la possibilité de poser ses propres en-têtes, par un fichier .htaccess sur Apache ou LiteSpeed, ou par le panneau ;
selon le site, un cache de page ou un cache d’objets (Redis, Memcached) pour les requêtes répétées à la base de données.

Un site statique, comme celui-ci, généré par Hugo et servi par Caddy, n’a guère besoin de cache serveur : il n’y a rien à recalculer. Le premier étage fait l’essentiel, avec des fichiers versionnés gardés longtemps et des pages HTML revalidées.

Le chronomètre avant et après

Le seul juge d’un cache serveur est le temps de réponse. Mesurer le TTFB de la même page avec et sans cache, vingt fois de suite, dit ce qu’il apporte ; la méthode est dans mesurer le premier octet.

Quand le relais garde la page

Un CDN qui garde aussi le HTML supprime presque tout le travail du serveur, à condition de purger son cache à chaque modification. Les cas où ce troisième étage se justifie sont triés dans un CDN devant un petit site.

La première digue d’un afflux

Une page servie depuis le cache coûte au serveur une fraction de ce que coûte une page calculée. Le jour d’une campagne, c’est la différence entre un site qui tient et une erreur 508, comme le montre la préparation d’un pic de trafic.