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. 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,privateoumax-age=0forcent Cloudflare à ignorer le cache (statutBYPASS). - 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
MISSré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.
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-maxagepour 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.
CF Garage