Analyse des Web Vitals.

Core Web Vitals

Grâce à sa connexion à l’API PageSpeed Insights, Screaming Frog SEO Spider te permet de mesurer facilement les Core Web Vitals (CWV) de chaque page de ton site.

Les Core Web Vitals sont un ensemble de métriques introduites par Google en mai 2021 pour mesurer les aspects clés de l’expérience utilisateur pendant le chargement d’une page. C’est une vraie révolution qui aide Google à évaluer les pages et à attribuer leur classement dans les résultats.

Il y a aujourd’hui trois métriques : LCP (chargement), INP (réactivité) et CLS (stabilité visuelle). Google les fait évoluer : en mars 2024, l’INP a remplacé le FID comme métrique de réactivité.

LCP : Largest Contentful Paint

Le Largest Contentful Paint (LCP) indique le temps de rendu de la plus grande image ou du plus grand bloc de texte visible dans le viewport, par rapport au début du chargement. Google fixe un maximum de 2,5 secondes pour une expérience utilisateur satisfaisante.

Pour atteindre cet objectif pour la majorité de tes utilisateurs, un bon seuil est le 75e centile des chargements de page, segmentés entre mobile et desktop.

12

1FCPLe premier contenu visible.2LCPLe plus grand élément du viewport, ici l’image.

INP : Interaction to Next Paint

L’Interaction to Next Paint (INP) mesure la réactivité d’une page : le temps qui s’écoule entre une interaction de l’utilisateur (un clic, un tap, une touche) et le moment où le navigateur affiche la réponse, c’est-à-dire le « paint » suivant.

Depuis le 12 mars 2024, l’INP a remplacé le First Input Delay (FID) parmi les Core Web Vitals. Le FID avait deux limites importantes :

• il ne mesurait que la première interaction avec la page, en ignorant toutes les suivantes ;
• il ne mesurait que le délai d’entrée, c’est-à-dire l’attente avant que le navigateur commence à traiter l’événement, et pas le temps de traitement ni de mise à jour de la page.

L’INP, lui, observe toutes les interactions pendant la visite et additionne pour chacune trois phases :

1. Input delay : l’attente avant le lancement des gestionnaires d’événements, souvent parce que le thread principal est occupé par d’autres scripts ;
2. Processing time : le temps d’exécution du JavaScript lié à l’interaction ;
3. Presentation delay : le temps nécessaire au navigateur pour recalculer la mise en page et dessiner la nouvelle image.

La valeur finale est l’interaction la plus lente de la visite (sur les pages avec énormément d’interactions, Google écarte les valeurs aberrantes). C’est donc une métrique bien plus sévère et réaliste que le FID : une page peut bien répondre au premier clic mais se figer quand l’utilisateur ouvre un filtre ou ajoute un produit au panier.

Les interactions ralentissent surtout quand le navigateur est occupé par d’autres tâches. Dans la chronologie ci-dessous, les long tasks, ces tâches qui occupent le thread principal plus de 50 ms, sont mises en évidence : si l’utilisateur clique pendant l’une d’elles, la réponse n’arrive qu’une fois la tâche terminée.

12

1Long TasksLes scripts longs qui bloquent le navigateur.2CPUL’activité du processeur pendant le chargement.

Pour une bonne expérience de navigation, Google indique que l’INP doit être inférieur ou égal à 200 millisecondes ; entre 200 et 500 ms la page doit être améliorée, au-delà de 500 ms la réactivité est mauvaise. Pour atteindre cet objectif pour la majorité de tes utilisateurs, un bon seuil est le 75e centile des chargements de page, segmentés entre mobile et desktop.

CLS : Cumulative Layout Shift

Le Cumulative Layout Shift (CLS) est une métrique centrée sur l’utilisateur, très importante, qui mesure la stabilité visuelle de la mise en page pendant le chargement d’une page HTML. Il a été introduit pour limiter les déplacements inattendus et désagréables dus, par exemple, aux bannières publicitaires. On a tous vécu l’expérience frustrante de lire un article sur un site d’actualité et de voir le texte sauter plus bas pendant le chargement ; le CLS mesure justement cette instabilité.

