Télécharger les sites web qui utilisent Cloudflare Browser Insights

À propos de Cloudflare Browser Insights

Personne n’a ajouté ce script à la main. La balise de mesure de Cloudflare Browser Insights est injectée par un réseau de périphérie au passage de la réponse, si bien qu’une détection décrit un interrupteur basculé dans le tableau de bord d’un fournisseur et non une décision prise dans une base de code. Aucun dépôt ne contient le code, aucun relecteur ne l’a validé, et c’est cette différence qui rend la fiche intéressante.

Cloudflare Inc. livre la fonction sous licence Proprietary dans son tableau de bord, et nous la classons dans la catégorie Analytics. La balise collecte des temps mesurés chez de vrais visiteurs plutôt que lors de tests synthétiques : le temps qu’une page a mis à devenir utile, la rapidité d’arrivée du premier octet, l’ampleur des déplacements de la mise en page pendant le chargement. Datant de 2019, l’outil appartient à la génération de supervision née quand les tests en laboratoire ont cessé de convaincre à eux seuls, et il rend compte au tableau de bord du site lui-même plutôt qu’à un compte d’analytics séparé.

En octobre 2026 nous voyons la balise sur 809 398 sites. On en compte 619 120 aux États-Unis, et .com porte une grande partie du mélange de suffixes. Une concentration de cette ampleur n’est pas une affirmation sur les pays qui se soucient de performance. La concentration suit la forme de la base de clients du fournisseur lui-même, laquelle penche vers le même pays et le même espace de noms, si bien que la géographie de la balise est en réalité la géographie de la plateforme sous-jacente.

Pour un chercheur, l’inférence utile va de côté plutôt que vers le bas. Un site qui porte la balise passe par le proxy du fournisseur, se trouve sur une formule où la fonction est disponible, et a un exploitant qui a ouvert un tableau de bord et activé délibérément quelque chose. La présence sépare donc les comptes qui configurent leur périphérie du groupe bien plus large qui y pointe son DNS une fois et n’y revient jamais, et cette séparation est difficile à obtenir autrement. Les fournisseurs de supervision concurrents lisent le même champ comme un signal de déplacement, puisqu’un site qui collecte déjà des mesures d’utilisateurs réels a admis que le problème compte pour lui et n’a encore payé personne pour un outil plus poussé. Les consultants y voient un critère de qualification avant un argumentaire de performance.

Une vérification domaine par domaine indique si un site a activé un interrupteur, ce qui vaut rarement la requête. La liste téléchargeable dit à quoi cet interrupteur est corrélé : quelles plateformes, quels systèmes de boutique et quelles stacks d’analytics apparaissent à côté de lui, comment la population se répartit entre pays et suffixes de domaine, et quelle est vraiment la taille du segment adressable avant que quiconque bâtisse une campagne sur une supposition. L’agrégation est aussi le seul moyen de regarder la population bouger, puisque le fait intéressant à propos d’une fonction de périphérie est en général sa courbe d’adoption plutôt que tel ou tel compte particulier.

Les limites sont simples et méritent d’être respectées. La détection dépend de l’apparition de la balise dans la réponse que reçoit notre robot, et les fonctions de périphérie peuvent être activées par nom d’hôte, désactivées sur certaines routes ou supprimées pour les clients automatisés, si bien qu’une absence constitue une preuve faible à propos d’un site donné. Le fournisseur a aussi renommé et remanié ses produits de supervision plus d’une fois, et les variantes anciennes et récentes ne se ressemblent pas toujours à l’intérieur d’une page. La population que nous publions doit se lire comme les sites où une balise reconnaissable est apparue sur une page explorée, ce qui constitue un plancher, et non comme la totalité des comptes ayant discrètement activé la fonction quelque part dans un tableau de bord.