Combinez les outils Google pour auditer, améliorer et surveiller efficacement votre site Web.
Publié le 28 mai 2020
Les Core Web Vitals sont un ensemble de métriques qui évaluent l'expérience utilisateur en fonction de critères tels que les performances de chargement, la réactivité aux entrées utilisateur et la stabilité de la mise en page.
Ce guide présente un workflow permettant d'améliorer les métriques Core Web Vitals de votre site Web. Toutefois, le point de départ de ce workflow dépend de la manière dont vous collectez vos propres données sur le terrain. La durée de cette étape peut dépendre des outils Google que vous trouverez utiles pour diagnostiquer et résoudre les problèmes d'expérience utilisateur.
Il est préférable de mesurer les métriques Core Web Vitals sur le terrain
Les Core Web Vitals sont spécifiquement conçus pour mesurer l'expérience utilisateur sur votre site Web. Il s'agit de métriques axées sur l'utilisateur. Les outils de laboratoire tels que Lighthouse sont des outils de diagnostic qui permettent de mettre en évidence les problèmes de performances potentiels et les bonnes pratiques. Les outils basés sur des tests en laboratoire sont exécutés dans certaines conditions prédéfinies et ne reflètent pas nécessairement les mesures Core Web Vitals réelles que vos utilisateurs rencontrent.
Par exemple, Lighthouse est un outil de laboratoire qui exécute des tests avec une limitation simulée dans un environnement de bureau ou mobile simulé. Bien que ces simulations de conditions réseau et d'appareil plus lentes soient utiles pour diagnostiquer les problèmes de performances, elles ne représentent qu'un seul segment de la grande variété de conditions réseau et de fonctionnalités des appareils. Elles ne reflètent donc pas nécessairement ce que les utilisateurs de vos sites vivent.
Les outils basés sur un laboratoire, comme Lighthouse, effectuent généralement un "chargement à froid" d'une page Web en tant que visiteur totalement nouveau. Il s'agit souvent de la charge la plus lente, mais dans la pratique, certains éléments peuvent être mis en cache si les visiteurs ont déjà accédé au site ou s'ils le parcourent. Les nouveaux visiteurs et les outils peuvent également avoir une expérience différente du site, avec des bannières de cookies ou d'autres contenus qui s'affichent.
En résumé, bien que les outils basés en laboratoire puissent vous indiquer les problèmes de performances potentiels et vous aider à déboguer et à itérer, ils ne représentent peut-être pas le nombre de visiteurs qui utilisent réellement votre site Web. Utilisez des données sur le terrain pour mesurer les performances réelles et des outils en laboratoire, comme Lighthouse, pour diagnostiquer les problèmes et les améliorer. Consultez également la section Quand utiliser Lighthouse.
Google mesure les métriques Core Web Vitals via le rapport d'expérience utilisateur Chrome (ou "rapport CrUX"). Il s'agit d'un ensemble de données publiques collectées auprès d'utilisateurs Chrome réels. Il constitue l'épine dorsale de nombreux outils Google et tiers qui signalent les Core Web Vitals d'un site.
CrUX présente cependant certaines limites. Il peut souvent vous indiquer quand un problème survient, mais les données sont souvent insuffisantes pour vous expliquer pourquoi.
Collectez vos propres données sur le terrain, si possible
Le meilleur ensemble de données pour améliorer les performances d'un site Web dans le domaine est celui que vous créez. Pour ce faire, vous devez commencer par collecter des données sur le terrain auprès des visiteurs de votre site Web. La méthode à suivre dépend de la taille de votre organisation et de votre choix entre payer pour une solution tierce ou créer votre propre solution.
Les solutions payantes mesurent presque certainement les Core Web Vitals (et d'autres métriques de performances) et fournissent généralement divers outils pour analyser les données obtenues. Dans les grandes entreprises disposant de ressources importantes, il peut s'agir de la méthode privilégiée.
Toutefois, vous ne faites peut-être pas partie d'une grande entreprise, ou n'avez pas les moyens de vous offrir une solution tierce. Dans ce cas, la bibliothèque web-vitals
de Google vous aidera à collecter tous les Web Vitals. Toutefois, vous serez responsable de la manière dont ces données sont enregistrées, stockées et analysées.
Si vous utilisez déjà Google Analytics, mais que vous n'avez pas commencé à collecter vos propres données sur le terrain, vous pouvez peut-être utiliser la bibliothèque web-vitals
pour envoyer les signaux Web collectés sur le terrain à Google Analytics et utiliser les exportations BigQuery de GA4 pour créer des rapports sur les données.
Comprendre les outils de Google
Que vous collectiez vos propres données sur le terrain ou non, plusieurs outils Google peuvent vous aider à analyser les Core Web Vitals. Avant d'établir un workflow, un aperçu général de chaque outil peut vous aider à déterminer ceux qui peuvent ou non vous convenir.
Rapport d'expérience utilisateur Chrome (CrUX)
Comme indiqué précédemment, le rapport CRUX est un ensemble de données publiques collectées auprès d'un segment d'utilisateurs réels de Google Chrome sur des millions de sites Web. Il inclut les métriques Core Web Vitals et d'autres métriques pour les sites Web générant suffisamment de trafic.
CrUX est disponible en tant qu'ensemble de données BigQuery mensuel au niveau de l'origine ou en tant qu'API quotidienne au niveau de l'URL ou de l'origine, à condition qu'une URL ou une origine dispose de suffisamment d'échantillons dans l'ensemble de données CrUX. Les données CrUX sont disponibles via divers outils CrUX pour un accès programmatique et des outils visuels à utiliser par les utilisateurs.
Quand utiliser CrUX ?
Même si vous collectez vos propres données sur le terrain, CrUX reste utile. Bien que le CrUX ne représente qu'un sous-ensemble d'utilisateurs Chrome, il est utile de comparer les données sur le terrain de votre site Web pour voir comment elles s'alignent sur ses données CrUX. Chacune présente des avantages et des inconvénients, ce qui peut entraîner des différences. Si vous ne collectez aucune donnée sur le terrain pour votre site Web, CrUX est particulièrement utile pour obtenir une vue d'ensemble, à condition que votre site Web soit représenté dans l'ensemble de données.
Vous pouvez utiliser CrUX directement ou via un autre outil (y compris ceux mentionnés ci-dessous). Utiliser directement l'ensemble de données CrUX, que ce soit avec BigQuery ou l'API, est utile pour afficher des données qui ne sont pas affichées dans d'autres outils. Par exemple, les données au niveau du pays ne sont souvent pas disponibles dans d'autres outils, ou pour afficher les métriques supplémentaires dans CrUX, qui ne sont souvent pas affichées dans d'autres outils.
Cas d'utilisation non valides de CrUX
CrUX ne représente que les utilisateurs de Chrome, et même dans ce cas, seulement un sous-ensemble d'utilisateurs de Chrome. Une solution RUM complète peut inclure davantage d'expériences dans Chrome et d'autres navigateurs où les métriques Web Vitals sont prises en charge.
Les sites Web qui ne reçoivent pas suffisamment de trafic ne sont pas représentés dans l'ensemble de données CrUX. Dans ce cas, vous devrez collecter vos propres données sur le terrain pour comprendre les performances de votre site Web sur le terrain, car CrUX ne sera pas une option. Vous pouvez également vous appuyer sur des données de laboratoire, mais avec les limites qu'elles peuvent présenter, comme décrit précédemment.
Étant donné que les données fournies par CrUX sont une moyenne glissante sur les 28 derniers jours, cet outil n'est pas idéal pendant le développement, car il faudra un certain temps pour que les améliorations soient reflétées dans le jeu de données CrUX.
Enfin, en tant qu'ensemble de données public, CrUX est limité en termes de quantité d'informations qu'il peut mettre à disposition et de manière dont ces données peuvent être interrogées. En capturant vos propres données RUM, vous pouvez collecter plus de détails (par exemple, l'élément LCP) et segmenter davantage les données pour identifier les problèmes. Les utilisateurs connectés obtiennent-ils de meilleures ou de moins bonnes métriques Core Web Vitals que les utilisateurs non connectés ? Les utilisateurs dont le LCP est lent présentent-ils un élément LCP particulier ? Quelles interactions génèrent des valeurs FID et INP élevées ?
PageSpeed Insights (PSI)
PSI est un outil qui fournit des données réelles issues de CrUX et du laboratoire Lighthouse pour une page donnée. Pour en savoir plus, consultez ces sections.
Quand utiliser PSI ?
PSI est idéal pour évaluer les performances CrUX au niveau de la page ou de l'origine, pour les utilisateurs mobiles et les utilisateurs de bureau. Il est utile pour obtenir un aperçu initial des métriques Core Web Vitals d'une page ou d'un site. Il vous permet également d'afficher les données Core Web Vitals d'autres sites, comme vos concurrents.
PSI fournit également des données Lighthouse, qui fournissent des recommandations utiles pour améliorer vos métriques Core Web Vitals (si les métriques sont alignées). Si ce n'est pas le cas, les recommandations de Lighthouse peuvent être moins pertinentes.
Étant donné que Lighthouse est exécuté à partir du serveur, il peut constituer une référence plus cohérente que l'exécution de Lighthouse à partir de DevTools.
Cas d'utilisation non valides
La PSI n'est disponible que pour les URL publiques. Elle ne peut pas être utilisée sur les sites de développement qui ne sont pas accessibles au public.
Les données CrUX ne sont disponibles que si les sites remplissent certains critères d'éligibilité, y compris les seuils de popularité. PSI est moins utile lorsque les données CrUX ne sont pas disponibles pour une page ou une origine, car il ne peut afficher que les données du laboratoire Lighthouse dans ce cas.
De même, si vous ne disposez que de données CrUX au niveau de l'origine plutôt que de l'URL spécifique testée, la corrélation des données de champ au niveau de l'origine avec les diagnostics de laboratoire au niveau de la page est également limitée. Les données de champ au niveau de l'origine restent très utiles pour obtenir un résumé des performances du site. Les audits Lighthouse peuvent vous aider, mais vous devez faire preuve de prudence dans ce cas.
Enfin, lorsque des données au niveau de la page sont disponibles dans CrUX, mais qu'elles diffèrent des données de l'atelier Lighthouse, les recommandations de Lighthouse peuvent être d'une utilité limitée. Cela peut se produire en particulier pour les problèmes de CLS post-chargement et pour les Core Web Vitals d'interactivité (FID et INP), pour lesquels les audits en laboratoire sont moins utiles.
Search Console
La Search Console mesure les performances et le trafic de recherche de votre site, y compris les Core Web Vitals. Elle n'est disponible que pour les propriétaires de sites qui ont confirmé leur propriété.
La Search Console propose une fonctionnalité intéressante : elle regroupe les pages similaires (par exemple, celles qui utilisent le même modèle) dans une évaluation de groupe. La Search Console inclut également un rapport Core Web Vitals basé sur les données réelles de CrUX.
Quand utiliser la Search Console ?
La Search Console permet aux développeurs et aux autres personnes d'évaluer les performances de la recherche et des pages d'une manière différente des autres outils Google. La présentation des données CrUX et le regroupement des pages par similarité offrent un nouvel aperçu de l'impact des améliorations des performances sur l'ensemble des catégories de pages.
Cas d'utilisation non valides
La Search Console n'est peut-être pas adaptée aux projets qui utilisent différents outils tiers qui regroupent les pages par similarité, ou si un site Web n'est pas représenté dans l'ensemble de données CrUX.
Le regroupement des pages peut également être quelque peu déroutant lorsque les exemples de pages d'un groupe présentent des caractéristiques différentes du reste du groupe. Par exemple, si le groupe échoue pour certaines Core Web Vitals dans l'ensemble, mais que les exemples de pages semblent tous réussir les mêmes Core Web Vitals. Cela peut se produire lorsqu'un groupe contient une longue traîne ou des pages rarement consultées qui peuvent être plus lentes à charger, car elles sont moins susceptibles d'être mises en cache. Lorsque ces pages sont suffisamment nombreuses dans la longue traîne, elles peuvent avoir une incidence sur le taux de réussite global du groupe.
Phare
Lighthouse est un outil de laboratoire qui fournit des opportunités spécifiques pour améliorer les performances des pages. Les flux utilisateur Lighthouse permettent également aux développeurs de créer des scripts de flux d'interaction pour les tests de performances au-delà du chargement de la page.
Lighthouse-CI est un outil associé qui exécute Lighthouse lors des compilations et des déploiements de projets pour faciliter les tests de régression des performances. Il présente un rapport Lighthouse ainsi que des requêtes pull, et suit les métriques de performances au fil du temps.
Quand utiliser Lighthouse ?
Lighthouse est excellent pour identifier les opportunités d'amélioration des performances lors du développement, à la fois dans les environnements locaux et de préproduction. La CI Lighthouse est également utile dans les phases de compilation et de déploiement pour les environnements de préproduction et de production, où des tests de régression des performances sont nécessaires pour préserver une bonne expérience utilisateur.
Cas d'utilisation non valides de Lighthouse
Lighthouse (ou Lighthouse CI) ne remplace pas les données sur le terrain. Lighthouse est principalement un outil de diagnostic qui liste les problèmes potentiels et les bonnes pratiques à partir d'un chargement de page prédéfini. Les recommandations qu'il propose ne correspondent pas toujours aux performances enregistrées par vos utilisateurs.
Bien que Lighthouse puisse être utilisé pour diagnostiquer des sites de production à l'aide d'outils tels que PageSpeed Insights, il est idéal de l'utiliser dans des environnements de développement et d'intégration continue pour résoudre les problèmes de performances avant qu'ils ne soient mis en production.
Les audits fournis par Lighthouse sont également disponibles dans les "insights" du panneau "Performances" de Chrome DevTools, qui fournit une analyse plus approfondie des performances d'une page.
Panneau "Performances" dans les outils pour les développeurs Chrome
Les Outils pour les développeurs Chrome sont un ensemble d'outils de développement dans le navigateur, y compris le panneau "Performances". Le panneau "Performances" est un outil de laboratoire qui se compose de deux "modes":
Lorsque vous ouvrez le panneau "Performances" pour la première fois, un écran "Métriques en direct" affiche la métrique Core Web Vitals actuelle, avec la possibilité d'importer des données d'utilisation réelles à partir de CrUX. Il s'agit d'une vue "en direct" des performances lorsque vous interagissez avec la page pour tenter de détecter les problèmes de performances, en particulier les problèmes post-chargement que vous pourriez rencontrer avec les métriques CLS et INP.
Deuxièmement, le panneau "Performances" permet aux développeurs de capturer un profil (ou une trace) de toute l'activité de la page pendant le chargement de la page ou pendant une période enregistrée. Cette vue offre des insights détaillés sur tout ce qu'elle observe dans des dimensions telles que le réseau, le rendu, la peinture et l'activité de script, ainsi que sur les Core Web Vitals d'une page. Il inclut également des insights, semblables à ceux fournis par Lighthouse.
Quand utiliser le panneau "Performances" ?
Les développeurs doivent utiliser le panneau "Performances" pour obtenir des insights détaillés sur les performances d'une page spécifique.
La vue des métriques en direct vous permet de comprendre rapidement les caractéristiques de performances actuelles de la page, et de détecter les problèmes potentiels au fur et à mesure de l'interaction avec la page.
La vue de trace est particulièrement utile pour déboguer les problèmes de réactivité affectant l'INP. Une fois qu'une interaction qui répond mal a été identifiée et reproductible, le panneau "Performances" peut fournir de nombreuses données sur ce qui se passe dans le navigateur pour vous aider à comprendre le problème, du blocage du thread principal aux piles d'appels JavaScript en passant par le travail de rendu.
Cas d'utilisation non valides du panneau "Performances"
Le panneau "Performances" est un outil de développement qui fournit principalement des données de laboratoire, mais avec un contexte sur le terrain provenant de CrUX. Il ne remplace pas les données sur le terrain.
La vue de trace contient de nombreuses informations de débogage. Par conséquent, elle peut être difficile à comprendre pour les développeurs novices ou les personnes qui ne sont pas développeurs. Toutefois, la vue des métriques en direct avec laquelle le panneau s'ouvre résout ce problème en fournissant une interface plus facile à utiliser pour ceux qui n'ont pas besoin de tous les détails.
Workflow en trois étapes pour vous assurer que les Core Web Vitals de votre site Web restent en bon état
Lorsque vous travaillez à améliorer l'expérience utilisateur, il est préférable de considérer le processus comme un cycle continu. Pour améliorer les métriques Core Web Vitals et d'autres métriques de performances, vous pouvez suivre cette approche:
- Évaluez l'état de santé du site Web et identifiez les difficultés.
- Déboguer et optimiser
- Surveillez votre application à l'aide d'outils d'intégration continue pour détecter et éviter les régressions.

