Analytics Cloudflare : comprendre visiteurs, requêtes et taux de cache

Comment lire ensemble quatre métriques Cloudflare

Prenons un exemple générique : quelques centaines de visiteurs uniques, quelques milliers de requêtes, des dizaines de mégaoctets fournis et un taux de cache à un chiffre. Ces signaux ne révèlent pas combien de personnes ont lu une page. Cloudflare observe le trafic HTTP qui traverse son réseau pour les enregistrements DNS proxifiés. Il mesure donc une couche d’infrastructure antérieure aux outils chargés dans le navigateur. Les requêtes peuvent provenir d’internautes, de robots, de contrôles automatiques ou de services externes.

Les visiteurs uniques approchent les sources du trafic ; les requêtes comptent les opérations HTTP ; les données fournies additionnent le volume des réponses ; le pourcentage en cache indique l’activité servie depuis l’edge selon la vue choisie. Vérifiez toujours période, nom d’hôte, filtres et choix entre requêtes ou données transférées.

Les visiteurs uniques sont des adresses IP, pas des personnes identifiées

Pourquoi un visiteur unique ne signifie pas un lecteur

Cloudflare explique qu’une visite est identifiée lorsqu’une adresse IP unique est reconnue pour une requête. Il s’agit d’une estimation technique, pas d’un nombre d’êtres humains, d’utilisateurs connectés ou de sessions. Plusieurs personnes sur un réseau domestique, professionnel ou mobile peuvent partager une IP. Une seule personne peut au contraire apparaître plusieurs fois après un changement de réseau ou d’adresse. Les robots et les requêtes de contenu partiel comptent aussi sans produire une page vue complète.

Le chiffre reste précieux pour étudier tendances, anomalies et distribution si les comparaisons conservent la même fenêtre et les mêmes filtres. Une hausse soudaine peut refléter un intérêt réel, une analyse automatisée, une campagne, un aperçu de lien social ou du trafic hostile. Segmentez par chemin, pays, user agent, action de sécurité et code HTTP avant de retenir une hypothèse. Le total des IP ne prouve pas à lui seul une acquisition commerciale.

Pourquoi les requêtes dépassent largement les visiteurs

Une requête correspond à une opération HTTP. Charger une page peut nécessiter HTML, feuilles de style, JavaScript, images, polices, appels API et redirections, donc produire plusieurs requêtes. Lorsque quelques centaines d’IP génèrent plusieurs milliers de requêtes, le rapport obtenu ne mesure pas l’engagement : ressources déjà dans le navigateur, bot téléchargeant un seul fichier, erreurs, prefetch et architecture du site le modifient fortement.

Données transférées, taux et statuts du cache

Le volume affiché représente les données HTTP transférées dans les réponses observées par Cloudflare, pas la taille du site ni nécessairement le trafic facturé par Vercel. Diviser des totaux arrondis ne donnerait qu’une moyenne approximative par requête, mélangeant HTML, images, erreurs et réponses sans corps. Filtrer par type de contenu et URL est plus utile : cela révèle les objets lourds et fréquents qui atteignent encore l’origine.

Le ratio de requêtes et le ratio d’octets répondent à des questions différentes

La part des requêtes servies depuis le cache mesure combien d’opérations évitent l’origine ; la part des données en cache mesure combien d’octets sont livrés par l’edge. Un site peut afficher peu de HIT mais économiser beaucoup de bande passante si ses grandes images sont en cache. L’inverse est possible avec de nombreux petits fichiers en HIT et de grosses réponses dynamiques. Dans Cache Analytics, une réponse revalidée peut compter côté origine dans la vue Requêtes, mais côté Cloudflare dans la vue Données, car l’origine est consultée alors que le corps reste en cache.

Le statut HIT signifie généralement qu’une réponse est disponible en cache ; MISS impose une récupération auprès de l’origine ; BYPASS traduit une règle ou un signal qui évite le cache ; DYNAMIC désigne un contenu non éligible ; REVALIDATED déclenche un contrôle de fraîcheur. La ventilation par statut, chemin et content type sépare le HTML dynamique légitime des ressources mal configurées ou non réutilisables.

Distinguer trafic humain, robots et menaces

