Contrôle du cache : vérifiez que vos pages restent en cache après chaque boost

Un boost demande vos pages pour remplir le cache. Mais demander une page ne garantit pas qu'elle reste en cache : si elle renvoie Cache-Control: private ou un cookie de session, le CDN la sert une fois puis l'oublie, et le visiteur suivant tombe encore sur un MISS.

Le contrôle du cache répond à cette question après chaque boost : vos pages sont-elles vraiment servies depuis le cache ?

Le taux de hit pendant le boost ne suffit pas

Jusqu'ici, chaque run affichait le taux de cache hit mesuré pendant le boost. Ce chiffre est souvent mal lu :

• un taux bas, même 0 %, ne veut pas dire que le boost n'a rien fait. Il a trouvé des pages froides et les a réchauffées ;
• un taux élevé dit que les pages étaient déjà en cache, pas qu'elles le resteront après ce passage.

Aucun des deux ne dit si les pages réchauffées sont restées en cache. C'est ce que mesure le contrôle.

Comment fonctionne le contrôle

Une fois le préchauffage terminé, CacheBoost rappelle une partie des URLs dans les mêmes conditions que le premier appel : même région, même user-agent, mêmes cookies et en-têtes. Chaque deuxième réponse est classée :

• Servie depuis le cache : le CDN répond HIT.
• Probablement en cache : le CDN n'expose pas de statut de cache, mais la deuxième réponse est au moins deux fois plus rapide que la première.
• Non retenue par le cache : le CDN répond MISS. CacheBoost lit les en-têtes de la réponse pour en donner la cause.
• Non concluant : la réponse vient d'un autre point de présence (POP) que le premier appel, l'appel a échoué, ou le statut de cache est introuvable. Ces appels sont exclus du calcul.

Le résultat est le pourcentage de pages servies depuis le cache parmi les appels concluants. À partir de 80 %, le run affiche Cache vérifié. En dessous, Cache à corriger.

Si votre site n'envoie aucun statut de cache, ce qui est fréquent sans CDN, aucune page ne peut être comptée en MISS. Le verdict devient alors Cache probable, et le pourcentage porte sur tout l'échantillon : 3 pages plus rapides sur 10 donnent 30 %, pas 100 %.

Ce que vous voyez sur chaque run

Le détail d'un run montre maintenant :

• Le résultat du contrôle : par exemple « 17 sur 17 pages en cache après le boost », avec le badge Cache vérifié ou Cache à corriger.
• Les pages réchauffées : combien de pages étaient froides avant le boost.
• Le gain mesuré : le temps de réponse moyen au premier appel comparé au deuxième, par exemple 327 ms → 168 ms par page (−49 %).
• Pendant le boost / Après : les deux taux côte à côte, pour voir d'un coup d'œil ce que le boost a changé.
• Le statut par URL : au warm (réchauffée ou déjà en cache) puis au contrôle (confirmée, non retenue ou non concluante).

Le taux de contrôle apparaît aussi dans la liste des runs, dans le graphique d'historique du boost et dans l'email de rapport de run. Si vos pages expirent avant le boost suivant, l'app le signale et vous propose d'allonger le TTL ou d'augmenter la fréquence du boost.

Pourquoi une page n'est pas retenue

Quand une page est servie en MISS au deuxième appel, la cause détectée est affichée à côté de l'URL :

Ce sont les mêmes causes que celles qui font baisser votre taux de cache hit au quotidien. La différence : vous savez maintenant quelles pages sont concernées, et pourquoi, dès le run suivant.

Un exemple réel

Sur un site de 1 690 URLs, un run donne :

• seulement 39 % de pages en cache pendant le boost : 1 037 pages étaient froides, et le boost les a réchauffées ;
• 100 % au contrôle : avec un contrôle sur 1 %, les 17 pages de l'échantillon ont été servies par le cache ;
• un temps de réponse passé de 327 ms à 168 ms par page entre le premier et le deuxième appel (−49 %).

Sans le contrôle, ce run n'aurait affiché que 39 %, ce qui ressemble à un problème. En réalité, le boost a réchauffé plus de 1 000 pages froides et le CDN les a gardées. Avant, ce n'était qu'une supposition. C'est maintenant mesuré à chaque run.

Régler le contrôle

Le réglage se trouve dans les paramètres de chaque boost, section Contrôle du cache :

• Désactivé, 1 %, 10 %, 50 % ou 100 % des appels réchauffés. Les nouveaux boosts démarrent à 10 %.
• Au moins 5 pages par région : sur un petit site, 1 % donnerait moins d'une page. L'échantillon est donc toujours d'au moins 5 pages par région préchauffée.
• Compté dans votre quota : chaque appel de contrôle compte comme un appel. Le formulaire affiche une estimation du nombre d'appels ajoutés par run et par mois. Si votre quota ne suffit pas, l'échantillon est réduit, ou le contrôle est ignoré pour ce run.

Pour un suivi régulier, 1 % ou 10 % suffit. Pour diagnostiquer un problème, passez temporairement à 50 % ou 100 %.

Dans l'API et le serveur MCP

Le contrôle est aussi disponible pour vos intégrations :

• validation_ratio (0, 1, 10, 50 ou 100) sur la création et la modification des boosts, sur le lancement d'un run, et sur le préchauffage à la demande (désactivé par défaut).
• Les runs renvoient un bloc validation (pages vérifiées, HIT, MISS, causes, temps moyens) et un validation_status : verified, to_fix, probable, not_verified ou in_progress. Voir la référence des runs.
• Le serveur MCP suit le même modèle : warm_site accepte validation_ratio, et get_run et list_warm_runs renvoient le verdict. Votre assistant peut lancer un préchauffage puis vous dire si le cache a tenu.

Le contrôle du cache est disponible dès maintenant sur tous les boosts. Ouvrez les réglages d'un boost, choisissez un pourcentage, et le prochain run vous dira si vos pages restent en cache.