Analyse Core Web Vitals

Analyse des principaux indicateurs de performance et suivi des possibilités d'optimisation des pages.

Core Web Vitals

Screaming Frog SEO Spider, grâce à sa connexion avec l’API PageSpeed Insights, vous permet de mesurer facilement le Core Web Vitals (CWV) pour chaque page de votre site web.

Core Web Vitals est un ensemble d’indicateurs que Google a introduit à partir de mai 2021 pour mesurer des aspects clés de l’expérience de l’utilisateur lors du chargement d’une page web. Core Web Vitals est une révolution qui aide Google à évaluer les pages web et à les classer dans les résultats de recherche.

Pour l’instant, ils sont essentiellement au nombre de trois, mais je pense qu’à l’avenir, d’autres mesures seront introduites en plus de l’affinement de celles-ci afin de garantir une expérience de navigation plus satisfaisante.

LCP : Largest Contentful Paint (plus grande peinture de contenu)

La mesure Largest Contentful Paint (LCP) indique le temps de rendu de la plus grande image ou du plus grand bloc de texte visible dans la fenêtre de visualisation, par rapport au moment où la page a commencé à se charger. Comme paramètre d’évaluation, Google considère un temps maximum de 2,5 secondes pour garantir une expérience utilisateur bonne et satisfaisante.

Pour vous assurer que vous y parvenez pour la majorité de vos utilisateurs, un bon seuil à considérer est le 75e percentile de chargement des pages, segmenté entre les appareils mobiles et les ordinateurs de bureau.

Analisi Core web vitals LCP con screaming frog

FID : Délai de première entrée

Le délai de première entrée (DPI) d’une page mesure sa réactivité aux interactions de l’utilisateur. Par exemple, si un utilisateur clique sur un lien ou sélectionne un menu déroulant, le FID évalue la rapidité avec laquelle cette action est effectuée sur la page.

En général, les interactions avec l’utilisateur sont retardées lorsque le navigateur est occupé à d’autres tâches.

Par exemple, en analysant la chronologie de chargement ci-dessous, nous voyons des barres bleues identifiant le temps de chargement d’une ressource (telle qu’un fichier JavaScript) qui prend beaucoup de temps.

Si un utilisateur clique sur un élément de la page HTML pendant ce temps, l’interaction est retardée jusqu’à ce que le navigateur ait terminé le processus précédent.

En tant que paramètre d’évaluation, Google indique que le délai de première entrée doit être inférieur ou égal à 100 millisecondes pour offrir une bonne expérience à l’utilisateur. Pour vous assurer que vous atteignez cet objectif pour la majorité de vos utilisateurs, un bon seuil à mesurer est le 75e percentile de chargement des pages, segmenté entre les appareils mobiles et les ordinateurs de bureau.

CLS : Cumulative Layout Shift (décalage cumulatif de la mise en page)

Cumulative Layout Shift (CLS) est une mesure très importante axée sur l’expérience de l’utilisateur qui mesure la stabilité visuelle d’une mise en page lors du chargement d’une page HTML. Cet indice a été introduit pour limiter les changements inattendus et désagréables dus, par exemple, à des bannières publicitaires ou autres. Nous avons tous fait l’expérience frustrante de lire un site d’information et de voir le texte de l’article sauter vers le bas au fur et à mesure que la navigation se charge ; CLS mesure précisément cette instabilité de la navigation.

Vous pouvez voir ci-dessous ce phénomène pendant que la page est chargée par le navigateur. À chaque écran, du contenu est ajouté, ce qui fait monter et descendre les éléments précédents.

Pour offrir une bonne expérience à l’utilisateur, les sites doivent s’efforcer d’obtenir un score CLS inférieur ou égal à 0,1. Pour vous assurer que vous atteignez cet objectif pour la majorité de vos utilisateurs, un bon seuil à mesurer est le 75e percentile de chargement des pages, segmenté entre les appareils mobiles et les ordinateurs de bureau.

Les indicateurs Core Web Vitals sont des mesures basées sur les données Chrome User Experience Report (CrUX) des 28 derniers jours et sur les visites de l’utilisateur sur une page.

Chaque vitalité du web est évaluée selon trois catégories : bonne, à améliorer et médiocre.

Pour qu’une page soit validée par le Core Web Vital Assessment, elle doit être considérée comme “bonne” pour les trois indicateurs.

Google a fourni une illustration pratique des seuils pour chaque mesure.

Analyse des paramètres Core Web Vitals

Les indicateurs de performance des sites web sont enregistrés et stockés dans le rapport sur l’expérience utilisateur de Chrome et vous pouvez les consulter de deux manières.

Pour une seule URL, vous pouvez utiliser PageSpeed Insights (PSI), qui vous indique si la page a réussi ou échoué les contrôles.

Analisi PSI di un sito web

La deuxième solution consiste à consulter la Search Console dans la section “Core Vitals”, qui indique les performances des pages, les erreurs et les avertissements par rapport à ces paramètres.

