De 0,198 s à 0,050 s avec un cache de page maison, et le crochet posé au mauvais endroit

Une page servie en 0,03 seconde au lieu de 0,19 : médiane de douze relevés du temps jusqu’au premier octet, le 2026-10-19, sur la même adresse, avec un paramètre de requête (jamais mise en cache) puis sans (servie par le cache). Le gain vient d’un cache de page écrit à la main, un fichier d’environ 240 lignes, sans extension installée. L’essentiel du travail n’a pourtant pas été d’écrire le cache : il a été de trouver où poser la purge.

Pourquoi l’écrire soi-même

Les extensions de cache du marché sont bonnes et couvrent des cas que nous n’avons pas : plusieurs serveurs, un stockage mémoire, des règles par type de contenu, une interface pour tout ça. Sur un site de contenu hébergé en mutualisé, le besoin tient en une phrase : un visiteur anonyme doit recevoir du HTML déjà écrit, sans qu’une seule ligne du moteur ne s’exécute.

WordPress prévoit exactement ce point d’entrée. Un fichier déposé à un emplacement réservé est chargé avant tout le reste, avant les extensions, avant le thème, avant même de savoir quelle page est demandée. S’il trouve une copie valable, il l’envoie et s’arrête là. C’est cette sortie anticipée qui vaut l’écart mesuré, pas la finesse de l’algorithme.

Vous lisez la suite le mardi

Chaque semaine, la lettre reprend une série publique : la valeur, sa date, sa source. Quatre minutes, le mardi matin.

Ne pas remplirAdresse e-mailJe m'inscris

En validant, vous acceptez de recevoir la lettre. Désinscription en bas de chaque envoi.

Le crochet posé au mauvais endroit ne se plaint pas

Un cache sans purge est un piège. La suite logique est d’écrire la purge dans le même fichier que le cache : c’est là que vit la connaissance des chemins, du format, du dossier de stockage. C’est aussi le seul endroit où elle ne fonctionnera pas.

Ce fichier d’entrée est chargé par le serveur web, pas par la ligne de commande. Un script lancé en console ne le charge jamais. Les crochets qu’il déclare sont donc muets pour tout ce qui ne passe pas par un navigateur : un import en masse, un script de correction, une génération de pages. C’est-à-dire pour à peu près tout ce qui modifie réellement le contenu d’un site d’annuaire ou de média.

Le symptôme est déplaisant parce qu’il n’en est pas un. Rien ne casse, rien n’avertit. Le script s’exécute, annonce ses milliers de lignes traitées, et les visiteurs continuent de recevoir la version d’avant pendant des jours. La panne est silencieuse et lente, la pire des deux qualités.

La purge a donc été déplacée dans une extension à chargement obligatoire, qui se charge partout : requête web, ligne de commande, tâche planifiée. Elle expose aussi une commande de purge manuelle, ce qui évite d’avoir à ouvrir une interface pour vider une page.

Ce qu’un cache ne doit jamais figer

Trois cas sont exclus, et cette liste est plus importante que le reste du code. Une adresse portant une chaîne de requête, parce qu’un paramètre change le contenu et qu’un cache qui les ignore sert la mauvaise page. Un visiteur porteur d’un cookie de session, parce qu’un administrateur doit voir l’état réel, pas une photographie. Une page absente, parce qu’un 404 mis en cache survit à la correction du lien.

Le dossier de stockage, lui, refuse toute demande directe. Un cache de page contient du HTML final, y compris celui de pages qui pourraient ne plus exister. Il n’a rien à faire dans une adresse publique, et un fichier déposé dans un dossier servi finit toujours par être demandé.

Le cache qu’on ne contrôle pas

Une couche reste hors de portée. L’hébergeur exploite son propre cache de bord, en amont du serveur, qui garde sa copie du HTML pendant la durée annoncée par nos en-têtes. Il ne se vide pas depuis la machine : après une purge locale, l’ancienne page peut encore sortir de chez eux.

Il n’y a pas de contournement, seulement un arbitrage. Nous annonçons une durée de vie courte, cinq minutes. On perd le bénéfice d’un cache de bord agressif, on gagne de savoir qu’une correction est visible partout en cinq minutes au pire. Sur un site où le contenu change plusieurs fois par jour, ce n’est pas un compromis, c’est le bon réglage.

La règle générale se pose là : la durée de vie d’un cache devrait être inversement proportionnelle à votre capacité à le purger. Ce que vous pouvez vider à volonté peut vivre longtemps. Ce que vous ne pouvez qu’attendre doit vivre peu.

Vérifier qu’il tourne, et pas seulement qu’il existe

Un cache s’installe en dix minutes et se croit fonctionnel en deux. Le contrôle qui compte se fait en trois passages sur la même adresse : premier appel après enregistrement, la page doit être manquée et régénérée ; deuxième appel, elle doit sortir du disque ; puis on modifie le contenu et le premier appel suivant doit à nouveau être manqué.

Sans le troisième temps, on mesure une accélération et on ne mesure pas la purge. Or c’est la purge qui décide si le cache est un outil ou une dette. Un site rapide qui affiche des informations périmées est plus coûteux qu’un site lent qui dit la vérité.