Combinez les outils Google pour auditer, améliorer et surveiller efficacement votre site Web.
Date de publication : 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 collecte ou non de vos propres données de champ. La fin de ce parcours 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 des utilisateurs 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 permettant de mettre en évidence les problèmes de performances potentiels et les bonnes pratiques. Les outils de laboratoire sont exécutés dans des conditions prédéfinies et peuvent ne pas refléter les mesures réelles des Core Web Vitals 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 simulé pour ordinateur ou mobile. Bien que ces simulations de conditions de réseau et d'appareil plus lentes soient utiles pour diagnostiquer les problèmes de performances, elles ne représentent qu'une partie de la grande variété de conditions de réseau et de capacités des appareils. Elles ne reflètent donc pas nécessairement l'expérience des utilisateurs sur vos sites.
Les outils de laboratoire tels que Lighthouse effectuent généralement un "chargement à froid" d'une page Web, comme s'il s'agissait d'un tout nouveau visiteur. Il s'agit souvent du chargement le plus lent, mais dans la réalité, les visiteurs peuvent avoir mis en cache certains éléments s'ils ont déjà visité le site ou lorsqu'ils le parcourent. Les nouveaux visiteurs et les outils peuvent également voir le site différemment, avec des bannières de cookies ou d'autres contenus qui leur sont présentés.
En résumé, même si les outils de laboratoire peuvent indiquer des problèmes de performances potentiels et vous aider à déboguer et à itérer, ils ne représentent pas nécessairement l'expérience réelle de la plupart des visiteurs de votre site Web. Utilisez les données de terrain pour mesurer les performances réelles et des outils de laboratoire comme Lighthouse pour diagnostiquer comment les améliorer. Consultez également la section Quand utiliser Lighthouse.
Google mesure les Core Web Vitals à l'aide du rapport sur l'expérience utilisateur de Chrome. Il s'agit d'un ensemble de données publiques collectées auprès d'utilisateurs réels de Chrome. Il s'agit de la base de nombreux outils Google et tiers qui génèrent des rapports sur les métriques Core Web Vitals d'un site.
Toutefois, CrUX a ses limites. Il peut souvent vous indiquer quand un problème survient, mais il ne dispose généralement pas de suffisamment de données pour vous expliquer pourquoi.
Collectez vos propres données de terrain si possible
Le meilleur ensemble de données pour améliorer les performances d'un site Web sur le terrain est celui que vous créez. Cela commence par la collecte de données de terrain auprès des visiteurs de votre site Web. La procédure à suivre dépend de la taille de votre organisation et de votre choix d'utiliser une solution tierce payante ou de créer votre propre solution.
Les solutions payantes mesurent presque toujours les métriques 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 organisations disposant de ressources importantes, il peut s'agir de la méthode privilégiée.
Cependant, vous ne faites peut-être pas partie d'une grande organisation, ou d'une organisation ayant les moyens de s'offrir une solution tierce. Dans ce cas, la bibliothèque web-vitals de Google vous aidera à collecter tous les signaux Web essentiels. Toutefois, vous serez responsable de la façon dont ces données sont rapporté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 de terrain, vous pouvez utiliser la bibliothèque web-vitals pour envoyer les signaux Web essentiels 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 ou non vos propres données de terrain, plusieurs outils Google peuvent vous être utiles pour analyser les Core Web Vitals. Avant d'établir un workflow, une présentation générale de chaque outil peut vous aider à comprendre lesquels sont les plus adaptés à vos besoins.
Rapport sur l'expérience utilisateur de Chrome (CrUX)
Comme mentionné précédemment, CrUX est un ensemble de données public de données de terrain recueillies 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 qui enregistrent un trafic suffisant.
CrUX est disponible sous la forme d'un ensemble de données BigQuery mensuel au niveau de l'origine, ou d'une 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 différents outils CrUX, à la fois pour un accès programmatique et pour des outils visuels destinés aux utilisateurs.
Quand utiliser CrUX ?
Même si vous collectez vos propres données réelles, CrUX reste utile. Bien que le rapport CrUX ne représente qu'un sous-ensemble d'utilisateurs de Chrome, il est utile de comparer les données réelles de votre site Web pour voir comment elles s'alignent sur les 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 réelle pour votre site Web, CrUX est particulièrement utile pour fournir une vue d'ensemble, à condition que votre site Web soit représenté dans son ensemble de données.
Vous pouvez utiliser CrUX directement ou via un autre outil (y compris ceux mentionnés ci-dessous). L'utilisation directe de l'ensemble de données CrUX, via BigQuery ou l'API, est utile pour exposer 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.
Quand ne pas utiliser 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 compatibles avec les métriques Web Vitals.
Les sites Web qui ne reçoivent pas suffisamment de trafic ne sont pas représentés dans l'ensemble de données CrUX. Si c'est votre cas, vous devrez collecter vos propres données de terrain pour comprendre les performances de votre site Web, car vous ne pourrez pas utiliser CrUX. Sinon, vous devrez vous fier aux données de laboratoire, mais avec les limites qu'elles peuvent ne pas être représentatives, comme décrit précédemment.
Étant donné que les données fournies par le rapport d'expérience utilisateur Chrome sont une moyenne mobile sur les 28 derniers jours, ce n'est pas un outil idéal pendant le développement, car il faudra un certain temps pour que les améliorations soient reflétées dans l'ensemble de données du rapport d'expérience utilisateur Chrome.
Enfin, en tant qu'ensemble de données public, CrUX est limité quant à la quantité d'informations qu'il peut mettre à disposition et à la manière dont ces données peuvent être interrogées. En capturant vos propres données RUM, vous pouvez recueillir 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 bénéficient-ils de métriques Core Web Vitals meilleures ou moins bonnes que les utilisateurs déconnectés ? Les utilisateurs dont le LCP est lent ont-ils un élément LCP particulier ? Quelles interactions entraînent 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 des données de laboratoire issues de Lighthouse pour une page donnée. Pour en savoir plus, consultez les sections correspondantes.
Quand utiliser PSI ?
PSI est idéal pour évaluer les performances CrUX au niveau de la page ou de l'origine, pour les utilisateurs d'appareils mobiles et d'ordinateurs. C'est un bon choix pour obtenir un premier aperçu des 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 ceux de vos concurrents.
PSI fournit également des données Lighthouse, qui offrent des recommandations utiles pour améliorer vos Core Web Vitals, si les métriques correspondent. Si ce n'est pas le cas, les recommandations de Lighthouse peuvent être moins pertinentes.
Comme Lighthouse est exécuté depuis le serveur, il peut former une référence plus cohérente que s'il était exécuté depuis les outils de développement.
Quand ne pas utiliser PSI ?
PSI n'est disponible que pour les URL publiques. Il ne peut pas être utilisé sur les sites de développement qui ne sont pas accessibles au public.
Les données CrUX ne sont disponibles que lorsque les sites répondent à certains critères d'éligibilité, y compris des 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 de laboratoire Lighthouse dans ces cas-là.
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, cela limite également l'utilité de la corrélation entre les données réelles au niveau de l'origine et les diagnostics de laboratoire au niveau de la page. Les données de champ au niveau de l'origine restent très utiles pour résumer les performances du site, et les audits Lighthouse peuvent vous aider, mais vous devez faire preuve d'une prudence accrue 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 laboratoire Lighthouse, les recommandations de Lighthouse peuvent être d'une utilité limitée. Cela peut se produire en particulier pour les problèmes de CLS après chargement et pour les métriques Core Web Vitals d'interactivité (FID et INP), pour lesquelles les audits en laboratoire sont moins utiles.
Search Console
La Search Console mesure le trafic issu du Réseau de Recherche et les performances de votre site, y compris les Core Web Vitals. Il n'est disponible que pour les propriétaires de sites qui ont confirmé qu'ils en sont propriétaires.
La Search Console offre une fonctionnalité intéressante : elle regroupe les pages similaires (par exemple, celles qui utilisent le même modèle) dans une seule évaluation de groupe. La Search Console inclut également un rapport Core Web Vitals basé sur les données réelles du rapport CrUX.
Quand utiliser la Search Console ?
La Search Console est idéale pour les développeurs et les non-développeurs, car elle permet d'évaluer les performances de recherche et des pages d'une manière que les autres outils Google ne proposent pas. 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 de performances sur des catégories entières de pages.
Quand ne pas utiliser la Search Console
La Search Console peut ne pas convenir aux projets qui utilisent différents outils tiers regroupant les pages par similarité, ou si un site Web n'est pas représenté dans l'ensemble de données CrUX.
Le regroupement de pages peut également prêter à confusion lorsque les exemples de pages d'un groupe présentent des caractéristiques différentes de celles du reste du groupe. Par exemple, si le groupe échoue globalement à certains Core Web Vitals, mais que les exemples de pages semblent tous réussir ces mêmes Core Web Vitals. Cela peut se produire lorsqu'un groupe contient des pages de longue traîne ou rarement visité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 influencer 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 parcours utilisateur Lighthouse permettent également aux développeurs de créer des scripts de flux d'interaction pour tester les performances au-delà du chargement de page.
Lighthouse-CI est un outil associé qui exécute Lighthouse lors de la compilation et du déploiement du projet pour faciliter les tests de régression des performances. Il présente un rapport Lighthouse ainsi que des demandes d'extraction, et suit les métriques de performances au fil du temps.
Quand utiliser Lighthouse ?
Lighthouse est idéal pour identifier les opportunités d'amélioration des performances lors du développement dans des environnements locaux et de préproduction. Lighthouse CI est également utile lors des phases de compilation et de déploiement dans 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.
Quand ne pas utiliser Lighthouse
Lighthouse (ou Lighthouse CI) ne remplace pas les données de 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 affiche ne correspondent pas toujours aux performances constatées par vos utilisateurs.
Bien que Lighthouse puisse être utilisé pour diagnostiquer les sites de production via des outils tels que PageSpeed Insights, il est idéalement utilisé dans les environnements de développement et d'intégration continue pour résoudre les problèmes de performances avant qu'ils n'atteignent la production.
Les audits fournis par Lighthouse sont également disponibles via les "insights" du panneau "Performances" des outils pour les développeurs Chrome, 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 intégrés au 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 réelles depuis CrUX. Il est utile pour obtenir une vue "en direct" des performances lorsque vous interagissez avec la page pour tenter de détecter des problèmes de performances, en particulier pour les problèmes de post-chargement que vous pourriez rencontrer avec les métriques CLS et INP.
Ensuite, le panneau "Performances" permet aux développeurs de capturer un profil (ou une trace) de l'ensemble de l'activité de la page pendant son chargement ou une période enregistrée. Cette vue offre un aperçu détaillé de tout ce qu'elle observe dans des dimensions telles que l'activité du réseau, l'affichage, le rendu et les scripts, ainsi que 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 permet de comprendre rapidement les caractéristiques de performances actuelles de la page, et de repérer les problèmes potentiels lorsque l'utilisateur interagit 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 est identifiée et reproductible, le panneau "Performances" peut fournir une multitude de 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.
Quand ne pas utiliser le panneau "Performances"
Le panneau "Performances" est un outil pour les développeurs qui fournit principalement des données de laboratoire, avec un certain contexte de données réelles issues de CrUX. Il ne remplace pas les données de terrain.
La vue de trace contient de nombreuses informations de débogage, mais elle peut donc être difficile à comprendre pour les développeurs débutants ou les personnes n'ayant pas de rôle de développeur. Toutefois, la vue des métriques en direct qui s'ouvre dans le panneau résout ce problème en fournissant une interface plus facile à utiliser pour les personnes qui n'ont pas besoin de tous les détails.
Un workflow en trois étapes pour vous assurer que les Core Web Vitals de votre site Web restent satisfaisants
Lorsque vous cherchez à 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 procéder comme suit :
- Évaluez l'état de votre site Web et identifiez les problèmes.
- Déboguez et optimisez.
- Surveillez les performances à l'aide d'outils d'intégration continue pour détecter et éviter les régressions.
Étape 1 : Évaluez l'état de votre site Web et identifiez les opportunités d'amélioration
Il est préférable de commencer par les données de terrain pour évaluer l'état d'un site Web.
- Utilisez PageSpeed Insights pour afficher les métriques globales de l'expérience Core Web Vitals sur l'origine, ainsi que des informations spécifiques sur une URL individuelle.
- La Search Console peut être utile pour identifier les pages à améliorer lorsque sa fonctionnalité de regroupement de pages fonctionne bien pour votre site.
- Si vous disposez de données RUM, il s'agit souvent de la meilleure option pour identifier des pages ou des segments de trafic spécifiques présentant des problèmes.
Que vous analysiez les données de terrain que vous collectez vous-même ou les données CrUX, cette première étape est essentielle. Si vous ne collectez pas de données de 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 d'un site avec PageSpeed Insights
PageSpeed Insights affiche les données CrUX couvrant les 28 derniers jours de données d'expérience utilisateur au 75e centile. 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 les performances, utilisez-la. Pour avoir une vue d'ensemble d'un site lorsque vous commencez à l'optimiser, vous pouvez commencer par la page d'accueil, car il s'agit généralement de l'une des pages les plus populaires de nombreux sites.
Pour commencer, concentrez-vous sur la section Expérience de vos utilisateurs réels de PSI. Vous verrez jusqu'à quatre vues des données : mobile et ordinateur pour l'URL saisie et l'origine complète. Comparez-les et voyez ce qui les différencie. Les performances sur mobile sont généralement inférieures à celles sur ordinateur, car les appareils mobiles sont plus limités en ressources et fonctionnent dans des conditions réseau potentiellement moins stables. Si les données de l'URL et de l'origine sont très différentes, essayez de comprendre pourquoi : les pages d'accueil sont souvent les premières pages visitées (c'est-à-dire une page de destination). Elles peuvent donc être plus lentes que l'origine, car les utilisateurs subissent de plein fouet un cache de navigateur non initialisé. Les pages suivantes se chargeront probablement plus rapidement, car tous les éléments 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 métriques Core Web Vitals sont-elles défaillantes, et dans quelle mesure ? Cela vous indiquera où concentrer vos efforts.
Comprenez 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 rendra très difficile le respect du seuil recommandé de 2,5 secondes pour un bon LCP. Cela suggère un backend lent (problèmes de serveur ou absence de CDN), des réseaux plus lents ou des redirections retardant les premiers octets HTML. Pour en savoir plus, consultez le guide sur l'optimisation du TTFB. Le FCP prend une seconde de plus, ce qui peut également indiquer des réseaux plus lents. Dans cet exemple, le LCP n'est pas très éloigné du FCP, ce qui suggère que la ressource LCP est bien optimisée une fois la page chargée. CrUX affiche désormais davantage d'informations de diagnostic dans les types de ressources et les sous-parties, ce qui vous aide également à diagnostiquer les problèmes de LCP.
Pour le CLS, examinez les scores CLS CrUX et CLS Lighthouse pour déterminer s'il s'agit d'un problème de CLS au chargement (que Lighthouse détectera et pour lequel il vous conseillera) ou d'un problème de CLS après le chargement (que Lighthouse ne détectera pas). Pour en savoir plus, consultez le guide "Optimiser le CLS".
Pour la réactivité, examinez les scores INP. Examinez les audits TBT dans Lighthouse pour voir si un grand nombre de traitements JavaScript ont lieu 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 peu performantes dans la Search Console
PSI est utile lorsque vous souhaitez tester une URL spécifique ou l'ensemble du site, mais 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 présente une vue d'ensemble des performances de votre site Web, mais vous pouvez également examiner en détail les pages spécifiques qui nécessitent une attention particulière. La Search Console vous permet également d'effectuer les actions suivantes :
- 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 critère de regroupement (état, métrique et groupes de pages Web similaires, comme les pages produit détaillées d'un site d'e-commerce).
- Obtenez des rapports détaillés qui regroupent les URL dans chaque catégorie de qualité de l'expérience utilisateur, pour mobile et ordinateur.
Une fois que vous avez identifié des pages spécifiques à examiner, vous pouvez utiliser PSI comme expliqué précédemment pour mieux comprendre les problèmes de ces pages.
Étape 2 : Déboguer et optimiser
À l'étape 1, vous devriez avoir identifié les pages dont les performances doivent être améliorées, 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 de comprendre la cause principale et d'identifier le problème.
- Consultez les audits Lighthouse pour obtenir des conseils généraux sur la page.
- Utilisez la vue des métriques en direct 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 pour vous. Il est également possible d'exécuter Lighthouse à partir des Outils pour les développeurs Chrome, ce qui est utile pour valider les corrections localement. Toutefois, le panneau "Performances" (abordé ci-après) est un outil plus complet pour identifier et corriger les problèmes de performances localement.
Il est essentiel 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 l'expérience utilisateur que pendant le chargement de page. Comme il s'agit d'un outil de laboratoire, il exclut également l'INP au profit du TBT.
Lorsque les métriques Lighthouse suggèrent un problème similaire à celui que vous essayez de résoudre, la multitude d'informations contenues dans ses audits peut vous aider à identifier les problèmes et à suggérer des solutions.
Vous pouvez filtrer les audits pour n'afficher que les métriques Core Web Vitals qui vous intéressent, afin de vous concentrer sur la résolution des problèmes liés à une métrique spécifique :
Pour l'INP, utilisez les audits TBT pour identifier les problèmes susceptibles d'affecter ces métriques. Sachez toutefois que sans interactions, Lighthouse est limité dans ses capacités de diagnostic.
Analysez 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 direct des outils pour les développeurs Chrome dans le panneau "Performances" affiche les métriques Core Web Vitals en temps réel pendant le chargement de la page et pendant la navigation sur une page. Il peut donc 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 à partir de CrUX. Pour obtenir encore plus d'informations, vous pouvez explorer les données à l'aide d'une trace.
Affiner les résultats avec le panneau "Performances"
Le panneau "Performances" des outils pour les développeurs Chrome vous permet d'enregistrer un profil (ou une trace) de l'ensemble du comportement d'une 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 sont également affichées, ainsi que les valeurs réelles de ces métriques, lorsqu'elles sont disponibles.
La piste Décalages de mise en page met en évidence les décalages de mise en page. Cliquez dessus pour obtenir plus de détails sur les éléments qui ont été décalés afin de déboguer le CLS.
Les timings clés, tels que le LCP, sont affichés dans la section Timings (Temps) disponible 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 de flammes.
Ces fonctionnalités, ainsi que les informations d'autres parties du panneau "Performances", peuvent vous aider à déterminer si les correctifs ont un effet sur les métriques Core Web Vitals d'une page.
Déboguer les métriques Core Web Vitals sur le terrain
Les outils de laboratoire ne peuvent pas toujours identifier la cause de tous les problèmes liés aux Core Web Vitals qui affectent vos utilisateurs. C'est l'une des raisons pour lesquelles il est si important de collecter vos propres données de terrain, car elles prennent en compte des facteurs que les données de laboratoire ne peuvent pas prendre en compte.
Pour en savoir plus, consultez Déboguer les performances sur le terrain.
Étape 3 : Surveillez les modifications
Une fois que vous avez résolu les problèmes, vous devez vous assurer que les corrections ont l'effet escompté et que de nouveaux problèmes ne perturbent pas vos Core Web Vitals. Pour cela, il faut surveiller les problèmes de performances dans le workflow du développeur afin d'éviter qu'ils ne soient mis en production, et surveiller régulièrement les données de terrain pour s'assurer que c'est bien le cas.
Surveiller les demandes 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 que des régressions de performances ne s'introduisent dans le code. Il peut vérifier les temps de performance (qui peuvent varier) ou simplement les audits de performances, en tant qu'outil de linting pour éviter les mauvaises pratiques dans le code.
Afficher les tendances de l'état d'un site Web avec des données réelles
Bien que vous deviez vous efforcer de détecter et de résoudre tous les problèmes de performances avant qu'ils ne soient mis en production, il est essentiel de surveiller vos données de terrain à l'aide de la surveillance des utilisateurs réels pour détecter ceux qui passent entre les mailles du filet. Il existe de nombreux produits RUM commerciaux qui peuvent vous aider. La bibliothèque JavaScript web-vitals peut automatiser la collecte des données de champ d'un site Web et, si vous le souhaitez, utiliser ces données pour alimenter des tableaux de bord et des systèmes d'alerte personnalisés.
Pour les sites sans solution RUM, vous pouvez utiliser les différents outils CrUX pour effectuer une analyse de base des tendances des données de terrain.
Conclusion
Pour offrir aux utilisateurs une expérience rapide et agréable, vous devez adopter une approche axée sur les performances et un workflow qui garantit la progression. Avec les bons outils et processus d'audit, de débogage et de surveillance, vous pouvez créer des expériences utilisateur exceptionnelles et respecter les seuils définis pour de bons Core Web Vitals.