Ci-dessous, tu peux voir ce phénomène pendant le chargement de la page. À chaque étape, du contenu s’ajoute et déplace vers le haut ou le bas les éléments précédents.

12

1Bannière cookiesUn élément qui apparaît puis disparaît.2Bannière promotionnellePousse le contenu de la page vers le bas.

Pour une bonne expérience utilisateur, les sites devraient viser un score CLS de 0,1 ou moins. Pour atteindre cet objectif pour la majorité de tes utilisateurs, un bon seuil est le 75e centile des chargements de page, segmentés entre mobile et desktop.

Les Core Web Vitals reposent sur les données réelles du Chrome User Experience Report (CrUX) des 28 derniers jours, issues des visites des utilisateurs sur une page.

Chaque Web Vital est classé dans l’une de trois catégories : Good, Needs Improvement et Poor.

Pour valider le Core Web Vitals Assessment, une page doit être « Good » sur les trois métriques.

Voici les seuils de chaque métrique, mesurés au 75e centile :

Métrique	Good	Needs Improvement	Poor
LCP (chargement)	≤ 2,5 s	2,5 – 4 s	> 4 s
INP (réactivité)	≤ 200 ms	200 – 500 ms	> 500 ms
CLS (stabilité visuelle)	≤ 0,1	0,1 – 0,25	> 0,25

Analyser les Core Web Vitals

Les Core Web Vitals des sites sont enregistrés dans le Chrome User Experience Report, et on peut les consulter essentiellement de deux façons.

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

1234

1Évaluation des Core Web VitalsRéussie si LCP, INP et CLS sont tous Good.2INP130 ms : sous le seuil Good de 200 ms.3Autres métriquesFCP et TTFB aident à diagnostiquer le chargement.4Source des donnéesChrome UX Report, 28 derniers jours, utilisateurs réels.

La deuxième solution est la section « Core Web Vitals » de la Search Console, qui indique les performances des pages, les erreurs et les avertissements pour ces métriques.

123

1Core web vitalsLe rapport dans la section Enhancements.2MobileURL poor, à améliorer et good sur mobile.3DesktopLes mêmes données pour desktop.

Ces deux contrôles sont efficaces, mais aussi très limités : le premier ne vérifie qu’une URL à la fois, tandis que la GSC regroupe plusieurs URL (modèles d’URL) sans donner de scores individuels.

Analyse des Web Vitals avec Screaming Frog

Grâce à sa connexion à l’API PageSpeed Insights, Screaming Frog SEO Spider collecte facilement les données des Web Vitals et te fournit des données précises pour chaque URL, à partir des données réelles CrUX et des données de laboratoire. La configuration se fait en quelques étapes simples.

• 1. Connexion à l’API PageSpeed : va dans 1Configuration›2API Access›3PageSpeed Insights, saisis ta Secret Key et clique sur Connect.

123

1Account InformationL’onglet pour connecter l’API.2Secret KeyLa clé API créée dans la Google Cloud Console.3ConnectConnecte SEO Spider à l’API.

• 2. Choix des métriques.

Une fois connecté à PSI, clique sur l’onglet « Metrics » et choisis celles à inclure dans l’analyse. Pour tes premiers crawls des Core Web Vitals, je te conseille la sélection par défaut : elle comprend les données du rapport CrUX, les données de laboratoire de Google Lighthouse et les opportunités d’amélioration.

123

1MetricsL’onglet des métriques à collecter.2DeviceMobile ou Desktop.3CrUX MetricsLes données réelles, comme le Core Web Vitals Assessment.

• 3. Lancement du crawl.

Une fois les métriques de l’API configurées, lance le crawler et attends que le site soit crawlé et rempli avec les données des Core Web Vitals.

• 4. Analyse des données

Il ne reste plus qu’à cliquer sur l’onglet PageSpeed pour voir tous les détails du crawl : les URL qui ont réussi le test, celles à améliorer et celles qui ont des problèmes graves.

123

