Publié le 23 juin 2022, dernière mise à jour le 13 octobre 2026
Les métriques de CrUX sont basées sur des API de plate-forme Web standards exposées par les navigateurs. Dans l'ensemble de données BigQuery en particulier, ces données sont agrégées au niveau de l'origine. Les propriétaires de sites qui ont besoin d'une analyse et d'insights plus détaillés sur les performances de leur site (par exemple, au niveau de l'URL) peuvent utiliser les mêmes API pour collecter des données de mesure de l'utilisateur réel (RUM) détaillées pour leurs propres origines. Notez que, bien que toutes les API soient disponibles dans Chrome, d'autres navigateurs peuvent ne pas être compatibles avec l'ensemble complet des métriques.
La plupart des métriques sont représentées sous forme d'agrégation d'histogrammes, ce qui permet de visualiser la distribution et d'approximer les valeurs de centile.
Cumulative Layout Shift
"Le Cumulative Layout Shift (CLS) est une métrique importante, centrée sur l'utilisateur, qui permet de mesurer la stabilité visuelle, car elle permet de quantifier la fréquence à laquelle les utilisateurs rencontrent des changements de mise en page inattendus. Un CLS faible permet de s'assurer que la page est agréable."
DOM Content Loaded
"La métrique DOMContentLoaded indique le moment où le document HTML initial a été entièrement chargé et analysé, sans attendre la fin du chargement des feuilles de style, des images et des sous-frames."
Affichage du premier élément
"La métrique First Paint indique le moment où le navigateur a effectué le premier rendu après la navigation. Elle exclut la peinture d'arrière-plan par défaut, mais inclut la peinture d'arrière-plan non par défaut. Il s'agit du premier moment clé qui intéresse les développeurs lors du chargement d'une page : le moment où le navigateur a commencé à afficher la page."
First Contentful Paint
"La métrique First Contentful Paint (FCP) indique le moment où le navigateur a effectué le premier rendu de texte, d'image (y compris les images d'arrière-plan), de canevas non blanc ou de SVG. Cela inclut le texte avec des polices Web en attente. C'est la première fois que les utilisateurs peuvent commencer à consommer le contenu de la page."
Interaction to Next Paint
"La métrique Interaction to Next Paint (INP) est une métrique de terrain qui évalue la réactivité. L'INP enregistre la latence de toutes les interactions tout au long du cycle de vie de la page. La valeur la plus élevée de ces interactions, ou une valeur proche de la plus élevée pour les pages comportant de nombreuses interactions, est enregistrée comme INP de la page. Une INP faible garantit que la page sera toujours réactive."
La métrique Interaction to Next Paint (INP) a été ajoutée à l'ensemble de données CrUX en février 2022. Cette nouvelle métrique capture la latence de bout en bout des événements individuels et offre une image plus globale de la réactivité globale d'une page tout au long de sa durée de vie.
Largest Contentful Paint
La métrique Largest Contentful Paint (LCP) est une métrique importante, centrée sur l'utilisateur, qui permet de mesurer la vitesse de chargement perçue, car elle marque le point dans la chronologie de chargement de page lorsque le contenu principal de la page a probablement été chargé. Un LCP rapide permet de rassurer l'utilisateur sur l'utilité de la page.
Type de ressource Largest Contentful Paint
"Le LCP indique le délai d'affichage de la plus grande image ou vidéo, ou du plus grand bloc de texte visible dans la fenêtre d'affichage, par rapport au moment où l'utilisateur a accédé à la page pour la première fois."
web.dev/articles/lcp - What elements are considered for LCP
Le texte et les images (y compris l'image de la première image vidéo) ont souvent des caractéristiques de chargement et des techniques d'optimisation très différentes. Comprendre le rapport entre les types de ressources LCP vous permet de mieux comprendre vos métriques LCP et vos chemins d'optimisation.
Pour en savoir plus, consultez l'article de blog sur le lancement des types de ressources LCP.
Sous-parties de l'image Largest Contentful Paint
"L'optimisation du LCP peut être une tâche plus complexe lorsque PageSpeed Insights ne vous indique pas comment améliorer cette métrique. Pour les tâches complexes, il est généralement préférable de les diviser en tâches plus petites et plus faciles à gérer, et de les traiter séparément."
web.dev/articles/optimize-lcp - LCP breakdown into subparts
La décomposition des LCP d'images en sous-parties les plus critiques permet d'utiliser des recommandations et des bonnes pratiques spécifiques pour optimiser chaque partie.
Les sous-parties des images LCP sont fournies dans quatre métriques distinctes :
largest_contentful_paint_image_time_to_first_bytelargest_contentful_paint_image_resource_load_delaylargest_contentful_paint_image_resource_load_durationlargest_contentful_paint_image_element_render_delay
Les sous-parties ne sont incluses que pour les images. Elles n'incluent pas les images de la première image vidéo, car elles sont un peu plus complexes, car nous ne pouvons pas mesurer le temps de téléchargement complet (notez que les premières images vidéo sont incluses dans la métrique de type de ressource LCP, où cette complication n'est pas pertinente).
Les sous-parties de texte ne sont pas non plus incluses, car elles sont moins utiles et faussent les chiffres des LCP d'images. Pour les sites qui sont principalement constitués de LCP de texte, les métriques globales TTFB et globales FCP sont des répartitions utiles, bien qu'elles concernent tous les LCP et non spécifiquement les LCP de texte.
Pour en savoir plus, consultez l'article de blog sur le lancement des sous-parties des images LCP.
Types de navigation
La métrique Types de navigation fournit une répartition du pourcentage de pages vues des navigations suivantes :
| Type | Description |
|---|---|
navigate |
Chargement de page qui ne correspond à aucune autre catégorie. |
navigate_cache |
Chargement de page pour lequel la ressource principale (le document HTML principal) a été diffusée à partir du cache HTTP. Les sites utilisent souvent la mise en cache pour les sous-ressources, mais le document HTML principal est souvent mis en cache beaucoup moins souvent. Lorsqu'il peut l'être, cela peut entraîner des améliorations notables des performances, car il peut être mis en cache localement et sur un CDN. |
reload |
L'utilisateur a rechargé la page, soit en appuyant sur le bouton d'actualisation, soit en appuyant sur Entrée dans la barre d'adresse, soit en annulant la fermeture d'un onglet. Les rechargements de page entraînent souvent une revalidation sur le serveur pour vérifier si la page principale a changé. Un pourcentage élevé de rechargements de page peut indiquer une frustration de l'utilisateur. |
restore |
La page a été rechargée après le redémarrage du navigateur ou d'un onglet qui avait été supprimé pour des raisons de mémoire. Pour Chrome sur Android, ces éléments sont signalés comme "reload". |
back_forward |
Navigation dans l'historique, ce qui signifie que la page a été consultée et consultée récemment. Avec une mise en cache correcte, ces expériences devraient être raisonnablement rapides, mais nécessitent toujours le traitement de la page et l'exécution de JavaScript, ce que le bfcache évite. |
back_forward_cache |
Navigation dans l'historique qui a été diffusée à partir du bfcache. L'optimisation de vos pages pour tirer parti du bfcache, en supprimant les bloqueurs, devrait entraîner des expériences plus rapides. Les sites doivent donc rechercher |
prerender |
La page a été prérendue, ce qui, comme le bfcache, peut entraîner des chargements de page quasi instantanés. |
Dans certains cas, le chargement d'une page peut être une combinaison de plusieurs types de navigation. Dans ce cas, CrUX signale la première correspondance dans l'ordre inverse du tableau (de bas en haut).
Pour en savoir plus, consultez l'article d'annonce sur les types de navigation.
Onload
"L'événement de chargement est déclenché lorsque la page et ses ressources dépendantes ont fini de se charger."
Délai aller-retour
Fournit une estimation du délai aller-retour HTTP (couche application) au début de la navigation, en fonction des connexions réseau récentes.
Cette métrique est basée sur la rtt
propriété de l'API Network Information, qui est la même API que celle responsable de l'ancienne
dimension Effective Connection Type (ECT).
Pour en savoir plus, consultez l'article de blog sur le lancement des types de ressources LCP.
Métriques expérimentales
Les métriques expérimentales sont disponibles à la fois dans l'ensemble de données CrUX à l'aide de BigQuery et dans l'API CrUX, bien que toutes les métriques ne soient pas disponibles dans les deux. Ces métriques sont susceptibles d'être modifiées à mesure qu'elles évoluent en fonction des commentaires des utilisateurs. Consultez les notes de version pour vous tenir à jour des dernières modifications.
Métriques expérimentales des signaux Web essentiels pour la navigation logicielle
La version d'octobre 2026 a introduit des versions expérimentales des métriques des signaux Web essentiels, y compris les navigations logicielles :
experimental_largest_contentful_paint_with_softnavsexperimental_interaction_to_next_paint_with_softnavsexperimental_cumulative_layout_shift_with_softnavs
Ces métriques incluent à la fois les chargements de page complets et les navigations logicielles.
Pour en savoir plus, consultez Présentation des métriques expérimentales des Core Web Vitals dans le rapport UX Chrome.
Time to First Byte
Le TTFB dans CrUX n'est collecté que lors du chargement complet de la page, contrairement à d'autres minuteurs (tels que LCP) qui sont également collectés lors des navigations dans le cache en arrière/en avant (bfcache) et sur les pages prérendues. Par conséquent, la taille de l'échantillon du TTFB peut être inférieure à celle d'autres métriques et ne peut pas nécessairement être comparée directement à celles-ci. Le TTFB dans CrUX inclura les chargements de page à froid, les chargements de page mis en cache et les chargements de page à partir d'une connexion établie (par exemple, les chargements de page intra-site).
Le TTFB n'est pas une mesure directe du temps de réponse du serveur, car il inclut des mesures antérieures, y compris le temps de redirection, et est affecté par le fait qu'une réponse est diffusée à partir du cache, du CDN ou du serveur. Cela est particulièrement visible dans les données de terrain comme CrUX, alors que les tests en laboratoire sont généralement moins affectés par ces facteurs, car l'URL de destination est testée et annule souvent de manière répétée les modifications de mise en cache.
Popularité
La métrique de classement par popularité est une mesure relative de la popularité du site dans l'ensemble de données CrUX, mesurée par le nombre total de navigations sur l'origine. Le classement est sur une échelle log10 avec des demi-étapes (par exemple, les 1 000 premiers, les 5 000 premiers, les 10 000 premiers, les 50 000 premiers, les 100 000 premiers, les 500 000 premiers, le million de premiers, etc.), chaque classement excluant le précédent (par exemple, les 5 000 premiers correspondent en fait à 4 000 URL, à l'exclusion des 1 000 premières). La limite supérieure est dynamique à mesure que l'ensemble de données augmente.
La popularité est fournie à titre indicatif pour une analyse générale, par exemple pour déterminer les performances par pays pour les 1 000 premières origines.
Autorisations de notifications
Pour les sites Web qui demandent l'autorisation d'afficher des notifications aux utilisateurs, cette métrique représente la fréquence relative des réponses des utilisateurs aux invites : accepter, refuser, ignorer ou fermer.
Métriques sur les annonces
Chrome fournit des métriques et des outils publics pour les sites et d'autres acteurs, comme les annonceurs, afin de mieux comprendre l'expérience publicitaire des utilisateurs réels et son impact.
- Nombre d'annonces : cette métrique décrit le nombre d'annonces qu'un utilisateur type voit à la fois sur le site.
- Densité d'annonces : cette métrique décrit l'équilibre entre le contenu et la visibilité publicitaire d'un utilisateur type.
- Poids de l'annonce : processeur : cette métrique décrit la consommation de processeur par les annonces, ce qui peut avoir un impact sur les performances.
- Poids de l'annonce : réseau : cette métrique décrit la consommation de ressources réseau par les annonces.
Nous nous attendons à ce que ces métriques soient particulièrement utiles pour les annonceurs Web et les services qu'ils utilisent pour diffuser des annonces. Un large éventail d'acteurs de l'écosystème publicitaire nous ont indiqué que ces métriques pourraient améliorer la façon dont ils évaluent les opportunités publicitaires et prennent des décisions concernant les produits publicitaires.
Pour en savoir plus, consultez l'article de blog sur le lancement des métriques sur les annonces ad metrics launch blog post et la documentation sur les mesures des annonces ad measurements documentation.