Les causes courantes d'un cache inefficace sur Cloudflare

Par défaut, Cloudflare ne met en cache qu'une liste stricte d'extensions de fichiers statiques (images, CSS, JS, polices). Les pages HTML et réponses dynamiques sont transmises directement à l'origine avec le statut cf-cache-status: DYNAMIC. Sur les sites à contenu, ces réponses HTML non cacheables représentent souvent la majorité du trafic, ce qui plafonne mécaniquement le hit ratio affiché dans le dashboard même quand tous les assets sont mis en cache. De plus, plusieurs facteurs techniques empêchent couramment la mise en cache :

  • En-têtes HTTP contradictoires émis par l'origine : Des directives telles que Cache-Control: no-store, private ou max-age=0 forcent Cloudflare à ignorer le cache (statut BYPASS).
  • Présence d'en-têtes Set-Cookie : Si votre backend (WordPress, Laravel, Node.js) envoie systématiquement un cookie de session sur chaque page publique, Cloudflare désactive la mise en cache pour éviter la fuite de données entre visiteurs.
  • Paramètres d'URL (Query Strings) fragmentés : Les balises marketing (UTM, gclid, fbclid) créent des clés de cache distinctes pour une même ressource, provoquant des requêtes MISS répétées.
  • Conflits entre Page Rules et Cache Rules modernes : L'empilement de règles historiques mal hiérarchisées annule les directives d'Edge TTL.

Le moyen le plus rapide d'identifier le facteur qui vous concerne est de lire directement les en-têtes de réponse. HIT signifie que l'edge a servi l'objet, MISS qu'il a dû le récupérer à l'origine, BYPASS qu'une règle ou un en-tête a explicitement désactivé le cache, et DYNAMIC que l'URL n'est pas considérée comme cacheable du tout. Si votre origine croule sous les requêtes non mises en cache, la surcharge se manifeste souvent ailleurs d'abord, par exemple sous forme d'erreurs 521, 522 ou 524 intermittentes vers l'origine.

La méthode éprouvée pour atteindre plus de 80 % de Cache Hit

Pour transformer Cloudflare en véritable bouclier de performance sans casser la dynamique de votre application :

  • Mise en place de Cache Rules granulaires : Définir des règles d'Edge TTL précises avec contournement automatique (bypass) lorsque des cookies d'authentification ou de panier sont présents.
  • Séparation du Browser TTL et de l'Edge TTL : Exploiter l'en-tête s-maxage pour conserver les ressources en cache sur le réseau Cloudflare tout en contrôlant la fraîcheur côté navigateur.
  • Normalisation des Query Strings : Ignorer ou réordonner les paramètres marketing pour unifier la clé de cache sans impacter vos outils de mesure analytique.
  • Activation du Tiered Cache : Regrouper les requêtes des datacenters régionaux vers des nœuds de cache centraux afin de minimiser drastiquement les allers-retours vers votre serveur d'origine.

Un dernier principe : mettez en cache agressivement à l'edge mais restez conservateur côté navigateur. Le cache edge reste sous votre contrôle direct et peut être purgé à tout moment, alors que les caches des navigateurs sont stockés sur les terminaux des visiteurs. Séparer les deux TTL est ce qui rend un cache edge long sûr pour du contenu fréquemment mis à jour.

Corriger pas à pas : la checklist pratique

Suivez ces étapes dans l'ordre. Chacune isole un mode de défaillance précis avant que vous ne touchiez au moindre réglage, ce qui vous permet de toujours savoir quel changement a réellement résolu le problème. D'autres checklists testées sur le terrain sont réunies dans notre hub de guides Cloudflare.

  1. Inspectez les en-têtes de l'edge. Depuis n'importe quel terminal, interrogez une URL représentative et examinez les en-têtes de cache : 
    curl -sI https://www.exemple.com/page | grep -iE "cf-cache-status|cache-control|set-cookie|cf-ray"
    La valeur cf-cache-status vous dit pourquoi l'objet a été mis en cache ou non, et cf-ray encode le datacenter qui a répondu (par exemple CDG pour Paris). Répétez le test sur un asset statique et sur une page HTML, car ils se comportent généralement différemment.
  2. Comparez avec la réponse de l'origine. Interrogez directement votre serveur d'origine, en contournant le proxy, pour voir les en-têtes qu'il envoie réellement : 
    curl -sI --resolve www.exemple.com:443:203.0.113.10 https://www.exemple.com/page
    Remplacez l'IP par celle de votre origine. Tout no-store, private, max-age=0 ou Set-Cookie sur une page publique explique immédiatement un statut BYPASS.
  3. Auditez les Cache Rules dans le dashboard. Ouvrez Caching > Cache Rules et listez toutes les règles de la zone. Cloudflare les évalue de haut en bas, mais lorsque plusieurs règles correspondent à la même requête, c'est la dernière correspondance qui l'emporte sur chaque réglage qu'elles définissent toutes les deux. Une règle historique permissive placée en fin de liste peut donc écraser silencieusement tout ce qui précède. Vérifiez aussi Rules > Page Rules pour d'anciennes entrées qui écraseraient encore l'Edge TTL.
  4. Créez une règle de cache explicite pour le contenu cacheable. Ciblez les hostnames et chemins sûrs à mettre en cache, fixez un Edge TTL cohérent avec votre cadence de publication (un jour pour des pages éditoriales, un mois pour des assets versionnés, par exemple), et dans la même règle contournez le cache quand un cookie de session ou de panier est présent, afin qu'un utilisateur authentifié ne reçoive jamais une copie partagée.
  5. Normalisez la clé de cache. Dans la Cache Rule, sous Cache key, ignorez l'ordre des query strings et retirez les paramètres de tracking connus (utm_*, fbclid, gclid). Cela regroupe des centaines d'entrées de cache dupliquées d'un même asset en une seule.
  6. Activez le Tiered Cache. Rendez-vous dans Caching > Tiered Cache et activez Smart Tiered Caching. Les datacenters régionaux récupèrent alors leurs objets depuis des hubs de niveau supérieur au lieu de votre origine, ce qui compte dès que vous servez du trafic depuis plusieurs pays.
  7. Purgez, puis re-testez. Lancez Caching > Configuration > Purge Everything, puis répétez le test curl -I. Attendez-vous à un MISS sur la première requête et un HIT sur la seconde ; si la seconde est toujours BYPASS ou DYNAMIC, revenez à l'étape une et réexaminez les en-têtes.

