Comment optimiser Google Core Web Vitals avec des données utilisateur réelles

Image d'en-tête

Les Core Web Vitals de Google ont été un signal de classement depuis 2021, lorsque Google a introduit trois métriques pour mesurer la qualité de l'expérience utilisateur sur un site Web.

Les données réelles de surveillance des utilisateurs peuvent vous indiquer vos performances sur Core Web Vitals et ce que vous pouvez faire pour les améliorer. Cela s'applique particulièrement au nouveau Interaction avec la peinture suivante (INP) qui deviendra l'un des Core Web Vitals le 12 mars 2024.

Quelle est la différence entre les données de laboratoire et les données d’utilisateurs réels ?

Lors de la mesure des performances Web, nous pouvons examiner soit des données de laboratoire (également appelées données synthétiques), soit des données d'utilisateurs réels (également appelées données de terrain).

Les données de laboratoire sont collectées dans un environnement de test contrôlé. Il vous indique la vitesse de chargement de votre site Web à partir d'un emplacement de test donné, avec une connexion réseau donnée et un appareil de test spécifique. Cela le rend très cohérent entre les tests, et les rapports peuvent être très détaillés car les outils de test ont un contrôle total sur l'environnement de test. Phare est un exemple d'outil de test synthétique.

En revanche, les données réelles des utilisateurs sont collectées auprès des visiteurs lorsqu’ils accèdent à votre site Web. Chaque visiteur vivra une expérience différente selon l'endroit où il se trouve, la vitesse de sa connexion Internet et le type d'appareil qu'il utilise. Ainsi, lorsque nous examinons une mesure, nous devons examiner une moyenne statistique telle que 75e centile qui est couramment utilisé lors de la déclaration des données Core Web Vitals.

Vous verrez souvent que le les valeurs métriques ne correspondent pas entre les données de laboratoire et de terrain. En fin de compte, ce qui vous importe, c'est l'expérience utilisateur réelle, mais les données synthétiques peuvent fournir beaucoup plus de profondeur pour vous aider à comprendre et à améliorer la vitesse de vos pages.

Données Core Web Vitals d'utilisateurs réels et données de laboratoire Lighthouse dans PageSpeed ​​InsightsDonnées Core Web Vitals d'utilisateurs réels et données de laboratoire Lighthouse dans PageSpeed ​​Insights

Pourquoi les données réelles des utilisateurs sont-elles importantes pour améliorer vos Core Web Vitals ?

Exécution d'un test de vitesse de page en laboratoire est idéal pour analyser la vitesse de chargement initiale de votre site Web. Mais d'autres mesures dépendent de la manière dont les utilisateurs interagissent avec la page une fois celle-ci ouverte.

Cela s’applique particulièrement à la nouvelle métrique Interaction to Next Paint. Votre score INP dépend des éléments de page avec lesquels les utilisateurs interagissent et du moment où ces interactions se produisent au cours du processus de chargement de la page.

Alors que Changement de disposition cumulatif (CLS) peut se produire lors du chargement initial de la page, cela se produit souvent en réponse à une interaction de l'utilisateur ou lors du défilement d'une page. Si vous collectez uniquement des données dans un environnement synthétique, vous manquerez ces changements de présentation qui se produiront plus tard au cours de la visite d'un site Web.

Comment collecter les données Core Web Vitals des utilisateurs réels

Une véritable solution de surveillance des utilisateurs (RUM) comme DébogageOurs peut vous aider à collecter des données Core Web Vitals sur vos visiteurs. Vous configurez un extrait d'analyse sur votre site Web et ces données sont ensuite agrégées et affichées dans un tableau de bord Core Web Vitals.

Vous pouvez voir si l'une de vos pages les plus visitées est lente et comment l'expérience utilisateur varie en fonction de l'emplacement de vos visiteurs.

Tableau de bord Core Web Vitals de l'utilisateur réel DebugBearTableau de bord Core Web Vitals de l'utilisateur réel DebugBear

Comment décider quelles pages optimiser

Pour commencer, vérifiez si l’une de vos pages les plus populaires échoue à l’évaluation Core Web Vitals. Vous pouvez aussi utiliser Console de recherche Google pour identifier les pages avec une mauvaise expérience utilisateur sur votre site Web.

Une fois que vous avez identifié une page, vous pouvez approfondir l'analyse de vos données RUM et trouver des moyens de l'améliorer.

Améliorez la plus grande peinture de contenu avec des données utilisateur réelles