Étape 1: Évaluer l'état de santé du site Web et identifier les possibilités d'amélioration
Il est préférable de commencer par les données sur le terrain pour évaluer l'état du site Web.
- Utilisez PageSpeed Insights pour afficher les métriques globales sur l'expérience Core Web Vitals pour l'origine et des informations spécifiques sur une URL individuelle.
- La Search Console peut vous aider à identifier les pages qui doivent être améliorées lorsque sa fonctionnalité de regroupement de pages fonctionne bien pour votre site.
- Si vous disposez de données RUM, c'est souvent la meilleure option pour identifier les pages ou les segments de trafic présentant des problèmes.
Que vous analysiez des données sur le terrain que vous collectez vous-même ou des données CrUX, cette première étape est essentielle. Si vous ne collectez pas de données sur le terrain, les données CrUX peuvent suffire à vous guider, à condition que votre site Web soit représenté dans l'ensemble de données.
Analyser les performances de votre site avec PageSpeed Insights

PageSpeed Insights affiche les données CrUX des 28 derniers jours sur l'expérience utilisateur au 75e percentile. Cela signifie que si 75% des expériences utilisateur atteignent le seuil défini pour une métrique donnée, l'expérience est considérée comme "bonne".
Si vous avez une page spécifique en tête pour examiner ses performances, utilisez-la. Pour obtenir une vue d'ensemble d'un site lorsque vous commencez à l'optimiser, vous pouvez commencer par la page d'accueil, car elle est généralement l'une des pages les plus populaires de nombreux sites.
Commencez par vous concentrer sur la section Ce que vos utilisateurs réels vivent de l'outil PSI. Vous pouvez afficher jusqu'à quatre vues des données: mobile et ordinateur pour l'URL saisie et l'origine complète. Comparez-les et identifiez leurs différences. Les appareils mobiles sont généralement moins performants que les ordinateurs, car ils disposent de moins de ressources et fonctionnent dans des conditions réseau potentiellement moins stables. Si l'URL et les données d'origine sont très différentes, essayez de comprendre pourquoi: les pages d'accueil sont souvent les premières pages consultées (c'est-à-dire une page de destination). Elles peuvent donc être plus lentes que les pages d'origine, car les utilisateurs sont soumis à la pleine charge d'un cache de navigateur non amorcé. Les pages suivantes se chargeront probablement plus rapidement, car les composants partagés seront mis en cache, ce qui réduira les données agrégées au niveau de l'origine.
PSI affiche également les trois métriques Core Web Vitals (LCP, CLS et INP), ainsi que les métriques de diagnostic TTFB et FCP. Certaines des métriques Core Web Vitals ne respectent-elles pas les seuils, et dans quelle mesure ? Vous saurez ainsi où concentrer vos efforts.
Comprendre les relations entre ces chiffres, en particulier pour le LCP Si le LCP est lent, comme dans cet exemple, examinez le TTFB et le FCP, qui sont tous deux des jalons de cette métrique. Dans cet exemple, le TTFB est de 1,8 seconde, ce qui va rendre très difficile d'atteindre le seuil recommandé de 2,5 secondes pour une bonne LCP. Cela suggère que le backend est lent (problèmes de serveur ou absence de CDN), que les réseaux sont plus lents ou que les redirections retardent les premiers octets HTML. Pour en savoir plus, consultez le guide d'optimisation du TTFB. Le FCP prend encore une seconde en plus, ce qui peut également indiquer des réseaux plus lents. Dans cet exemple, le LCP n'est pas loin derrière le FCP, ce qui suggère que la ressource LCP est bien optimisée une fois la page elle-même chargée. CrUX affiche désormais plus d'informations de diagnostic dans les types de ressources et les sous-composants, ce qui vous aide également à diagnostiquer les problèmes de LCP.
Pour le CLS, examinez les scores CLS de CrUX et de Lighthouse pour déterminer s'il s'agit d'un problème de CLS de chargement (que Lighthouse détectera et sur lequel il vous conseillera) ou d'un problème de CLS post-chargement que Lighthouse ne détectera pas. Pour en savoir plus, consultez le guide d'optimisation du CLS.
Pour la réactivité, examinez les scores INP. Examinez les audits TBT dans Lighthouse pour voir si de nombreux traitements JavaScript sont effectués lors du chargement initial de la page, ce qui est susceptible d'avoir un impact sur l'INP. L'INP peut être une métrique difficile à améliorer. Pour en savoir plus, consultez le guide d'optimisation de l'INP.
Identifier les pages qui enregistrent de mauvaises performances dans la Search Console