Les erreurs fréquentes qui maintiennent le hit ratio bas

  • Mettre en cache le HTML sans bypass sur les cookies : Servir une copie edge partagée d'une page qui affiche des données propres à chaque utilisateur peut exposer le contenu de session d'un visiteur à un autre. Associez toujours un cache HTML agressif à un bypass explicite sur les cookies d'authentification, de panier ou de session.
  • Empiler des règles contradictoires : Mélanger d'anciennes Page Rules, des Cache Rules et des en-têtes d'origine qui fixent chacun un TTL différent produit un comportement qui varie d'un datacenter à l'autre. Choisissez une seule source de vérité, en général les Cache Rules, et supprimez le reste.
  • Poursuivre un hit ratio de 100 % : Les endpoints dynamiques, les requêtes POST et les chemins d'administration ne seront jamais mis en cache, et c'est très bien ainsi. Mesurez le ratio sur les assets cacheables ; une zone saine affiche typiquement 80 à 95 % sur ceux-là, pas sur le trafic total.
  • Modifier un TTL sans purger : Les objets déjà stockés à l'edge conservent le TTL avec lequel ils ont été mis en cache. Après tout changement de TTL, purgez le cache, sinon les utilisateurs voient du contenu périmé pendant des heures et vous pouvez conclure à tort que la nouvelle règle ne fonctionne pas.
  • Tester le mauvais hostname : Comparer www.exemple.com au domaine racine, ou interroger un hostname de staging avec d'autres enregistrements DNS, mène à de fausses conclusions. Confirmez toujours avec cf-ray que vous observez bien la zone et le datacenter auxquels vous pensez.

Questions fréquentes

Pourquoi cf-cache-status affiche DYNAMIC sur des fichiers que je pensais mis en cache ?

DYNAMIC signifie que l'URL ne correspond pas à la liste par défaut des extensions de fichiers cacheables, ce qui est le plus souvent le cas des pages HTML. Tout ce qui est en dehors de cette liste a besoin d'une Cache Rule explicite pour devenir éligible au cache edge. Vérifiez le chemin exact demandé, car un répertoire peut se comporter différemment d'un autre.

Les Cache Rules sont-elles disponibles sur le plan Free ?

Oui. Les Cache Rules, la normalisation des query strings et le Tiered Cache sont inclus dans tous les plans, y compris Free ; seul le nombre de règles actives augmente avec les plans payants. La mise à niveau n'est nécessaire que pour des options avancées comme le cache reserve ou des quotas de règles plus élevés, pas pour les correctifs décrits dans ce guide.

En combien de temps les modifications de Cache Rules prennent-elles effet ?

Les changements de règles se propagent à l'edge en quelques secondes. Les objets déjà stockés conservent en revanche le TTL avec lequel ils ont été mis en cache, donc purgez le cache après avoir modifié une règle si vous voulez que le nouveau comportement s'applique immédiatement. En pratique, un Purge Everything suivi de quelques requêtes de warm-up suffit à vérifier le résultat.

Un hit ratio bas peut-il affecter mon SEO ?

Indirectement, oui. Les réponses non mises en cache rendent les pages plus lentes, ce qui dégrade les Core Web Vitals, et une origine saturée par un trafic de bots non mis en cache peut finir par servir des erreurs aux crawlers. Si les moteurs de recherche reçoivent des erreurs ou des timeouts de façon répétée, l'indexation en souffre ; notre guide sur le blocage accidentel de Googlebot et la chute de SEO couvre le diagnostic côté crawler.

Besoin d'aide pour décharger votre origine et optimiser vos Core Web Vitals ?

CF Garage analyse vos en-têtes HTTP, audite vos flux de requêtes et configure des règles de cache avancées adaptées à votre stack technique. Tarif fixe, résultat mesuré et garanti.

Voir nos offres

Ressources et guides complémentaires