1PageSpeedL’onglet avec les données de PageSpeed Insights.2PSI StatusSuccess si l’API a renvoyé les données.3MétriquesPerformance Score, FCP, Speed Index, LCP.

Dans l’exemple ci-dessus (réglages par défaut), la première colonne montre les URL et la deuxième l’état du « Core Web Vitals Assessment ». Le statut PSI est « Pass » ou « Fail » selon que la page est bonne sur les trois Web Vitals.

Sur la capture, l’URL du haut a un LCP de 1,99 s (sous 2,5 s), une réactivité de 37 ms (le FID à l’époque, aujourd’hui remplacé par l’INP avec un seuil de 200 ms) et un CLS de 0,06 (sous 0,1) : elle a donc validé les CWV.

Cette vue d’ensemble te permet de voir tout de suite quelles pages ont échoué et sur quelles métriques CWV intervenir.

Il arrive que certaines URL n’aient pas de données CWV : c’est le cas quand CrUX ne dispose pas d’assez de données de vitesse, faute de visiteurs. En général, seules les pages les plus populaires ont assez de données pour le Chrome UX Report.

• 5. Segmentation des schémas d’erreur

Une fois les données obtenues, tu peux examiner chaque métrique CWV avec différents filtres, isoler les problèmes à optimiser et obtenir toutes les URL qui présentent le même problème.

12

1FiltresLes opportunités de Lighthouse sous forme de filtres.2Performance ScoreLe score de chaque URL.

En sélectionnant une URL dans la fenêtre supérieure et en cliquant sur l’onglet « PageSpeed Details » (fenêtre inférieure), tu trouves toute une série de détails supplémentaires et d’opportunités pour corriger les erreurs ou avertissements.

123

1OpportunitiesLes optimisations avec le gain estimé.2RessourcesLes URL des ressources et le gain en octets.3PageSpeed DetailsL’onglet de la fenêtre inférieure.

Optimiser le LCP

Commençons par définir les zones qui influent sur le LCP et les facteurs à optimiser pour améliorer la métrique.

• Properly Size Images.
• Defer Offscreen Images.
• Efficiently Encode Images.
• Serve Images in Next-Gen Formats.

Le point de départ, ce sont les images, l’un des piliers des performances des pages HTML. Pour améliorer le LCP, assure-toi que chaque image est bien dimensionnée et utilise le lazy loading quand c’est pertinent.

Il est conseillé d’utiliser des formats d’image récents et plus efficaces comme WebP et d’améliorer l’encodage des images existantes.

Le temps de réponse du serveur pèse aussi beaucoup. Un serveur peu puissant entraîne des réponses lentes et des temps de chargement plus longs ; je te conseille donc un hébergement plus performant ou des CDN (Content Delivery Networks) pour réduire les temps de réponse et améliorer le TTFB.

Parmi les optimisations possibles, sois très attentif aux ressources qui bloquent le rendu. Pendant l’analyse du HTML, chaque référence à une feuille de style peut mettre le parser en pause et retarder le LCP.

Idéalement, tu devrais différer tout CSS et JavaScript non critique pour accélérer le chargement du contenu principal, et utiliser le « preload » pour les ressources critiques. Autre conseil : minifier le CSS et le JavaScript, supprimer les fichiers inutiles du chargement, et utiliser le « preconnect » pour les ressources tierces (par ex. Google Analytics, Tag Manager).

• Minify CSS.
• Minify JavaScript.
• Remove Unused CSS.
• Remove Unused JavaScript.
• Enable Text Compression.
• Preconnect to Required Origins.
• Preload key Requests.
• Use Video Formats for Animated Content.

Optimiser l’INP

Dans la plupart des cas, l’INP se dégrade à cause de longs temps d’exécution de gros scripts, qui occupent le thread principal au moment précis où l’utilisateur interagit. La première action consiste à minifier et supprimer les parties de scripts inutilisées (ou des scripts entiers), pour réduire le temps d’exécution et de rendu de ces fichiers.

• Minify JavaScript.
• Remove Unused JavaScript.
• Reduce the Number of Third-Party Scripts Used.

