Dimension Core/Dash : Navigateur

Dimension : Navigateur (browser)

La dimension Navigateur regroupe les données de performances en fonction de 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 des données exclusivement auprès des utilisateurs ayant accepté de participer sur Chrome (et certains dérivés de Chromium). Il exclut aveuglément le trafic de Firefox (moteur Gecko) et de Safari (moteur WebKit).
• CoreDash RUM : collecte des données à partir de chaque navigateur qui exécute l'extrait 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 navigateur gèrent les ressources, compilent le JavaScript et calculent la géométrie de la mise en page différemment. Utilisez cette dimension pour identifier les défaillances 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 thread principal.

• Firefox (SpiderMonkey) : Firefox gère la hiérarchisation des tâches différemment de Chrome. Un écouteur d'événements lourd qui passe dans Chrome peut causer un délai d'entrée perceptible dans Firefox en raison des différences dans la façon dont le thread principal yield.
• 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 délais 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 signale un LCP rapide mais que Firefox est à la traîne, vérifiez votre stratégie de format d'image. Il se peut que vous serviez du AVIF à Chrome tout en utilisant un fallback avec des JPEG plus volumineux pour les anciennes versions de navigateur qui ne le supportent pas.
• Priority Hints : Chrome respecte de manière agressive fetchpriority="high". Les navigateurs qui ignorent cet attribut traitent la ressource LCP avec une priorité standard, gonflant artificiellement le Load Delay.
• Protocoles de connexion : Edge et Firefox peuvent négocier les connexions HTTP/3 (QUIC) différemment dans les environnements d'entreprise ou de réseau restreint, 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 à l'aide d'une logique sous-pixel distincte.

• Rendu des polices (Gecko vs Blink) : Firefox (Gecko) et Chrome (Blink) effectuent le rendu des lignes de base et de l'approche des polices 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 au chargement de la police Web, provoquant 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é provoque souvent des décalages de mise en page basés sur la largeur qui sont invisibles lors du développement sur un Mac mais importants pour les utilisateurs Windows.

Flux de travail : isoler les régressions spécifiques au moteur

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

• Identifier l'anomalie : triez votre table de navigateurs 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 : 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 (les deux utilisent Blink), étudiez 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 pour y trouver des propriétés non standard ou un layout thrashing que Gecko pénalise plus lourdement que Blink.

Navigateurs hérités et intégrés

Utilisez la dimension Navigateur pour identifier les freins de performances de « 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 héritées : vous pouvez trouver du trafic provenant de versions obsolètes de navigateurs. 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.