Les données réelles de surveillance des utilisateurs pour une page peuvent vous aider à comprendre l’impact qu’auraient diverses optimisations de performances.

Potentiel d'optimisation du LCP L'analyse montre ce que vous devez optimiser pour améliorer le LCP :

  • Time to First Byte (TTFB) : ce composant examine la rapidité avec laquelle le serveur répond à la requête HTML.
  • First Contentful Paint (FCP) : cela vous indique s'il y a ressources bloquant le rendu qui empêchent le contenu de la page d'apparaître.
  • LCP : cela montre combien de temps il faut pour que l'élément LCP apparaisse après le premier rendu de la page
DebugBear Le plus grand tableau de bord Contentful Paint pour une page spécifique d'un site WebDebugBear Le plus grand tableau de bord Contentful Paint pour une page spécifique d'un site Web

Découvrez quels éléments de page sont responsables de la plus grande peinture de contenu

Différents visiteurs consultant la même page verront un contenu différent lors du premier chargement de la page. L'élément de contenu le plus important varie entre les utilisateurs de bureau et mobiles et entre les utilisateurs connectés et déconnectés.

L'analyse des éléments de page qui finissent le plus souvent en tant qu'élément LCP vous aide à comprendre quelles optimisations aideront le plus grand nombre d'utilisateurs. Il vous permet également de voir si certains éléments du LCP entraînent des scores LCP particulièrement médiocres.

Répartition des éléments LCPRépartition des éléments LCP

Réduire les ressources bloquant le rendu

Si le composant First Contentful Paint contribue beaucoup de temps à votre score LCP, vous devez voir ce qui peut être fait pour que votre site Web s'affiche plus tôt.

Des outils comme DebugBear et d'autres vous indiquent quelle est la dernière demande de blocage de rendu pour chaque page vue. Si vous chargez cette ressource plus rapidement, le First Contentful Paint se produira plus tôt.

Liste des ressources bloquant le rendu sur un site WebListe des ressources bloquant le rendu sur un site Web

Optimiser les images LCP

Le Élément LCP la répartition nous indique quel type d'élément est responsable du LCP pour différents utilisateurs. Ici, l'analyse nous montre qu'une image d'arrière-plan est responsable de la plus grande peinture de contenu dans 96 % des cas. Cela signifie que nous devrions nous concentrer sur le chargement de cette image plus rapidement.

Analyse d'image LCP basée sur des données utilisateur réelles dans DebugBearAnalyse d'image LCP basée sur des données utilisateur réelles dans DebugBear

Le Sous-parties du LCP La répartition nous aide à optimiser les performances de chargement des images en examinant les composants qui suivent le TTFB :

  • Délai de chargement : à quelle vitesse après le chargement du document HTML le navigateur commence-t-il à charger l'image ?
  • Temps de chargement : combien de temps faut-il pour télécharger l'image ?
  • Délai de rendu : le navigateur affiche-t-il l'image immédiatement après son chargement ou y a-t-il un délai ?

Dans ce cas, nous pouvons voir que nous devons optimiser le temps de chargement, par exemple en réduisant la taille du téléchargement avec plus de temps de chargement. format d'image moderne. L'image termine également souvent son chargement avant le premier Contentful Paint, ce qui signifie qu'elle reste masquée pendant quelques centaines de millisecondes.

En regardant une page vue spécifique et en étudiant le demander une cascade la visualisation peut vous aider à mieux comprendre dans quel ordre les différentes ressources sont chargées et combien de temps prend une requête donnée.

Par exemple, nous pouvons voir ici quelle requête charge l'image LCP, quand cette requête démarre et combien de temps après la requête le LCP est enregistré. Ici, nous pouvons voir que le LCP (indiqué par la ligne rouge à droite) se produit juste après le chargement de l'image LCP, ce qui signifie qu'il n'y a pas de délai de rendu pour cette vue de page.

Cascade de requête montrant l'impact du chargement des ressources sur le rendu du site WebCascade de requête montrant l'impact du chargement des ressources sur le rendu du site Web

Améliorez l'interaction avec Next Paint avec des données utilisateur réelles

Le score INP de votre site Web dépend grandement des éléments de page avec lesquels les utilisateurs interagissent. Cliquer quelque part sur un paragraphe ne déclenche généralement l’exécution d’aucun code, et ces interactions seront rapides. Une bascule de menu ou un bouton qui génère un nouveau composant d'interface utilisateur et l'affiche prendra beaucoup plus de temps.