Bien que l'outil PSI soit utile lorsque vous souhaitez tester une URL spécifique ou l'ensemble du site, la Search Console peut vous aider à cibler vos efforts sur des types de pages particuliers. Cela est particulièrement utile si de nombreuses pages partagent des thèmes ou des technologies communs et que la Search Console peut les identifier.
Le rapport Core Web Vitals de la Search Console donne un aperçu des performances de votre site Web, mais vous pouvez toujours examiner les pages spécifiques qui nécessitent votre attention. La Search Console vous permet également de:
- Identifiez les groupes de pages individuels qui doivent être améliorés et ceux qui offrent une bonne expérience utilisateur.
- Obtenez des données précises sur les performances par URL, regroupées par état, métrique et groupes de pages Web similaires (par exemple, les pages d'informations détaillées sur les produits d'un site Web d'e-commerce).
- Obtenez des rapports détaillés qui regroupent les URL dans chaque catégorie de qualité de l'expérience utilisateur, à la fois sur mobile et sur ordinateur.
Une fois que vous avez identifié des pages spécifiques à examiner, vous pouvez utiliser l'outil PSI, comme expliqué précédemment, pour mieux comprendre les problèmes liés à ces pages.
Étape 2: Déboguer et optimiser
Lors de l'étape 1, vous avez dû identifier les pages qui nécessitent une amélioration des performances, ainsi que les métriques Core Web Vitals que vous souhaitez améliorer. Vous pouvez utiliser les outils Google pour obtenir plus d'informations afin d'identifier la cause du problème.
- Consultez les audits Lighthouse pour obtenir des conseils généraux sur la page.
- Utilisez la vue des métriques en temps réel du panneau "Performances" pour analyser les Core Web Vitals en temps réel.
- Utilisez le traçage du panneau "Performances" pour déboguer les problèmes de performances et tester les modifications de code.
Pour en savoir plus, consultez les guides suivants:
Découvrir des opportunités avec Lighthouse
PageSpeed Insights exécute Lighthouse à votre place. Vous pouvez également exécuter Lighthouse à partir des outils pour les développeurs Chrome, ce qui est utile pour valider les corrections localement. Toutefois, le panneau "Performances" (qui sera abordé ci-dessous) est un outil plus complet pour identifier et résoudre les problèmes de performances localement.
Un point clé est de vérifier que l'audit Lighthouse reproduit les problèmes que vous essayez de résoudre (par exemple, un LCP lent ou des problèmes de CLS). Par défaut, Lighthouse n'évalue que l'expérience utilisateur lors du chargement de la page. Comme il s'agit d'un outil d'atelier, il exclut également l'INP au profit du TBT.
Lorsque les métriques Lighthouse suggèrent un problème semblable à celui que vous essayez de résoudre, la richesse des informations de ses audits peut vous aider à identifier les problèmes et à suggérer des solutions.
Vous pouvez filtrer les audits pour n'afficher que les Core Web Vitals qui vous intéressent afin de vous concentrer sur les corrections des problèmes liés à une métrique spécifique:

Pour l'INP, utilisez les audits TBT afin d'identifier les problèmes susceptibles d'affecter ces métriques. Toutefois, sachez que sans interactions, Lighthouse est limité dans ses diagnostics.
Analyser en temps réel avec l'écran des métriques en direct des outils pour les développeurs Chrome
L'écran des métriques en temps réel des outils pour les développeurs Chrome, dans le panneau "Performances", affiche les Core Web Vitals en temps réel lors du chargement de la page et pendant la navigation. Il peut ainsi capturer l'INP ainsi que les décalages de mise en page qui se produisent après le chargement. Vous pouvez également afficher des informations plus détaillées sur chaque métrique:

Cette vue fournit de nombreuses informations utiles pour identifier les problèmes de performances et peut même extraire des informations de champ de CrUX. Pour obtenir encore plus d'informations, vous pouvez effectuer une analyse détaillée à l'aide d'une trace.
Analyser les performances avec le panneau "Performances"
Le panneau "Performances" de Chrome DevTools vous permet d'enregistrer un profil (ou une trace) de l'ensemble du comportement de la page pendant une période donnée.

Les insights sur les performances sont disponibles dans le panneau latéral Insights. Les métriques Core Web Vitals ainsi que les valeurs des champs correspondants (le cas échéant) sont également affichées.
Le suivi Décalages de mise en page met en évidence les décalages de mise en page. Cliquez dessus pour en savoir plus sur les éléments qui ont été décalés pour le débogage du CLS.
Les temps clés (comme le LCP) sont affichés dans la section Timings (Temps) située en bas de la trace. Cliquez dessus pour en savoir plus.
Les tâches longues (qui peuvent entraîner des problèmes d'INP) sont également mises en évidence par des triangles rouges dans le graphique en forme de flamme.
Ces fonctionnalités, ainsi que les informations d'autres sections du panneau "Performances", peuvent vous aider à déterminer si les corrections ont un impact sur les Core Web Vitals d'une page.
Déboguer les Core Web Vitals sur le terrain
Les outils de laboratoire ne peuvent pas toujours identifier la cause de tous les problèmes Core Web Vitals affectant vos utilisateurs. C'est l'une des raisons pour lesquelles il est si important de collecter vos propres données sur le terrain, car elles prennent en compte des facteurs que les données de laboratoire ne peuvent pas.
Pour en savoir plus, consultez Déboguer les performances sur le terrain.
Étape 3: Surveillez les modifications

Une fois que vous avez corrigé les problèmes, vous devez vous assurer qu'ils ont l'effet souhaité et que de nouveaux problèmes ne perturbent pas vos métriques Core Web Vitals. Pour cela, vous devez surveiller les problèmes de performances dans le cadre du workflow du développeur afin d'éviter qu'ils ne soient publiés en production, et surveiller régulièrement les données sur le terrain pour vous en assurer.
UneSurveiller les requêtes de performances dans les environnements d'intégration continue (CI)
Lighthouse-CI vous permet d'exécuter automatiquement des audits Lighthouse sur les commits de code afin d'éviter les régressions de performances dans le code. Cela peut vérifier les délais de performances (qui sont sujets à des variations) ou uniquement les audits des performances, en tant qu'outil de linting pour éviter les mauvaises pratiques dans le code.
Afficher les tendances de santé des sites Web avec des données sur le terrain
Bien que vous deviez vous efforcer de détecter et de corriger tous les problèmes de performances avant qu'ils ne passent en production, la surveillance de vos données de champ à l'aide de RUM est essentielle pour détecter les problèmes qui passent entre les mailles. De nombreux produits RUM commerciaux peuvent vous aider à y parvenir. La bibliothèque JavaScript web-vitals
peut automatiser la collecte des données de champ d'un site Web et utiliser ces données pour alimenter des tableaux de bord et des systèmes d'alerte personnalisés.
Pour les sites qui ne disposent pas d'une solution RUM, vous pouvez utiliser les différents outils CrUX pour effectuer une analyse de tendances de base des données sur le terrain.
Conclusion
Pour garantir une expérience utilisateur rapide et agréable, vous devez adopter un état d'esprit axé sur les performances et un workflow pour assurer la progression. Avec les outils et les processus appropriés pour effectuer des audits, des débogages et des surveillances, vous pouvez créer des expériences utilisateur de qualité et respecter les seuils définis pour obtenir un bon score Core Web Vitals.