Bien que ces deux contrôles soient efficaces, ils sont également extrêmement réducteurs car la première solution permet un contrôle unitaire des URL, tandis que la seconde, avec GSC, agrège plusieurs URL (modèles d’URL) et ne fournit pas de scores de qualité unitaires.

Analyse de Screaming Frog Web Vitals

Grâce à sa connexion à l’API PageSpeed Insights, Screaming Frog SEO Spider vous permet de collecter facilement des données sur la vitalité du Web et renvoie des données spécifiques aux URL basées sur des données CrUX et de laboratoire réelles. Pour le mettre en place, il suffit de suivre quelques étapes simples.

  • 1. Connexion à l’API PageSpeed.
  • 2. Paramètres des mesures à prendre en compte.

Une fois que vous êtes connecté à PSI, vous devez cliquer sur l’onglet ‘Metrics’ et choisir ceux que vous voulez introduire comme paramètres d’analyse. Pour les premiers balayages du Core Web Vitals, je vous recommande d’utiliser la sélection par défaut car elle inclut les données du rapport CrUX, les données de laboratoire de Google Lighthouse et les données d’opportunité des domaines à améliorer.

Metriche web vitals analizzate dal seo spider
  • 3. Effectuez l’analyse.

Une fois que vous avez terminé la configuration des paramètres de l’API, vous pouvez lancer le crawler et attendre que le site Web soit scanné et alimenté avec les données de Core Web Vitals.

  • 4. Analyse des données

Il vous suffit de cliquer sur l’onglet PageSpeed pour voir tous les détails du crawl et les URL qui ont passé le test, celles qui doivent être améliorées et celles qui présentent des erreurs graves.

L’exemple ci-dessus (avec les paramètres par défaut) présente les URL dans la première colonne et le “Core Web Vitals Assessment” dans la seconde. Le statut de l’ISP est marqué “Pass” ou “Fail” selon qu’il est considéré comme valide dans les trois Vitales Web.

Dans la capture d’écran, vous pouvez voir que l’URL du haut a un LCP de 1,99s (moins de 2,5s), un FID de 37ms (moins de 100ms) et un CLS de 0,06 (moins de 0,1), ce qui signifie qu’il a passé la validation du CWV.

Grâce à cette vue d’ensemble, vous êtes en mesure d’examiner immédiatement quelles pages ont échoué au test et sur quelles métriques CWV spécifiques il convient d’agir.

Il peut arriver que certains URL n’obtiennent pas de données CWV. Cette situation se produit lorsqu’il n’y a pas assez de données sur la vitesse dans CrUX, ou parce que la page n’a pas assez de visiteurs. Seules les pages les plus populaires disposent généralement de suffisamment de données pour le rapport Chrome UX.

  • 5. Segmentation des schémas d’erreur

Une fois que vous disposez des données, vous pouvez examiner les performances de chaque CWV à l’aide de différents filtres et isoler les problèmes à optimiser en faisant en sorte que chaque URL présente les mêmes problèmes critiques.

En mettant en évidence une URL dans la fenêtre supérieure et en cliquant sur l’onglet “PageSpeed Details” (fenêtre inférieure), vous trouverez toute une série de détails supplémentaires et la possibilité d’examiner les erreurs ou les avertissements trouvés.

Optimisation des mesures LCP

Commençons par définir les domaines qui peuvent affecter le LCP et les facteurs qui peuvent être optimisés pour améliorer l’indice métrique.

  • Dimensionnez correctement les images.
  • Différer les images hors écran.
  • Encoder efficacement les images.
  • Servir des images dans des formats de nouvelle génération.

Le point de départ est constitué par les images, qui sont l’un des éléments clés de la performance des pages html. Pour améliorer les mesures LCP, veillez à ce que chaque image soit de taille correcte et utilisez le “chargement paresseux” le cas échéant.

Il est conseillé d’utiliser de nouveaux formats d’image plus performants tels que WebP et d’améliorer l’encodage des fichiers d’image existants.

Un autre aspect très important concerne les temps de réponse des serveurs. C’est pourquoi je vous recommande de choisir un hébergement plus performant ou d’utiliser des CDN (Content Delivery Networks) afin de réduire les temps de réponse et d’améliorer le TTFB.

Parmi les optimisations possibles à envisager, portez une attention particulière à la gestion des ressources qui bloquent le rendu des pages. Comme vous le savez, lors de l’analyse du code HTML, toute référence à des feuilles de style ou à des feuilles de style CSS peut entraîner une pause dans l’analyseur, ce qui retarde l’application du code LCP.

Idéalement, vous devriez reporter tout CSS et JavaScript non critique afin d’accélérer le chargement de votre contenu principal et utiliser la fonction “preload” pour les ressources critiques. Un autre conseil est de minifier CSS et Javascript et de supprimer tous les fichiers inutiles du chargement de votre page. Pensez également à utiliser “preconnect” pour les ressources tierces (par exemple Google Analytics, Tag Manager, etc.).

  • Minifiez le CSS.
  • Minifiez JavaScript.
  • Supprimez les feuilles de style CSS inutilisées.
  • Supprimez le JavaScript inutilisé.
  • Activer la compression du texte.
  • Préconnexion aux origines requises.
  • Demande de clé de préchargement.
  • Utilisez des formats vidéo pour les contenus animés.