Avec des données utilisateur réelles, vous pouvez voir avec quels éléments les utilisateurs interagissent le plus souvent et lesquelles de ces interactions sont lentes.

Analyse INP montrant différents sélecteurs d'éléments de pageAnalyse INP montrant différents sélecteurs d'éléments de page

Identifier le code qui provoque des interactions lentes

Analyse INP montrant différents fichiers JavaScript ralentissant le traitement des événementsAnalyse INP montrant différents fichiers JavaScript ralentissant le traitement des événements

Ceci est possible grâce au nouveau API d'images d'animation longues qui sera inclus dans Chrome à partir de la mi-mars 2023. Cette fonctionnalité du navigateur signale le code qui provoque des retards de rendu sur une page.

Quand tu regardes un expérience utilisateur individuelle vous pouvez voir avec quel élément l'utilisateur a interagi et quel code s'est exécuté à ce stade, provoquant un mauvais INP.

Analyse INP pour une visite de page spécifiqueAnalyse INP pour une visite de page spécifique

Une fois que vous avez identifié un fichier de script spécifique, vous pouvez vérifier si ce script est nécessaire et s'il existe des moyens de le rendre plus rapide.

Quand les interactions lentes se produisent-elles sur la page ?

Un autre facteur qui a un impact sur INP est l'étape de chargement de la page au moment où l'interaction se produit. Au cours des toutes premières étapes de chargement, l'INP est souvent élevé, car de nombreuses parties de la page sont initialisées, ce qui nécessite beaucoup de traitement CPU.

Si tel est le cas, vous pouvez envisager différentes manières d'optimiser la logique de chargement initial de la page et déterminer si davantage de place peut être laissée pour gérer les interactions des utilisateurs pendant cette période.

La largeur des barres dans ce graphique indique combien d'utilisateurs rencontrent un INP médiocre à chaque étape de chargement. Ainsi, même si la première étape de « chargement » entraîne une mauvaise INP, peu d’utilisateurs sont réellement concernés ici.

Analyse INP par étape de chargement de la pageAnalyse INP par étape de chargement de la page

Améliorez le changement de mise en page cumulatif avec des données utilisateur réelles

Étant donné que les changements de disposition se produisent souvent à la suite d’une interaction utilisateur, les données utilisateur réelles facilitent l’identification des changements que vous ne pouvez pas détecter lors d’un test en laboratoire.

Vous pouvez voir quels éléments changent et quelle interaction de l'utilisateur a conduit au changement de mise en page. Par exemple, une image qui apparaît en réponse à un clic sur un bouton peut faire descendre un autre contenu de la page une fois le téléchargement de l'image terminé.

Élément de changement de mise en page collecté sur la base de données utilisateur réellesÉlément de changement de mise en page collecté sur la base de données utilisateur réelles

Quelle est la différence entre la surveillance des utilisateurs réels (RUM) et les données Google CrUX ?

Vous pouvez utiliser celui de Google Rapport sur l'expérience utilisateur Chrome (CrUX) pour obtenir des données utilisateur réelles Core Web Vitals pour votre site Web, sans avoir à effectuer de travaux de configuration.

Cependant, la surveillance réelle des utilisateurs répond à plusieurs limitations des données CrUX :

  • Les régressions et les améliorations apparaissent instantanément avec les données RUM, tandis que les données CrUX sont agrégées sur une période de 28 jours.
  • Les données CrUX ne sont disponibles que pour les pages à fort trafic, tandis que les données RUM sont disponibles pour toute page de votre site Web consultée par un visiteur.
  • Les données CrUX fournissent uniquement des valeurs métriques et aucune donnée de débogage. Vous pouvez voir où votre site Web rencontre des difficultés sur les Core Web Vitals, mais vous ne saurez pas quoi faire.

La surveillance réelle des utilisateurs vous montre comment les utilisateurs vivent votre site Web et quel impact cela a sur leur comportement.

Histogramme de la plus grande peinture de contenu avec superposition du taux de rebondHistogramme de la plus grande peinture de contenu avec superposition du taux de rebond

Démarrez avec la surveillance des utilisateurs réels Core Web Vitals

Vous cherchez à améliorer vos statistiques Web, à obtenir un meilleur classement dans Google et à offrir une meilleure expérience utilisateur ? DebugBear propose un Essai gratuit de 14 jours – inscrivez-vous maintenant pour obtenir les données dont vous avez besoin pour optimiser votre site Web !

Newsletter

Rejoignez notre newsletter pour des astuces chaque semaine