Dimension Core/Dash : Navigateur

Dimension : Page & Navigation : URLs (u)

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 la performance des Core Web Vitals à travers le prisme du logiciel spécifique effectuant le rendu de votre application (par ex. Chrome, Firefox, Safari, Edge, Samsung Internet).

La dimension Navigateur isole les contraintes logicielles, les différences de 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) : Ce jeu de données collecte exclusivement des données d'utilisateurs ayant consenti sur Chrome (et certains dérivés Chromium). Il exclut aveuglément le trafic provenant de Firefox (moteur Gecko) et Safari (moteur WebKit).
• CoreDash RUM : Collecte des données depuis chaque navigateur qui exécute le snippet JavaScript.

Pour de nombreux sites web, les navigateurs non-Chrome représentent 30 à 50 % du trafic. Se fier uniquement au 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

Les différents moteurs de navigateur gèrent les ressources, compilent le JavaScript et calculent la géométrie de mise en page différemment. Utilisez cette dimension pour identifier les échecs spécifiques au 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 main-thread.

• Firefox (SpiderMonkey) : Firefox gère la priorisation des tâches différemment de Chrome. Un event listener lourd qui passe sur Chrome peut causer un input delay notable sur Firefox en raison des différences dans la manière dont le main-thread effectue le yielding.
• Safari (JavaScriptCore) : présente souvent des comportements distincts concernant la latence au "tap" sur mobile. Une logique d'hydratation qui semble instantanée sur Android (Chrome) peut déclencher des délais sur iOS en raison de modèles de propagation d'événements distincts.

Largest Contentful Paint (LCP)

Les divergences 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 signale un LCP rapide mais que Firefox traîne, vérifiez votre stratégie de format d'image. Vous servez peut-être du AVIF à Chrome tout en utilisant un fallback vers des JPEG plus lourds pour les anciennes versions de navigateur manquant de support.
• Priority Hints : Chrome respecte agressivement fetchpriority="high". Les navigateurs qui ignorent cet attribut traitent la ressource LCP avec une priorité standard, gonflant artificiellement le délai de chargement.
• Protocoles de connexion : Edge et Firefox peuvent négocier les connexions HTTP/3 (QUIC) différemment dans les environnements d'entreprise ou les réseaux restreints, impactant la composante 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) effectuent le rendu des lignes de base et du tracking des polices légèrement différemment. Si vous ne faites pas correspondre parfaitement les métriques de votre police de fallback, le bloc de texte se redimensionnera lors du chargement de la web font, causant un shift dans un navigateur mais pas dans l'autre.
• Réservation de la barre 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 layout shifts basés sur la largeur qui sont invisibles lors du développement sur Mac mais proéminents pour les utilisateurs Windows.

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

Le cas d'usage principal pour cette dimension est la "Validation du moteur".

• Identifier l'anomalie : Triez votre tableau Navigateur par Impact ou Volume. Cherchez 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 : Vérifiez 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éboguer : Si Edge est lent mais que Chrome est rapide (tous deux utilisent Blink), enquêtez sur les extensions tierces ou les logiciels de sécurité d'entreprise courants chez les utilisateurs Edge qui injectent des scripts dans le DOM. Si Firefox est lent, auditez votre CSS pour des propriétés non standard ou du layout thrashing que Gecko pénalise plus lourdement que Blink.

Navigateurs Legacy et Embarqués

Utilisez la dimension Navigateur pour identifier les freins à la 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 Legacy : Vous pouvez trouver du trafic provenant de versions de navigateur 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 pour réduire la taille du bundle pour les utilisateurs modernes.