Optimiser le FID

Dans la plupart des cas, le FID est affecté par les longs délais d’exécution des scripts volumineux. La première mesure à prendre est de minifier et de supprimer les parties inutilisées des scripts (ou des scripts entiers) afin de réduire le temps d’exécution et de rendu de ces fichiers.

  • Minifiez JavaScript.
  • Supprimez le JavaScript inutilisé.
  • Réduisez le nombre de scripts tiers utilisés.

Vous trouverez la liste des ressources tierces dans votre document HTML sous l’onglet PageSpeed Details.

Une autre optimisation à prendre en compte concerne le travail du fil principal. Si un navigateur est occupé à effectuer le rendu du fil principal, l’utilisateur ne pourra pas interagir avec la page tant que cette opération ne sera pas terminée. Si vous réduisez le temps d’exécution du thread principal, les interactions avec les utilisateurs seront plus réactives et plus immédiates.

Les principales solutions concernent la réduction de l’exécution des scripts Javascript et la réduction du Main Thread.

  • Minimiser le travail sur le fil principal
  • Réduire le temps d’exécution de JavaScript

Considérez ensuite que chaque ressource nécessaire à une page prend du temps à être demandée, téléchargée et exécutée. En réduisant à la fois le nombre de requêtes nécessaires et la taille totale du téléchargement, vous contribuerez à améliorer les temps d’exécution des pages.

Les activités utiles sont la minification des feuilles de style CSS et Javascript, la suppression des feuilles de style/CSS et Javascript inutilisées et la compression du texte.

  • Diminution du nombre et de la taille des ressources.
  • Minifiez le CSS.
  • Minifiez JavaScript.
  • Supprimez les feuilles de style CSS inutilisées.
  • Supprimez le JavaScript inutilisé.
  • Activer la compression du texte.

Optimiser le CLS

Comme indiqué précédemment, la stabilité de la mise en page est l’élément principal qui permet au CLS de garantir une expérience pertinente à l’internaute. Cet aspect doit vous inciter à servir la page dans l’ordre approprié et avec un espacement défini pour chaque ressource afin de ne pas créer d’à-coups dans la navigation.

<> <> Pour obtenir des résultats satisfaisants, vous devez vous assurer que toutes les images, publicités, vidéos et iframes ont les attributs de hauteur et de largeur nécessaires pour que les pages soient chargées avec l’espacement approprié et que les autres contenus ne soient pas déplacés lorsqu’ils sont ajoutés. Une autre considération du point de vue de CLS est de donner la priorité au chargement des ressources du haut vers le bas afin de ne pas faire rebondir l’utilisateur vers le haut qui peut avoir atteint un certain niveau de profondeur de navigation.

Veillez à ce que les polices personnalisées ne provoquent pas l’effet FOIT/FOUT, car si les polices personnalisées sont appliquées tardivement dans le chargement d’une page, il se peut que le texte clignote pendant qu’il est remplacé (FOUT) ou qu’un texte invisible soit affiché jusqu’à ce que la police personnalisée soit rendue (FOIT). Pour contourner cette latence, je vous recommande d’utiliser le “préchargement” des ressources critiques.

Screaming Frog et Web Vitals

Si vos URL n’affichent aucune donnée CrUX et que le statut PSI indique “succès”, il est probable que l’URL ne reçoive pas suffisamment de visites d’utilisateurs réels pour générer des données de vitesse suffisantes pour le rapport CrUX. Si vous vous trouvez dans cette situation après le crawl avec Screaming Frog, vous pouvez utiliser une page avec une mise en page similaire avec des données CrUX pour l’analyse, ou utiliser des données de laboratoire simulées (présentes par défaut dans la configuration de Seo Spider).

Lorsque vous devez utiliser des données de laboratoire, la seule mesure qui n’est pas disponible est le FID (First Input Delay) en raison de l’absence d’interaction demandée par l’utilisateur. Dans ce cas, vous pouvez utiliser le temps de blocage total (TBT) comme indicateur pour voir quelles ressources sont bloquées et, par conséquent, les considérer comme critiques, ce qui peut augmenter le FID.

Si vous devez analyser un site de grande taille, vous risquez de dépasser la limite de quota de PageSpeed Insight. Si vous vous trouvez dans cette situation, je vous conseille d’analyser un échantillon significatif ou d’attendre que le quota soit nul.

N’oubliez pas que les données du CrUX sont basées sur les 28 derniers jours d’interactions avec les utilisateurs, de sorte que tout changement apporté au site prendra 28 jours pour être reflété dans le CrUX.

Tutoriel vidéo de Web Vitals

Seo Spider Tab