Cache de bord
Le cache de bord est la copie de page conservée par le serveur de l'hébergeur, en avant de WordPress, et servie au visiteur sans que le site soit exécuté.
Définition
Le cache de bord est la copie de page conservée par le serveur de l’hébergeur, en avant de WordPress, et servie au visiteur sans que le site soit exécuté. C’est la couche la plus rapide, et celle qu’on oublie quand une correction reste invisible en ligne.
Où se place cette couche ?
Entre le visiteur et votre site, du côté de l’hébergeur.
Une page WordPress se fabrique à chaque appel : le serveur interroge la base, assemble le thème, exécute les extensions actives, puis produit le HTML. Une extension de cache évite ce travail en gardant le résultat dans un fichier, mais elle reste à l’intérieur de WordPress, donc PHP démarre quand même. Le cache de bord est encore un cran plus haut : il est tenu par le serveur web de l’hébergeur, qui garde la réponse complète et la renvoie telle quelle au visiteur suivant, sans réveiller ni PHP ni WordPress.
Le vocabulaire des spécifications HTTP appelle cela un cache partagé, par opposition au cache du navigateur qui ne sert qu’une personne. Une même page peut donc exister en plusieurs copies au même instant : celle de l’hébergeur, celle de l’extension, celle du navigateur de chaque visiteur, et parfois celle d’un réseau de diffusion intercalé. Elles ne se vident pas ensemble, et elles ne se périment pas ensemble.
Chez les hébergeurs qui font tourner le serveur LiteSpeed, cette couche porte un nom commercial et s’active sans réglage de votre part. L’extension LiteSpeed Cache installée dans WordPress ne fabrique pas cette copie, elle lui parle : elle lui indique quelles pages garder et quand les jeter. Sur d’autres hébergements, le même rôle est tenu par un logiciel séparé placé devant le serveur web, Varnish étant le plus répandu. Le principe ne change pas : une version statique de la page est gardée en mémoire et servie telle quelle.
La même mécanique vaut pour les fichiers qui composent la page, feuilles de style, scripts et images. Ils sont eux aussi gardés en réserve, et c’est la raison pour laquelle une image remplacée sous le même nom de fichier continue parfois d’apparaître à l’ancienne. Un réseau de diffusion de contenu, souvent désigné par son sigle anglais CDN, ajoute encore une couche du même genre, répartie sur plusieurs points géographiques.
Ce qu’il faut en retenir. Quand une modification ne se voit pas en ligne alors que tout a été vidé côté WordPress, le suspect le plus probable n’est pas votre site. C’est la copie gardée en amont, que votre tableau de bord ne montre pas.
Comment savoir si la page servie vient de la copie ?
En lisant les en-têtes de la réponse, pas en regardant la page.
Une page servie depuis la copie et une page fraîchement calculée sont rigoureusement identiques à l’écran. La différence se lit dans les en-têtes HTTP, que le navigateur reçoit mais n’affiche pas. Sur un hébergement LiteSpeed, la réponse porte un en-tête x-lsadc-cache dont la valeur vaut hit quand la copie a servi et miss quand le site a dû produire la page.
Deux façons de le voir, sans rien installer : l’onglet Réseau des outils de développement du navigateur, en cliquant sur la première ligne de la liste, ou une commande curl -I depuis un terminal. Dans les deux cas, l’information est dans la réponse, jamais dans le code de la page.
Pour forcer une réponse fraîche et voir ce que le site produit réellement, il suffit d’ajouter à l’adresse un paramètre unique, par exemple ?v=12345, avec une valeur différente à chaque essai. La couche de cache considère cette adresse comme une page nouvelle, qu’elle n’a pas en réserve. Sur WordPress, évitez le paramètre ?m=, qui est réservé et renvoie une page introuvable trompeuse.
Relevé du 18 septembre 2026 sur ilti.fr, douze adresses appelées une à une, en lecture seule. Onze répondent 200, une redirige. Cinq réponses portent x-lsadc-cache: hit, six portent miss : sur un site à faible trafic, une page sur deux n’est tout simplement pas en réserve au moment où on la demande. L’écart de temps de réponse entre les deux familles ne laisse aucune place au doute : de 40 à 54 millisecondes avant le premier octet pour les pages servies depuis la copie, de 258 à 299 millisecondes pour celles que le site a dû produire, soit environ six fois plus. Deuxième enseignement, tiré du même relevé : une page mesurée en miss est repassée en hit à 42 millisecondes quatre-vingt-dix secondes plus tard, sans autre événement que ma propre visite. C’est le premier visiteur qui paie le calcul, les suivants héritent de la copie. Enfin, la même page rappelée avec un paramètre unique est repartie en miss à 296 millisecondes, ce qui confirme que le paramètre force bien une réponse fraîche.
Pourquoi une purge ne suffit pas toujours
Parce que chaque couche a son propre bouton, et qu’ils ne sont pas reliés.
Le bouton de purge d’une extension agit sur les fichiers qu’elle a écrits. Selon l’hébergement, il transmet ou non l’ordre à la couche du serveur. Quand il ne le transmet pas, ou quand la demande porte sur une seule adresse, la copie en amont continue de vivre sa vie et le visiteur voit toujours l’ancienne page, parfois pendant des heures.
Constater sur l’adresse nue
Ouvrir la page telle qu’un visiteur la reçoit, sans paramètre ajouté, et lire l’en-tête de cache. Une vérification faite avec un paramètre unique ne prouve rien : elle contourne précisément la couche qu’on veut tester.
Vider entièrement, pas au détail
Une purge d’une seule adresse peut répondre que tout s’est bien passé sans avoir rien vidé. En cas de doute, c’est la purge complète qui fait foi, suivie d’une nouvelle lecture de l’en-tête.
Vérifier depuis une autre machine
Votre propre navigateur garde lui aussi une copie, et un rechargement forcé ne vide que la sienne. Une navigation privée ou un second appareil évite de confondre les deux couches.
Attendre la minute d’après
Une modification de fichier PHP peut mettre jusqu’à une minute à être prise en compte sur les hébergements qui gardent le code compilé en mémoire. Un fichier correctement déployé peut donc paraître absent pendant quelques dizaines de secondes.
Un cas particulier mérite d’être connu : les pages qui dépendent du visiteur, panier, compte client, formulaire porteur d’un jeton de sécurité, ne doivent jamais être gardées par cette couche. Les hébergeurs les excluent par défaut sur les installations WordPress courantes, mais une page fabriquée sur mesure sort de ces règles et se signale à la main.
Questions fréquentes
Faut-il désactiver le cache de bord pour travailler sur le site ?
Non, et ce serait contre-productif. Une personne connectée à l’administration reçoit déjà des pages non mises en cache, c’est la règle par défaut. Le besoin réel est de savoir lire l’en-tête de réponse pour distinguer ce que vous voyez de ce que voit un visiteur non connecté.
Est-ce que cette copie fausse les mesures de performance ?
Elle les explique. Un outil qui tombe sur une page en réserve mesure une réponse très rapide, un outil qui tombe sur une page absente mesure le site réel. Le même outil, lancé deux fois d’affilée sur la même adresse, peut donc donner deux résultats très différents sans que rien n’ait changé. La mesure honnête consiste à noter l’état du cache en même temps que le temps de réponse.
Combien de temps la copie est-elle conservée ?
Cela dépend de la configuration de l’hébergeur, et vous ne la fixez généralement pas depuis WordPress. Ce qui est sous votre contrôle, c’est l’ordre de vidage envoyé quand un contenu change. Sur un site dont les pages évoluent peu, une durée longue est un avantage, à condition que la publication déclenche bien le vidage de la page concernée.
Le cache de bord remplace-t-il une extension de cache ?
Il couvre le même besoin pour les visiteurs anonymes, et il le fait mieux puisqu’il répond plus tôt. L’extension reste utile pour ce qui ne relève pas de la copie de page : les réglages d’optimisation des fichiers, la gestion des exclusions et surtout l’ordre de vidage automatique à chaque publication.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.