Votre tableau de bord CDN affiche un voyant vert, votre score de vitesse a augmenté, vous en déduisez donc que vos pages sont servies à partir du cache. Or, ce n'est souvent pas le cas, et les outils de vérification qui vous indiquent que “ votre CDN fonctionne ” ne font que confirmer que vos images sont mises en cache, ce qui n'a jamais été la question.
Ce guide vous explique comment vérifier si votre CDN met réellement vos pages en cache, et pas seulement vos ressources : l'en-tête à surveiller, la signification de chaque valeur, et la marche à suivre lorsque votre code HTML est discrètement renvoyé vers le serveur d'origine à chaque requête.
Principaux enseignements
- Par défaut, un CDN met en cache vos fichiers CSS, JS et vos images, mais pas vos pages HTML ; par conséquent, le fait que “ mes ressources soient consultées ” ne signifie pas que vos pages sont mises en cache.
- Lire l'en-tête de réponse « cache-status » (
cf-cache-statussur Cloudflare) sur la PAGE elle-même, aveccurl -Iou dans l'onglet « Réseau » du navigateur : « HIT » signifie « cache », tandis que « DYNAMIC » ou « BYPASS » indiquent que la requête a été dirigée vers le serveur d'origine. - « DYNAMIC » signifie que le CDN n'a jamais considéré la page comme pouvant être mise en cache ; « BYPASS » signifie qu'il l'aurait considérée comme telle, mais qu'un cookie ou un
Cache-ControlL'en-tête l'a empêché. - Le
ÂgeCet en-tête n'apparaît que dans une réponse mise en cache et sa valeur augmente à mesure que l'objet reste dans le cache ; c'est donc la preuve la plus évidente qu'une page est bel et bien servie depuis la périphérie. - Sur une boutique WooCommerce, il faut également vérifier le contraire : le panier, la page de paiement et la section « Mon compte » ne doivent PAS être mis en cache, sinon la session d'un client sera servie au client suivant.
Comment vérifier si votre CDN met réellement une page en cache
Demandez la page et consultez l'en-tête de réponse « cache-status ». Sur Cloudflare, cet en-tête est cf-cache-status: « HIT » signifie que la page provenait du cache du CDN, « MISS » ou « EXPIRED » signifie qu'elle a été récupérée cette fois-ci sur votre serveur d'origine, et « DYNAMIC » ou « BYPASS » signifie que le CDN ne l'a pas du tout servie à partir de son cache.
Le moyen le plus rapide de le voir consiste à exécuter une commande dans votre terminal :
curl -sI https://yoursite.com/ | grep -i cf-cache-statusLe nom de l'en-tête varie selon le fournisseur (Fastly utilise x-cache, le cache du serveur LiteSpeed utilise x-litespeed-cache, KeyCDN et d'autres utilisent leur propre en-tête), mais le principe est le même : il suffit de lire l'en-tête « cache-status » renvoyé par votre pile.
Voici le hic, et la raison même pour laquelle ce guide existe. Si vous effectuez ce même test sur une image ou une feuille de style, vous obtiendrez presque toujours un résultat « HIT », car les CDN les mettent en cache par défaut. Ce résultat ne vous apprend donc rien sur vos pages. Donc Testez l'URL de la page, pas le logo.
Vous préférez utiliser un navigateur ? Ouvrez la page, appuyez sur F12, allez dans l'onglet « Réseau », actualisez la page, puis cliquez sur la toute première requête, qui correspond au document HTML lui-même, et lisez cf-cache-status dans la section « En-têtes de réponse ». Veillez simplement à cliquer sur la ligne du document située tout en haut et non sur une image ou un script situé en dessous, sinon vous devrez recommencer à vérifier les ressources.
La vérification du cache en 30 secondes
- Exécutez la commande « curl -I » sur l'URL d'une véritable page (pas d'une image)
- Lire l'en-tête « cache-status » (cf-cache-status sur Cloudflare)
- « HIT » ou « REVALIDATED » signifie que la page provient du cache.
- « DYNAMIC » ou « BYPASS » signifie que le trafic a été acheminé vers votre source à chaque fois.
- Vérifiez à l'aide de l'en-tête « Age », qui n'apparaît que dans une réponse mise en cache
Pourquoi vos images sont mises en cache, mais pas vos pages HTML, en général ?
Un CDN met en cache les fichiers statiques en fonction de leur extension et ne touche pas à vos fichiers HTML. Dans Selon les propres termes de Cloudflare, “ Le CDN de Cloudflare ne met pas en cache les fichiers HTML ou JSON par défaut. ” Sa liste par défaut comprend les formats CSS, JS, JPG, PNG, WEBP, WOFF2, PDF et des dizaines d’autres, mais pas .html et comme il n'y a rien qui redirige vers une page, vos pages sont redirigées vers l'origine, sauf si vous ajoutez une règle.
C'est pourquoi un “ vérificateur de cache CDN ” peut donner le feu vert à un site dont aucune page n'est mise en cache. L'outil récupère une ressource, détecte un HIT et signale que l'opération a réussi. Pendant ce temps, vos pages réelles, celles qui sont lentes et alimentées par une base de données, que vous souhaitiez voir mises en cache, vous revenez toujours à votre point de départ à chaque visite.
Vous pouvez constater cette répartition sur des sites réels. Voici des extraits d'en-têtes authentiques que j'ai analysés sur trois sites publics, tous protégés par Cloudflare :
$ curl -sI https://kinsta.com/ | grep -i cf-cache-status
cf-cache-status : DYNAMIC
$ curl -sI https://wpengine.com/ | grep -i cf-cache-status
cf-cache-status : DYNAMIC
$ curl -sI https://yoast.com/ | grep -iE 'cf-cache-status|age'
cf-cache-status : HIT
age : 22Deux d'entre eux diffusent leur code HTML de manière DYNAMIQUE, directement depuis la source, tandis que le troisième le met en cache en périphérie grâce à un véritable système de mise en cache, dont l'utilisation ne cesse de croître Âge. Même CDN, résultats opposés, et la seule façon de savoir dans quel camp se trouve votre site est de consulter l'en-tête de votre propre page. (Captures réelles, juillet 2026 ; sites publics, les en-têtes sont accessibles à tous.)
Signification de chaque valeur de « cf-cache-status » et mesures à prendre en fonction
Voici tous les cf-cache-status la valeur, ce que Cloudflare explique qu'elle signifie, et la seule action qu'elle recommande. Les outils de vérification vous indiquent la valeur ; la colonne « Action » est la partie qu'ils omettent.
| Valeur | Ce que Cloudflare explique qu'il signifie | Que faire à ce sujet ? |
|---|---|---|
| HIT | “ La ressource a été trouvée dans le cache de Cloudflare. ” | Fonctionne comme prévu. Vérifiez que l'« Âge » augmente bien, ce qui confirme qu'il s'agit d'un cache réel et durable. |
| MISS | “ La ressource n'a pas été trouvée dans le cache de Cloudflare et a été fournie par le serveur web d'origine. ” | Normal lors de la première consultation. Actualisez la page ; si le statut « HIT » n'apparaît jamais, cela signifie que la page n'est pas mise en cache. |
| EXPIRÉ | “ La ressource a été trouvée dans le cache de Cloudflare, mais son délai de validité était expiré et elle a donc été fournie depuis le serveur d'origine. ” | C'est acceptable avec modération. Le message « EXPIRED » affiché en permanence indique que la durée de vie (TTL) de la page est trop courte. |
| REVALIDÉ | La source a confirmé que la copie mise en cache était inchangée et qu'elle avait été fournie à partir du cache. | En cours. Le nœud périphérique a vérifié l'origine et a réutilisé la page mise en cache. |
| DYNAMIQUE | “ Cloudflare ne considère pas que ce ressource puisse être mise en cache et vos paramètres Cloudflare ne lui indiquent pas explicitement de le faire. ” | Paramètre par défaut pour le HTML. Ajoutez une règle de mise en cache si vous souhaitez que cette page soit mise en cache. |
| BYPASS | L'origine a demandé à Cloudflare de ne pas utiliser le cache via Cache-Control, ou bien la réponse a créé un cookie. | Identifiez le cookie ou l'en-tête qui désactive la page ; corrigez le problème pour le panier et la connexion ; il s'agit d'un bug ailleurs. |
| PÉRIMÉ | Contenu fourni à partir du cache alors qu'il était périmé, car Cloudflare n'a pas pu accéder au serveur d'origine. | Vérifiez l'état de votre serveur d'origine ; le serveur périphérique prend le relais d'un serveur qui n'a pas répondu. |
| MISE À JOUR | Le contenu a expiré, mais il est servi à partir du cache pendant que le serveur d'origine le met à jour en arrière-plan. | Fonctionnement normal sous charge immédiatement après l'expiration. Aucune intervention nécessaire. |
| AUCUN / INCONNU | Cloudflare a généré une réponse qui ne peut pas être mise en cache (un Worker, une redirection, une règle WAF). | La requête a reçu une réponse avant d'atteindre le cache ; c'est normal sur ces routes. |
Un en-tête supplémentaire joue ici un rôle discret mais essentiel : Âge. Cloudflare ne le renvoie que “ pour les réponses servies à partir du cache ”, et il comptabilise le nombre de secondes pendant lesquelles l'objet y est resté, le compteur étant remis à zéro en cas de purge ou de revalidation. Ainsi, un nombre croissant de Âge C'est la preuve la plus évidente qu'une page provient bel et bien du serveur d'origine, et son absence sur une page que vous pensiez trouver en cache est le signe qu'il n'en est rien.
Que signifie « cf-cache-status DYNAMIC » et en quoi diffère-t-il de « BYPASS » ?
“ DYNAMIC ” signifie que le CDN n’a jamais considéré la page comme pouvant être mise en cache ; il l’a donc récupérée depuis votre serveur d’origine. Selon les termes de Cloudflare, la ressource n’était « pas éligible à la mise en cache » et vos paramètres n’indiquaient pas le contraire. Il s’agit de l’état par défaut d’une page HTML sans règle de mise en cache, ce qui explique précisément pourquoi tant de personnes recherchent cette information : elles ont activé le CDN, ont vu la mention « DYNAMIC » sur chaque page et ont supposé qu’il y avait un problème.
BYPASS, c'est une tout autre histoire. Cloudflare serait a mis la page en cache, mais votre serveur d'origine lui a expressément demandé de ne pas le faire, soit par le biais d'un Cache-Control en-tête défini sur no-cache, privéou max-age=0, ou parce que la réponse a créé un cookie. Cloudflare ne mettra pas en cache une réponse contenant un Définir un cookie en-tête, par conception.
C'est la différence concrète qui détermine la solution à adopter. DYNAMIC correspond à un écart de configuration : Vous n'avez tout simplement pas encore configuré le CDN pour qu'il mette le code HTML en cache ; la solution consiste donc à définir une règle de mise en cache. BYPASS est une option permettant de se désinscrire, disponible sur la page : Pour résoudre le problème, il faut retrouver le cookie ou le Cache-Control C'est l'en-tête qui s'en charge. Sur une page normale, un cookie de session égaré est généralement en cause ; sur une page de panier ou de paiement, ce « BYPASS » est correct et il vaut mieux ne pas y toucher.
Comment mettre votre code HTML en cache sur Cloudflare sans causer de problèmes
Pour mettre en cache du contenu HTML, vous devez ajouter une règle de mise en cache qui marque les URL correspondantes comme “ Éligibles à la mise en cache ” (l’équivalent ancien était une règle de page “ Tout mettre en cache ”). L’erreur consiste à l’appliquer aveuglément à l’ensemble de votre site, car cela inclut les pages qui doivent rester spécifiques à chaque utilisateur. Limitez la portée de la règle aux pages pouvant être mises en cache en toute sécurité et excluez les pages personnelles ; c’est là que réside le piège de WooCommerce, abordé dans la section suivante.
Il est également utile de connaître les paramètres par défaut de Cloudflare. Lorsque votre serveur d'origine n'envoie aucun Cache-Control ou Date d'expiration En ce qui concerne l'en-tête, Cloudflare met en cache les codes 200, 206 ou 301 pendant 120 minutes, les codes 302 ou 303 pendant 20 minutes, et les codes 404 ou 410 pendant seulement 3 minutes ; tout le reste n'est pas mis en cache. Ainsi, un cache de courte durée sur une page que vous pensiez voir rester en mémoire est souvent simplement dû au fait que le serveur d'origine ne répond pas et que Cloudflare revient alors à la valeur par défaut de deux heures.
Bon à savoir : dans les formules Free, Pro et Business, que la plupart des utilisateurs de WordPress utilisent, Cloudflare respecte déjà les Cache-Control envoyée par votre serveur d'origine. Ainsi, si vos pages ne sont pas mises en cache, l'en-tête de votre propre pile (ou de votre Cache et couche d'optimisation WordPress) est le premier élément à examiner, et curl -I ça te le met sous les yeux.
Sur une boutique WooCommerce, vérifiez que le panier et le processus de paiement ne sont PAS mis en cache
Sur une boutique en ligne, vous vérifiez simultanément deux éléments contradictoires : que les pages normales soient bien mises en cache (HIT), et que le panier, la page de paiement et la page « Mon compte » ne le soient PAS (BYPASS ou DYNAMIC). Une boutique où tout est mis en cache (HIT) présente davantage de dysfonctionnements qu’une boutique où rien ne l’est, car une page de connexion mise en cache peut servir le panier et la session d’un client directement au visiteur suivant.
WooCommerce précise clairement quelles pages doivent rester dynamiques. Conformément à ses propres recommandations en matière de mise en cache, à l'exception des pages “ Panier ”, « Paiement » et « Mon compte », car « ces pages doivent rester dynamiques puisqu'elles affichent des informations spécifiques au client actuel et à son panier ». Les cookies qui indiquent une session personnelle, et que votre cache ne doit en aucun cas mettre en cache, sont les suivants :
woocommerce_cart_hashetwoocommerce_items_in_cart, qui indiquent à WooCommerce quand le contenu du panier change.wp_woocommerce_session_, qui associe chaque client aux données de son panier dans la base de données.woocommerce_recently_viewed, qui alimente le widget « Produits récemment consultés ».
Les bons plugins de mise en cache gèrent cela pour vous : WP Rocket exclut automatiquement ces trois pages lorsqu’il détecte WooCommerce, et WooCommerce indique activement à WP Super Cache d’ignorer le panier, la page de paiement et “ Mon compte ”. Une règle personnalisée de type « tout mettre en cache » définie au niveau du CDN ne tient pas compte de cette distinction, et c’est là que réside le danger.
La vérification s'effectue à l'aide d'une seule commande, qui cible les pages devant rester privées :
curl -sI https://yourstore.com/cart/ | grep -i cf-cache-statusSur la page du panier, vous DEVEZ voir « BYPASS » ou « DYNAMIC ». Si le message « HIT » s'affiche, arrêtez-vous immédiatement et corrigez votre règle de cache avant qu'un client ne voie le panier d'un autre utilisateur. C'est le seul endroit où un « HIT » est synonyme d'échec.
Ce que montrent réellement les en-têtes de notre propre site
Voici un extrait tiré de notre propre site, qui soulève un point pertinent. wpconsults.com n'utilise absolument pas Cloudflare en amont de son code HTML ; il utilise un cache de pages serveur LiteSpeed. L'en-tête à consulter est donc le suivant : x-litespeed-cache, et non cf-cache-status:
$ curl -sI https://www.wpconsults.com/ | grep -iE 'x-litespeed-cache|server'
x-litespeed-cache : hit
server : LiteSpeedCela coup signifie que la page a été servie à partir du cache de pages du serveur lui-même, et non à partir d’un nœud périphérique du CDN ; cette distinction est importante, car les gens ont tendance à confondre les deux. Un cache périphérique de CDN (Cloudflare) stocke votre page dans des centres de données situés à proximité du visiteur. A cache des pages serveur (LiteSpeed, WP Rocket, WP Super Cache) stockent le code HTML généré sur votre propre serveur d'origine afin que le PHP ne soit pas réexécuté. Vous pouvez en utiliser un seul, les deux ou aucun ; chaque couche dispose de son propre en-tête d'état à consulter.
Notre site est hébergé sur une plateforme basée sur LiteSpeed fournie par Hostinger, c'est pourquoi le cache de page se trouve sur le serveur et qu'il n'y a pas de cf-cache-status à trouver. Dans les deux cas, les ressources statiques se comportent comme on peut s'y attendre :
$ curl -sI https://www.wpconsults.com/wp-content/.../style.css | grep -i cache-control
cache-control : public, max-age=604800Un cache de navigateur vidé depuis sept jours pour la feuille de style, pas de problème. C'est la répartition habituelle : les ressources sont mises en cache et sans intérêt, ce sont les pages qu'il faut réellement vérifier.
Pourquoi votre taux de réussite du cache est inférieur à ce que vous attendiez
Même lorsque la mise en cache HTML est activée, votre taux de réussite de mise en cache (la part des requêtes servies à partir du cache plutôt que de la source d’origine) est généralement inférieur au chiffre affiché en tête de tableau de bord. Ce chiffre est en grande partie constitué d’éléments qui allaient de toute façon être servis à partir du cache, il vous donne donc une image plus flatteuse de la situation. Les pages qui comptent, à savoir les pages dynamiques, ne représentent qu’une petite partie et sont les premières à ne pas être servies depuis le cache après une purge ou un déploiement.
Évaluez donc la mise en cache en vous basant sur l'en-tête de vos principaux modèles de page (page d'accueil, article, catégorie ou collection), et non sur un pourcentage global à l'échelle du site. Un pourcentage élevé pour les pages DYNAMIQUES signifie simplement que vos images assument la majeure partie de la charge, tandis que vos pages lentes continuent d'accéder au serveur d'origine ; c'est également la raison pour laquelle l'état de la mise en cache apparaît dans votre Core Web Vitals et TTFB bien avant qu'elle n'apparaisse dans un chiffre récapitulatif.
Alors, est-ce que votre CDN met réellement vos pages en cache ?
Honnêtement, la plupart du temps, la réponse est “ pas comme vous le pensez ”. Le feu vert et l'indice de vitesse évaluent vos ressources, et celles-ci n'ont jamais été le problème. Si c'était mon site, je passerais deux minutes à lancer curl -I sur trois modèles de page réels : un article, une catégorie et le panier, avant de vous fier à un tableau de bord, car l'en-tête ne vous met pas autant en valeur qu'un score.
Configurez la mise en cache HTML de manière réfléchie, excluez-en les pages spécifiques à chaque utilisateur et vérifiez à nouveau l'en-tête chaque fois que vous modifiez une règle ou un plugin. L'objectif n'est pas d'avoir un CDN qui met tout en cache, ni un qui ne met rien en cache ; l'objectif est de savoir quelles pages sont mises en cache et de s'assurer que c'est bien le cas. Les outils vous indiquent que le CDN est activé. Seulement l'en-tête de réponse vous indique que cela fonctionne, et, sur un site très fréquenté, c'est ce qui fait la différence entre faire face à un pic de trafic et faire fondre ton origine sous son poids.
Vous ne savez toujours pas ce que vos en-têtes vous indiquent ?
Si l'en-tête « cache-status » affiche une valeur que vous ne parvenez pas à expliquer, ou si vos pages restent bloquées sur « DYNAMIC » et que vous ne comprenez pas pourquoi, nous contacter ou m'envoyer un courriel et je vais y jeter un œil. Il vaut la peine de bien s'assurer que vos pages soient servies à partir du cache et que les bonnes pages n'y figurent pas.
Vous souhaitez que nos publications apparaissent plus souvent sur Google ?
En un clic, Google affichera ce site dans votre rubrique « À la une ».
Audit des chaînes de redirection : comment identifier et aplatir toutes les chaînes de redirection de votre site
Google StoreBot : ce qu'il explore, pourquoi il est bloqué et comment résoudre les problèmes d'accès
Comparaison des alternatives à WP-Cron : Cron du serveur, Action Scheduler et services externes