Pour trouver la liste des ressources tierces, consulte ton document HTML dans l’onglet PageSpeed Details.

Autre optimisation : le travail du thread principal. Si le navigateur est occupé par le rendu sur le thread principal, l’utilisateur ne peut pas interagir avec la page tant que ce n’est pas fini. En réduisant ce temps d’exécution, les interactions deviennent plus réactives et immédiates.

Les principales solutions consistent à réduire l’exécution du JavaScript et le travail sur le main thread. Pour l’INP en particulier :

• découpe les long tasks en tâches plus courtes en rendant la main au navigateur (par exemple avec scheduler.yield() ou setTimeout), pour que les interactions ne restent pas en file d’attente ;

• garde des gestionnaires d’événements légers et reporte le travail non urgent après le paint ;

• réduis la taille du DOM, car un DOM très volumineux allonge le recalcul de la mise en page après chaque interaction (Avoid Excessive DOM Size).

• Minimise Main-Thread Work

• Reduce JavaScript Execution Time

N’oublie pas non plus que chaque ressource nécessaire à une page prend du temps à être demandée, téléchargée et exécutée. En réduisant le nombre de requêtes et la taille totale du téléchargement, tu améliores les temps d’exécution.

Les actions utiles : minifier le CSS et le JavaScript, supprimer les feuilles de style et le JavaScript inutilisés et compresser le texte.

• Lower Resource Counts & Sizes.
• Minify CSS.
• Minify JavaScript.
• Remove Unused CSS.
• Remove Unused JavaScript.
• Enable Text Compression.

Optimiser le CLS

Comme on l’a vu, la stabilité de la mise en page est au cœur du CLS et d’une bonne expérience : concentre-toi sur le fait de servir la page dans le bon ordre, avec un espace défini pour chaque ressource, pour éviter les sauts pendant la navigation.

Pour de bons résultats, assure-toi que toutes les images, annonces, vidéos et iframes ont les attributs <height> et <width>, afin que les pages se chargent avec le bon espacement et que les autres contenus ne bougent pas quand ils s’ajoutent. Autre point pour le CLS : charger en priorité les ressources de haut en bas, pour ne pas renvoyer vers le haut l’utilisateur déjà descendu dans la page.

Vérifie que les polices personnalisées ne provoquent pas d’effet FOIT/FOUT : si elles sont appliquées tard, le texte peut clignoter en étant remplacé (FOUT), ou rester invisible jusqu’au rendu de la police (FOIT). Pour éviter ce délai, je te conseille le « preload » des ressources critiques.

Screaming Frog et les Web Vitals

Si tes URL n’affichent aucune donnée CrUX alors que le statut PSI indique ‘success’, l’URL ne reçoit probablement pas assez de visites réelles pour générer suffisamment de données de vitesse pour le rapport CrUX. Si tu te retrouves dans ce cas après un crawl avec Screaming Frog, tu peux analyser une page à la mise en page similaire qui a des données CrUX, ou utiliser les données de laboratoire simulées (incluses par défaut dans la configuration de SEO Spider).

Avec les données de laboratoire, la seule métrique indisponible est l’INP, car Lighthouse ne simule pas les interactions d’un vrai utilisateur. Dans ce cas, utilise comme indicateur le Total Blocking Time (TBT) : il mesure combien de temps le thread principal reste bloqué par des long tasks pendant le chargement et il est très corrélé à l’INP ; les ressources qui le font grimper sont donc les premières à optimiser.

Si tu dois analyser un très grand site, tu risques de dépasser le quota de PageSpeed Insights. Dans ce cas, je te conseille d’analyser un échantillon significatif ou d’attendre la remise à zéro du quota.

N’oublie pas que les données CrUX reposent sur les 28 derniers jours d’interactions : toute modification du site mettra 28 jours à se refléter dans CrUX.

Tutoriel vidéo sur les Web Vitals (en italien)

Tutoriel vidéoScreaming Frog : analyse des Core Web VitalsRegarder la vidéo3:43