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 façon dont vous collectez vos propres données sur le terrain. La fin de ce processus 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. Ce sont des métriques centré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 ralentissements du réseau et des appareils soient utiles pour diagnostiquer les problèmes de performances, elles ne représentent qu'un échantillon de la grande variété des conditions du réseau et des capacités des appareils. Elles peuvent donc ne pas refléter ce que les utilisateurs de vos sites rencontrent.
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.
Collecter vos propres données de 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. La première étape consiste à collecter des données réelles 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 mesureront 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.
Cependant, 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 encore 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 flux de travail, une vue d'ensemble de chaque outil peut vous aider à comprendre quels outils peuvent, ou non, être les mieux pour vous.
Rapport d'expérience utilisateur Chrome
Comme indiqué précédemment, le rapport d'expérience utilisateur Chrome 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 BigQuery sont également disponibles dans le tableau de bord CRUX, qui permet aux sites d'examiner les tendances historiques de leur site.
Quand utiliser CrUX ?
Même si vous collectez vos propres données de terrain, l'expérience utilisateur Chrome reste utile. Bien que l'expérience utilisateur Chrome (CrUX) représente un sous-ensemble d'utilisateurs de Chrome, il est utile de comparer les données réelles de votre site Web pour déterminer dans quelle mesure elle s'aligne 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 présenté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 la manière dont ces données peuvent être interrogées. La capture de vos propres données RUM vous permet de recueillir plus de détails (par exemple, l'élément LCP) et de 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 spécifique ? Quelles interactions génèrent des valeurs FID et INP élevées ?
PageSpeed Insights (PSI)
PSI est un outil qui permet de générer des rapports sur les données réelles de CrUX et celles issues de l'atelier Lighthouse pour une page donnée. Pour en savoir plus, consultez les sections correspondantes.
Quand utiliser PSI ?
L'outil PSI est idéal pour évaluer les performances d'expérience utilisateur Chrome (CrUX) au niveau de la page ou de l'origine, tant pour les utilisateurs sur mobile que sur ordinateur. Il est adapté 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.
L'outil 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.
É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. Le fait de disposer des données du champ au niveau de l'origine reste une information très utile pour résumer les performances du site. Les audits Lighthouse peuvent être utiles, mais il convient d'être particulièrement vigilant 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 le trafic de recherche et les performances de votre site, y compris les métriques 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 aperçu inédit 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 pendant la compilation et le déploiement du projet 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 la solution idéale pour identifier des opportunités d'amélioration des performances pendant le développement 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 n'atteignent la production.
Panneau "Performances" dans Chrome DevTools
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 informations détaillées sur tout ce qu'elle observe à travers des dimensions telles que l'activité de réseau, d'affichage, de peinture et de script, ainsi que les Core Web Vitals d'une page.
Quand utiliser le panneau "Performances" ?
Le panneau "Performances" est destiné aux développeurs pour obtenir des informations détaillées 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 INP. Une fois qu'une interaction qui ne répond pas correctement 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 rendu.
Dans quels cas ne pas utiliser le panneau "Performances"
Le panneau "Performances" est un outil pour les développeurs qui fournit principalement des données de laboratoire, mais avec un peu de contexte provenant de CrUX. Il ne remplace pas les données sur le terrain.
La vue de trace contient de nombreuses informations de débogage, mais pour cette raison, elle peut être difficile à comprendre pour les développeurs novices ou ceux qui n'ont pas de rôle de développeur. Cependant, la vue des métriques en direct avec laquelle le panneau s'ouvre permet de résoudre ce problème en proposant une interface plus facile à utiliser pour ceux qui n'ont pas besoin d'informations complètes.
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 adopter l'une des approches suivantes:
- Évaluer l'état du site Web et identifier 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 réelles afin d'évaluer l'état de votre 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 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 d'expérience utilisateur Chrome (CrUX) couvrant les 28 derniers jours de données sur l'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 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, qui est généralement l'une des pages les plus populaires sur de nombreux sites.
Commencez par vous concentrer sur la section Expérience des utilisateurs 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 voyez ce qui les différencie. Les mobiles sont généralement moins performants que les ordinateurs de bureau, car il s'agit d'un appareil dont les ressources sont plus limitées et fonctionnant dans des conditions de 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 totalité de la 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 sont-elles pas conformes ? 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 pour cette métrique. Dans cet exemple, nous avons un TTFB de 1,8 seconde, ce qui va rendre très difficile d'atteindre le seuil recommandé de 2,5 secondes pour obtenir un bon 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.
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 spécifiques. 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
À l'étape 1, vous devez 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 davantage d'informations afin de comprendre l'origine du problème et d'identifier le problème.
- Effectuer un audit Lighthouse pour obtenir des conseils au niveau de 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 :
Identifier des opportunités avec Lighthouse
PageSpeed Insights exécute Lighthouse à votre place, mais pour le développement local, vous pouvez également exécuter Lighthouse à partir des outils pour les développeurs Chrome. Cela vous permet de valider les correctifs en local.
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). Prêt à l'emploi, Lighthouse évalue uniquement l'expérience utilisateur pendant le chargement de la page. Puisqu'il s'agit d'un outil de laboratoire, il exclut également INP au profit de la TAT.
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 :
Bien que cette vue offre de nombreuses informations utiles pour vous aider à identifier les problèmes de performances, vous pouvez afficher plus de détails à 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 temps clés (par exemple, le LCP) s'affichent dans la piste "Timings". Cliquez dessus pour en savoir plus.
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 tâches longues (qui peuvent entraîner des problèmes INP) sont également mises en évidence par des triangles rouges.
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 la section Résoudre les problèmes de 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. Cela nécessite de surveiller les problèmes de performances dans le cadre du workflow du développeur afin d'éviter que ces problèmes ne soient publiés en production, et de surveiller régulièrement les données de terrain pour s'assurer que c'est le cas.
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 pour empêcher les régressions de performances de saisir du 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 l'état du site 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 commerciaux de RUM sont disponibles pour vous aider. 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 sans solution RUM, vous pouvez utiliser le tableau de bord CrUX pour analyser les tendances de base des données de terrain. Il indique les éléments suivants pour les sites dans CrUX :
- Vue d'ensemble du site, qui segmente les Core Web Vitals en fonction des types d'appareils (ordinateurs et appareils mobiles).
- Historique des tendances par type de métrique : répartition des métriques au fil du temps pour chaque version mensuelle disponible des données de rapport d'expérience utilisateur Chrome.
- Données démographiques des utilisateurs : cette section illustre la distribution des pages vues pour l'ensemble d'une origine pour les utilisateurs de chaque catégorie démographique, y compris les types d'appareil et de connexion effective.
Le tableau de bord CrUX est basé sur l'ensemble de données BigQuery CrUX, qui est mis à jour une fois par mois. Cela peut être un bon rappel pour vérifier régulièrement vos métriques Core Web Vitals.
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.