Dimension Core/Dash : Navigateur

Dimension : Navigateur (browser)

La dimension Navigateur regroupe les données de performance basées sur la chaîne User Agent envoyée par le client. Cela vous permet d'auditer les performances des Core Web Vitals à travers le prisme du logiciel spécifique qui effectue le rendu de votre application (par ex., Chrome, Firefox, Safari, Edge, Samsung Internet).

La dimension Navigateur isole les contraintes logicielles, les différences entre les moteurs de rendu (Blink, Gecko, WebKit) et la compatibilité des scripts tiers.

RUM vs. CrUX

Comprendre la source de vos données est important pour une analyse d'ingénierie précise.

• CrUX (Chrome User Experience Report) : Cet ensemble de données collecte exclusivement les données des utilisateurs ayant accepté le suivi sur Chrome (et certains dérivés de Chromium). Il exclut aveuglément le trafic provenant de Firefox (moteur Gecko) et de Safari (moteur WebKit).
• CoreDash RUM : Collecte des données à partir de chaque navigateur qui exécute le snippet JavaScript.

Pour de nombreux sites web, les navigateurs autres que Chrome représentent 30 à 50 % du trafic. S'appuyer uniquement sur CrUX crée un angle mort : vous optimisez pour le moteur V8 de Google tout en négligeant les moteurs SpiderMonkey (Firefox) et JavaScriptCore (Safari) utilisés par un segment massif de votre audience.

Diagnostics spécifiques aux métriques

Différents moteurs de navigation gèrent les ressources, compilent le JavaScript et calculent la géométrie de la mise en page (layout) différemment. Utilisez cette dimension pour identifier avec précision les défaillances spécifiques à un moteur.

Interaction to Next Paint (INP)

Les problèmes d'INP sont directement corrélés à l'efficacité du moteur JavaScript du navigateur et à la planification du thread principal (main-thread scheduling).

• Firefox (SpiderMonkey) : Firefox gère la hiérarchisation des tâches différemment de Chrome. Un écouteur d'événements lourd qui passe sans problème sur Chrome peut causer un délai de saisie (input delay) perceptible sur Firefox en raison des différences dans la façon dont le thread principal effectue le yielding.
• Safari (JavaScriptCore) : Présente souvent des comportements distincts concernant la latence de "tap" sur mobile. Une logique d'hydratation qui semble instantanée sur Android (Chrome) peut déclencher des retards sur iOS en raison de modèles de propagation d'événements distincts.

Largest Contentful Paint (LCP)

Les écarts de LCP signalent généralement un manque de parité des fonctionnalités ou de support pour les API d'optimisation modernes.

• Négociation de format : Si Chrome rapporte un LCP rapide mais que Firefox prend du retard, vérifiez votre stratégie de format d'image. Il se peut que vous serviez de l'AVIF à Chrome tout en utilisant un fallback vers des JPEG plus lourds pour les anciennes versions de navigateurs qui manquent de support.
• Priority Hints : Chrome respecte agressivement fetchpriority="high". Les navigateurs qui ignorent cet attribut traitent la ressource LCP avec une priorité standard, ce qui gonfle artificiellement le délai de chargement (Load Delay).
• Protocoles de connexion : Edge et Firefox peuvent négocier les connexions HTTP/3 (QUIC) différemment dans des environnements d'entreprise ou de réseaux restreints, ce qui a un impact sur le composant TTFB du LCP.

Cumulative Layout Shift (CLS)

Les moteurs de rendu calculent la géométrie des pixels en utilisant une logique de sous-pixels distincte.

• Rendu des polices (Gecko vs Blink) : Firefox (Gecko) et Chrome (Blink) rendent les lignes de base des polices et l'espacement (tracking) de manière légèrement différente. Si vous ne faites pas correspondre parfaitement les métriques de votre police de fallback, le bloc de texte se redimensionnera lorsque la police web se chargera, causant un décalage dans un navigateur mais pas dans l'autre.
• Réservation des barres de défilement : Les navigateurs Windows (Edge/Firefox/Chrome) réservent un espace physique pour les barres de défilement, tandis que les navigateurs macOS les superposent. Cette disparité cause souvent des décalages de mise en page basés sur la largeur qui sont invisibles lors du développement sur un Mac mais très marqués pour les utilisateurs Windows.

Workflow : Isoler les régressions spécifiques au moteur

Le principal cas d'usage de cette dimension est la « Validation du moteur ».

• Identifier l'anomalie (Outlier) : Triez votre table Navigateur par Impact ou Volume. Recherchez un navigateur spécifique (par ex., Firefox Mobile) qui a un score significativement pire que la référence (Chrome Mobile).
• Vérifier l'environnement : Contrôlez si le problème est strictement lié au navigateur ou à une combinaison de navigateur et d'OS (par ex., Edge sur Android vs Edge sur Windows).
• Débogage : Si Edge est lent mais que Chrome est rapide (tous deux utilisent Blink), analysez les extensions tierces ou les logiciels de sécurité d'entreprise communs aux utilisateurs d'Edge qui injectent des scripts dans le DOM. Si Firefox est lent, auditez votre CSS à la recherche de propriétés non standard ou de layout thrashing que Gecko pénalise plus lourdement que Blink.

Navigateurs anciens et embarqués

Utilisez la dimension Navigateur pour identifier les freins de performance de la « longue traîne ».

Navigateurs In-App : Le trafic provenant d'Instagram, LinkedIn ou Facebook s'exécute souvent dans des WebViews restreintes qui se comportent différemment du navigateur mobile natif.

Versions anciennes : Vous pourriez trouver du trafic provenant de versions de navigateurs obsolètes. Si celles-ci génèrent un INP élevé, configurez vos outils de build (Babel/PostCSS) pour servir les polyfills nécessaires ou, si le volume est négligeable, prenez la décision stratégique d'abandonner le support afin de réduire la taille du bundle pour les utilisateurs modernes.