Publié le 11 février 2025
La version de février 2025 du rapport d'expérience utilisateur Chrome (CrUX) inclut de nouvelles métriques (et des modifications) intéressantes:
- Sous-composants et types de ressources de l'image Largest Contentful Paint (LCP)
- Détails du délai aller-retour (DAR)
- Suppression de la dimension "Type de connexion compatible"
Chacune d'elles fournit des informations plus détaillées sur les métriques de performances des origines et des URL disponibles dans CrUX. Dans cet article, nous allons expliquer pourquoi.
Informations de diagnostic sur le LCP
Nous avons initialement présenté le concept de sous-composants de LCP lors de Google I/O 2022 comme une technique efficace pour décomposer la durée de LCP des pages avec des LCP d'image en composants plus petits afin de vous assurer que vous consacriez vos efforts à optimiser la ou les causes appropriées d'un LCP élevé.
L'analyse des données de laboratoire HTTP Archive de cette présentation a montré que le temps de téléchargement des images était souvent la partie la plus courte du temps de LCP. De nombreux outils de laboratoire (y compris Lighthouse de Google) se concentraient souvent sur des conseils visant à optimiser les formats et la taille des images pour réduire les temps de téléchargement et améliorer les performances. Bien que correct, l'analyse a montré que ce conseil avait peut-être été trop mis en avant. Le problème le plus important était les retards avant que le navigateur ne trouve l'image et ne commence à la télécharger.
Bien que l'analyse des données de laboratoire puisse être utile, la façon dont le Web est utilisé dans la vie réelle peut souvent différer. Il est donc essentiel de pouvoir voir ces sous-parties pour les données sur le terrain. Un article publié l'année dernière a confirmé que de nombreuses idées reçues sur l'optimisation du LCP étaient fausses.
Sous-composants de l'image LCP
Avec cette version, les propriétaires de sites peuvent vérifier les sous-parties de la LCP des images sur leurs propres sites, au niveau de l'origine ou de l'URL.
Les sous-parties ne sont disponibles que pour les images et n'incluent pas les images du premier frame vidéo (qui sont un peu plus complexes, car nous ne pouvons pas mesurer la durée de téléchargement complète). Les sous-parties de texte ne sont pas non plus incluses, car elles sont moins utiles et fausseraient les chiffres de LCP des images. Pour les sites qui comportent principalement des LCP textuelles, les métriques TTFB et FCP globales sont utiles. Notez toutefois qu'elles concernent l'ensemble des LCP et non uniquement les LCP textuelles. Enfin, les sous-parties d'image ne sont collectées que lors du chargement complet de la page, contrairement à la métrique LCP elle-même, qui est également collectée lors des navigations avant/arrière et des pages prérendues.
Ces données ont été ajoutées à l'API CrUX et à l'API CrUX History à partir de février 2025 (remarque: pas à BigQuery). Au lancement, l'API CrUX History contient deux semaines de données. Elle en contiendra 25 semaines au fil du temps. Les API rendent les données disponibles sous la forme du 75e centile de chaque sous-partie, exprimé en millisecondes.
Par exemple, pour obtenir les sous-parties d'image LCP pour https://web.dev/ pour les pages vues PHONE, vous pouvez utiliser la commande curl suivante (en remplaçant API_KEY par votre propre clé):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": [
"largest_contentful_paint_image_time_to_first_byte",
"largest_contentful_paint_image_resource_load_delay",
"largest_contentful_paint_image_resource_load_duration",
"largest_contentful_paint_image_element_render_delay"]}'
Vous obtiendrez un résultat semblable à celui-ci:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_image_element_render_delay": {
"percentiles": {
"p75": 2088
}
},
"largest_contentful_paint_image_resource_load_delay": {
"percentiles": {
"p75": 828
}
},
"largest_contentful_paint_image_resource_load_duration": {
"percentiles": {
"p75": 417
}
},
"largest_contentful_paint_image_time_to_first_byte": {
"percentiles": {
"p75": 2385
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Nous avons mis à jour l'outil de visualisation CrUX pour inclure ces données. Nous nous attendons à ce que d'autres outils tiers qui utilisent les API CrUX exposent également ces données précieuses:
Dans cet exemple, nous pouvons voir que pour un site multimédia populaire, la durée de chargement des ressources est le composant le plus petit. Les réelles possibilités d'amélioration de ce site se situent au niveau du TTFB et du délai de chargement des ressources, avec une opportunité plus faible au niveau du délai d'affichage des éléments.
Des valeurs élevées dans chaque sous-partie indiquent différents problèmes:
- Un temps de latence du premier octet (TTFB) élevé indique généralement des problèmes de serveur, de réseau ou de redirection, comme expliqué dans Optimiser le TTFB.
- Un délai de chargement des ressources élevé indique que l'image LCP est découverte tardivement par le navigateur (par exemple, une image LCP injectée par JavaScript côté client qui met du temps à s'exécuter).
- Si la durée de chargement des ressources est élevée, vous devez envisager de réduire la taille de téléchargement des images.
- Un délai de rendu des éléments élevé se produit lorsque l'image est disponible (par exemple, via un
<link rel=preload>, mais n'est pas utilisée pendant une longue période. Cela est souvent dû au fait que JavaScript côté client est requis pour afficher l'image.
Nous espérons que la mise à disposition de ces données dans CrUX au niveau de l'origine et de l'URL (sous réserve des critères d'éligibilité habituels) aidera les sites à optimiser plus facilement leur métrique LCP.
Types de ressources LCP
Étant donné que les sous-parties sont plus adaptées à l'affichage des LCP des images, CrUX ne limite ces données qu'aux pages contenant des images. Il est donc important de savoir combien de vos LCP sont des LCP d'image par rapport aux LCP de texte (par exemple, les titres <h1> et les paragraphes longs).
En plus des sous-composants d'image LCP, les API CrUX incluent désormais également une répartition des ressources montrant la répartition des chargements de pages LCP entre le texte et les images.
Par exemple, pour obtenir les types de ressources LCP pour https://web.dev/ pour les pages vues PHONE, vous pouvez utiliser la commande curl suivante (en remplaçant à nouveau API_KEY par votre propre clé):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["largest_contentful_paint_resource_type"]}'
Vous obtiendrez alors un résultat semblable à celui-ci:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_resource_type": {
"fractions": {
"image": 0.0155,
"text": 0.9845
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
La visualisation CrUX a également été mise à jour pour afficher ces données:
Par exemple, pour la page d'accueil de web.dev, nous pouvons voir que 98,5% des LCP étaient en fait des LCP textuelles.Les sous-parties de l'image du LCP sont donc moins utiles pour cette page. Dans ce cas, nous pouvons utiliser les métriques TTFB et FCP d'origine pour obtenir une répartition diagnostique potentiellement plus pertinente.
Les types de ressources LCP sont un autre outil de diagnostic utile pour comprendre et améliorer le LCP, en particulier pour savoir dans quelle mesure les sous-composants de l'image LCP sont utiles.
Informations de diagnostic sur le RTT
Nous avons également étendu la métrique RTT, introduite pour la première fois en août 2024.
Tri des intervalles RTT
Nous avons ajouté des tri-bins aux API CrUX, qui affichent trois regroupements de densités de RTT:
| Latence réseau | Démarrer | Terminer |
|---|---|---|
| Faible | 0 milliseconde | < 75 millisecondes |
| Moyenne | 75 millisecondes | < 275 millisecondes |
| Élevée | 275 millisecondes | ∞ |
Ces intervalles sont plus informatifs que les anciennes catégories de latence EC2, qui incluaient tout ce qui était inférieur à 270 millisecondes dans la catégorie 4g. Depuis le lancement de ces outils, les avancées technologiques dans le domaine des réseaux ont fait que la plupart des sites ont vu la majeure partie de leur trafic se retrouver dans cette catégorie, ce qui rend cette catégorisation moins utile.
C'est pourquoi nous vous suggérons d'utiliser les libellés faible, moyenne et élevée plutôt que les libellés habituels bon, à améliorer et mauvais. Ce ne sont pas des métriques qu'un propriétaire de site peut améliorer directement lui-même. Il s'agit donc de métriques de diagnostic pour comprendre les autres métriques et pourquoi elles peuvent être différentes de ce que vous attendez. Ils peuvent également aider à expliquer pourquoi d'autres métriques évoluent au fil du temps, même si le site ne change pas, s'ils montrent une évolution de la base d'utilisateurs.
Ces bacs sont disponibles dans les API CrUX, par exemple pour web.dev pour les pages vues PHONE (en remplaçant à nouveau API_KEY par votre propre clé):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["round_trip_time"]}'
Le résultat est semblable à celui-ci:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"round_trip_time": {
"histogram": [
{
"start": 0,
"end": 75,
"density": 0.1524
},
{
"start": 75,
"end": 275,
"density": 0.6641
},
{
"start": 275,
"density": 0.1835
}
],
"percentiles": {
"p75": 230
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Les intervalles sont affichés dans CrUX Vis lorsque les distributions sont sélectionnées:
RTT dans BigQuery
En plus d'étendre la métrique RTT dans les API CrUX pour inclure les tri-bins, nous avons également rendu les données disponibles dans l'ensemble de données BigQuery mensuel, y compris un histogramme complet dans des buckets de 25 millisecondes dans les tables brutes, ainsi que des tri-bins et des valeurs p75 dans les tables materialisées.
Cela permet d'obtenir une meilleure compréhension de la distribution des données au-delà des tri-bins disponibles dans les API CrUX. Il nous permet également de recréer la répartition de l'ECT qui a été supprimée de CrUX ce mois-ci (nous y reviendrons plus tard). La seule modification est un seuil de 275 millisecondes pour 4g au lieu du seuil précédent de 270 millisecondes. Les répartitions de l'ECT (désormais issues des données RTT) restent disponibles dans les tables materialisées BigQuery CRUX afin que des outils tels que le tableau de bord CRUX puissent continuer à les afficher.
L'ensemble de données BigQuery inclut également des données par pays (défini par la norme ISO 3166-1). Cela permet une analyse plus approfondie, qui peut être utile pour expliquer pourquoi les métriques de performances sont moins bonnes pour certains utilisateurs. Par exemple, nous pouvons examiner les données des utilisateurs de Google Phone en examinant les données de https://www.google.com:
SELECT
`chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
least(500, p75_rtt) AS capped_p75_rtt,
p75_rtt
FROM
`chrome-ux-report.materialized.country_summary`
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202501 AND
device = 'phone'
ORDER BY
p75_rtt DESC,
country_code
Nous visualisons ensuite les données sur une carte géographique:
https://www.google.com(données sources avec graphique interactif).
Nous pouvons constater que, alors que la plupart des pays du monde (en particulier le "monde occidental") enregistrent de très bons temps de latence, l'Afrique subsaharienne, certaines régions du Moyen-Orient et de l'Asie sont moins bien loties. En réalité, le graphique est limité à 500 millisecondes de RTT, car l'utilisation de l'ensemble des données fausse les couleurs, en particulier avec l'Érythrée, qui affiche un 75e percentile de 3 850 millisecondes.
Cela peut également s'avérer utile lorsque les tendances de trafic changent. Par exemple, une plus grande proportion d'utilisateurs provenant de pays où les temps de latence RTT sont plus élevés peut expliquer des statistiques Core Web Vitals moins bonnes, même si le site n'a pas changé.
Bien que les sites ne puissent pas améliorer directement le temps de latence aller-retour, en mettant ces données à la disposition des visiteurs, vous pouvez mieux comprendre les utilisateurs de votre site dans le monde entier. Il offre également de nombreuses possibilités d'analyse à l'avenir, et nous espérons que les chercheurs trouveront des insights intéressants dans cet ensemble de données.
Suppression de la dimension "ECT"
La dernière modification apportée dans la version de février 2025 est la suppression de la dimension "Type de connexion effectif" de BigQuery (nous avions déjà supprimé le RTT des API depuis septembre 2024 lorsque nous avons lancé la métrique RTT en remplacement).
Comme indiqué précédemment dans cet article, la métrique RTT offre une vue plus détaillée des détails de connexion des visiteurs d'un site. Vous pouvez même recréer les buckets ECT à partir de ces histogrammes. (Techniquement, l'ECT doit être une combinaison du RTT et de la vitesse de liaison descendante, mais Chrome n'a jamais utilisé que le RTT.)
Une différence importante est que l'ECT était une dimension CRUX, ce qui signifie que les autres métriques pouvaient être segmentées par ECT. Le RTT est une métrique CRUX et non une dimension. Il n'est donc pas possible d'afficher le LCP par RTT, par exemple, mais uniquement les RTT par rapport aux autres dimensions (type d'appareil et pays).
Cela peut sembler plus restrictif, mais le passage de la dimension à la métrique permet de débloquer davantage de données dans CrUX. En effet, CrUX impose certains seuils minimaux avant que nous puissions afficher des données. Nous avons déjà rendu les dimensions facultatives en 2022, ce qui signifie que nous avons supprimé l'ECT ou l'appareil lorsque cela était nécessaire pour générer des rapports à un niveau supérieur. Toutefois, les métriques qui n'étaient pas disponibles pour la plupart des chargements de pages (Interaction to Next Paint (INP), différents types de navigation et désormais les sous-parties d'image du LCP) n'étaient souvent pas disponibles pour les origines dans BigQuery.
En réduisant le nombre de dimensions, les données sont moins segmentées, ce qui augmente le nombre d'origines répondant à ces exigences minimales. En janvier, nous avons enregistré des INP pour 68,1% des origines, alors que pour l'ensemble de données de décembre, nous n'en avons enregistré que 64,5 %. Le mécanisme s'applique également aux types de navigation, aux sous-parties du LCP et aux types de ressources de cette version. Ils bénéficient tous de la suppression de la dimension ECT. Dans les API CrUX, la couverture étendue est entrée en vigueur début février.
Les colonnes ECT resteront dans BigQuery pour assurer la cohérence avec les ensembles de données précédents. Les données ECT des vues matérialisées resteront disponibles, mais en fonction des informations sur le RTT (avec une différence de 5 millisecondes pour 3g et 4g, comme indiqué précédemment), en plus du nouveau RTT p75 et des tri-bins.
Conclusion
L'ajout de métriques à l'ensemble de données public CrUX permet aux propriétaires de sites et aux chercheurs de disposer de beaucoup plus d'informations pour diagnostiquer et résoudre les problèmes de performances.
En tant qu'ensemble de données public, CrUX présente certaines limites quant au niveau de détail que nous pouvons afficher. Par exemple, les sélecteurs d'éléments individuels ne pourront jamais être affichés dans CrUX. Les propriétaires de sites qui souhaitent obtenir ce niveau de détail sont vivement invités à implémenter une solution RUM, qui ne sera pas aussi limitée.
Toutefois, les données agrégées de niveau supérieur, comme celles détaillées dans cet article, peuvent vous aider à comprendre pourquoi vous rencontrez un problème. Nous espérons que ces données supplémentaires vous seront utiles. N'hésitez pas à nous contacter sur le groupe de discussion si vous avez des commentaires ou des questions.