La documentation Zone Analytics précise que, sur l’offre gratuite, le panneau HTTP Traffic inclut les requêtes légitimes ainsi que les robots d’exploration et les menaces. Cloudflare opère à l’edge et voit les clients qui n’exécutent jamais JavaScript. Son nombre de visiteurs uniques peut donc dépasser les utilisateurs et sessions des produits côté navigateur. Un moteur de recherche, un moniteur de disponibilité, un aperçu de lien ou un scanner génère un vrai trafic d’infrastructure sans représenter un prospect.

Pour estimer les personnes intéressées, combinez pages HTML réussies, référents, chemins visités, sources connues, événements de conversion et filtres de bots disponibles. Examinez aussi les pics de réponses 403, 404 et 5xx, les méthodes inhabituelles et les pays inattendus. N’écartez pas toute automatisation : les robots des moteurs favorisent la visibilité et les moniteurs protègent la disponibilité. Il faut associer chaque métrique à la bonne question, pas obtenir le même total partout.

Cloudflare, Web Analytics, GA4 et PostHog mesurent des couches différentes

Zone Analytics décrit le trafic HTTP vu par le réseau. Cloudflare Web Analytics apporte une perspective sur la page et les performances réelles du navigateur. GA4 modélise utilisateurs, sessions, canaux d’acquisition et événements marketing ; PostHog sert particulièrement aux événements produit, funnels et parcours. Les outils navigateur dépendent du chargement du script, du consentement, des bloqueurs, de la navigation achevée et de la qualité du marquage. Cloudflare voit une requête même si la personne part avant le démarrage du code analytique.

Pour une réconciliation utile, alignez période, fuseau horaire, noms d’hôte et environnements, puis comparez des grandeurs compatibles : pages HTML réussies avec vues, conversions avec événements confirmés, requêtes edge avec journaux techniques. Exiger une égalité entre IP uniques et utilisateurs GA4 ou PostHog crée de fausses alertes. Une hiérarchie pratique utilise Cloudflare pour volume et sécurité, Web Analytics pour l’expérience, GA4 pour l’acquisition et PostHog pour le comportement, avec une source serveur pour les conversions critiques.

Pourquoi un faible taux de cache n’est pas forcément une erreur

Un taux faible peut être normal lorsque les requêtes concernent surtout du HTML personnalisé, des API, des aperçus, l’authentification ou des réponses avec cookies et directives privées. MDN avertit que le contenu personnalisé ne doit pas entrer dans un cache partagé, sous peine d’être transmis à un autre utilisateur. Erreurs, redirections, paramètres très variables et méthodes autres que GET peuvent aussi diminuer le ratio. Optimiser consiste à mettre en cache les réponses publiques, stables et réutilisables, pas à poursuivre une cible universelle.

Avec Vercel derrière Cloudflare, deux couches CDN interviennent. Un MISS Cloudflare qui atteint l’origine configurée peut encore être servi par le cache edge de Vercel ; le panneau Cloudflare ne révèle donc pas seul la charge des fonctions ou du serveur applicatif. Examinez ensemble CF-Cache-Status, x-vercel-cache, Cache-Control, CDN-Cache-Control et Vercel-CDN-Cache-Control. Ces en-têtes peuvent viser des destinataires et TTL différents, tandis que des politiques superposées compliquent invalidation et diagnostic.

Réaliser un audit sûr avant de modifier les Cache Rules

Commencez par une semaine représentative et classez les URL en ressources versionnées, pages publiques, HTML dynamique, API publiques et réponses privées. Pour chaque groupe, mesurez requêtes, octets, statut du cache, code HTTP et temps vers l’origine. Étudiez les principales URL en MISS, inspectez les en-têtes sur des requêtes répétées et testez après déploiement et purge. Priorisez les ressources publiques lourdes et fréquentes, tout en excluant connexion, administration, cookies de session et données personnalisées.

• Comparez le ratio de requêtes et le ratio d’octets sans les confondre.
• Définissez clés de cache et TTL par chemin et contenu, pas par une règle globale.
• Testez paramètres, cookies, autorisation, langue et variantes avant le déploiement.
• Observez Cloudflare et Vercel et documentez la couche propriétaire de chaque réponse.
• Surveillez 4xx, 5xx, fraîcheur et conversions avec l’amélioration du cache.

Une règle globale “cache everything” sans inventaire peut servir des données privées ou obsolètes et masquer des incidents. Déployez par petits groupes d’URL avec un retour arrière, puis vérifiez côté navigateur et origine. Nos services d’infrastructure, d’analytics et de performance construisent une mesure fiable ; pour auditer votre configuration Cloudflare et Vercel, contactez AE Digital Agency.