Core Web Vitals : LCP, INP et CLS

Module 4: Vitesse, mobile et https · Temps de lecture : 13 minutes

Objectif pédagogique : À l'issue de cette leçon, vous saurez expliquer les trois Core Web Vitals et leurs seuils, faire la différence entre données de terrain et données de laboratoire, lire une mesure avec PageSpeed Insights, traiter les principales causes d'un mauvais score et évaluer honnêtement le poids de la vitesse dans les résultats de recherche.

Notions clés : Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75e centile, données de terrain (CrUX), données de laboratoire (Lighthouse), PageSpeed Insights, rapport Core Web Vitals dans la Search Console, TTFB, compression, width et height sur les images, loading="lazy", expérience sur la page

La vitesse en trois chiffres

« Mon site est-il rapide ? » est une question vague. Google et les créateurs de Chrome en ont fait trois questions mesurables, les Core Web Vitals :

Quelques points à bien comprendre :

• LCP mesure le moment où le plus grand élément visible apparaît. Il s'agit généralement d'une grande photo en haut de page (le « hero ») ou d'un grand bloc de texte. Chez Bloemenatelier Lotte, c'est la photo de la composition florale sur la page d'accueil.
• INP observe tous les clics, toucher et frappes au clavier pendant la visite et rapporte (presque) la réaction la plus lente. Le 12 mars 2024, l'INP a remplacé l'ancienne mesure FID (First Input Delay), qui ne regardait que le premier clic et seulement l'attente avant le traitement. Si vous croisez le FID dans un ancien article, l'information est dépassée.
• CLS n'est pas une durée mais un score sans unité. Il augmente quand des éléments se déplacent pendant que vous lisez : vous voulez toucher un bouton et, à cet instant, une bannière apparaît au-dessus, si bien que vous touchez autre chose.

Le 75e centile

Une page « réussit » les Core Web Vitals quand 75 % des visites obtiennent un bon résultat sur les trois mesures, évaluées séparément sur mobile et sur ordinateur. C'est ce qu'on appelle le 75e centile. Concrètement, ce n'est pas votre ordinateur rapide sur la fibre qui compte, mais l'expérience de la plupart des visiteurs, y compris ceux qui utilisent un téléphone plus ancien en 4G.

Données de terrain et données de laboratoire

Il existe deux types de mesures, et elles donnent souvent des chiffres différents.

• Les données de terrain proviennent de vrais visiteurs. Chrome collecte de manière anonyme (auprès des utilisateurs qui l'acceptent) la vitesse des pages dans le Chrome User Experience Report (CrUX). PageSpeed Insights affiche les données de terrain des 28 derniers jours. Le rapport Core Web Vitals de la Search Console utilise la même source. Si votre page a trop peu de visiteurs, PageSpeed Insights affiche les chiffres de l'ensemble de votre site (l'« origine ») ; si celui-ci en a aussi trop peu, il n'y a pas de données de terrain.
• Les données de laboratoire proviennent d'un test simulé avec Lighthouse : un seul chargement sur un téléphone et une connexion moyens simulés. Lighthouse ne peut pas mesurer l'INP (personne ne clique) et fournit donc d'autres chiffres, comme le Total Blocking Time, qui donnent toutefois une indication sur l'INP.

Ce sont les données de terrain qui comptent pour l'évaluation. Les données de laboratoire sont utiles pour trouver les causes et pour vérifier immédiatement, après une amélioration, si elle porte ses fruits, sans attendre 28 jours.

Quel poids dans le classement ?

On exagère beaucoup sur ce point. Voici ce que Google en dit lui-même dans sa documentation sur l'expérience sur la page :

• « Core Web Vitals are used by our ranking systems » : ils comptent donc.
• Il n'existe pas de « signal d'expérience sur la page » distinct. Selon Google, les autres aspects d'une bonne expérience sur la page (https, pas de pop-ups intrusives, utilisabilité sur mobile) ne vous font pas monter directement, mais ils rendent votre site plus agréable.
• « Google Search always seeks to show the most relevant content, even if the page experience is sub-par. » Une page lente qui offre la meilleure réponse peut donc tout à fait apparaître en tête.
• Selon Google, viser un score parfait uniquement pour le SEO n'est « peut-être pas la meilleure utilisation de votre temps ».

Conclusion : veillez à être dans la zone verte, ou au moins orange, surtout parce que les visiteurs abandonnent une page lente ou qui bouge. Courir après les 100 points au lieu de 90 dans Lighthouse rapporte peu dans les résultats de recherche.

Les causes que vous pouvez traiter vous-même

Une première réponse lente (TTFB)

Tout commence au moment où le premier octet du HTML arrive : c'est le Time to First Byte. Le TTFB n'est pas lui-même un Core Web Vital, mais un TTFB lent rend un bon LCP presque impossible. web.dev donne comme valeur de référence : bon à 0,8 seconde ou moins, mauvais au-delà de 1,8 seconde. Causes citées par web.dev : un hébergement manquant de puissance, l'absence de cache (chaque page est reconstruite à chaque fois, typique d'un WordPress sans extension de cache), les redirections (leçon 4.1) et un serveur éloigné sans CDN.

La compression en fait partie : le serveur doit envoyer le HTML, le CSS et le JavaScript compressés avec gzip ou Brotli. Vous le voyez à l'en-tête Content-Encoding: gzip ou br. Presque tous les hébergements le font par défaut, mais un mauvais réglage ou un ancien serveur peut la désactiver.

Les images

Les images sont la cause la plus fréquente d'un mauvais LCP et d'un mauvais CLS :

1. Trop lourdes. Une photo de 4.000 pixels de large et de 5 Mo pour un emplacement de 800 pixels. Réduisez-la avant de la mettre en ligne et utilisez un format moderne comme WebP ou AVIF.

2. Pas de largeur ni de hauteur. Sans width et height, le navigateur ne sait pas combien de place l'image occupera, et le texte situé en dessous se décale dès qu'elle arrive. web.dev recommande de placer width et height sur chaque <img> :

   <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">

3. Charger la photo principale en différé. loading="lazy" ne charge une image qu'au moment où elle devient visible. C'est parfait pour les photos plus bas dans la page, mais web.dev est clair : les images visibles dès l'ouverture, et surtout l'image LCP, ne doivent pas être chargées en différé. Sinon, le navigateur fait attendre précisément la photo qui détermine votre LCP.

Contenu qui se décale et réactions lentes

Autres causes de CLS selon web.dev : des polices qui changent de taille au chargement, des publicités et des widgets intégrés qui s'agrandissent, et du contenu inséré après coup au-dessus du contenu existant (comme un bandeau de cookies qui pousse la page vers le bas au lieu de se superposer). Un mauvais INP vient presque toujours d'un excès de JavaScript : thèmes lourds, carrousels, widgets de chat et traceurs tiers. Examinez d'un œil critique chaque extension ou service intégré ; ici, moins, c'est vraiment mieux.

En pratique : mesurer avec PageSpeed Insights

Rendez-vous sur pagespeed.web.dev, saisissez l'adresse de votre page d'accueil et cliquez sur Analyser. Vous obtenez deux onglets (Mobile et Ordinateur). En haut figure l'évaluation des Core Web Vitals d'après les données de terrain, s'il y en a. En dessous, le test Lighthouse avec un score et une liste « Diagnostic » contenant des points concrets, par exemple des images plus grandes que nécessaire ou une image LCP chargée en différé (les intitulés exacts changent avec les nouvelles versions de Lighthouse). Commencez par Mobile : les résultats y sont généralement moins bons, et Google regarde d'abord la version mobile (leçon 4.2).

Si votre site est dans la Search Console (module 2), consultez aussi Expérience, Signaux Web essentiels. Vous y verrez des groupes de pages similaires avec leur statut, y compris pour des pages que vous n'aviez pas testées vous-même.

Un site créé avec AI Builder indique la largeur et la hauteur des images dont la taille est connue, charge la première photo de la page immédiatement et en priorité (fetchpriority="high") et les autres en différé, et crée lors de la publication une variante de 800 pixels de large pour les grandes photos. Dans WordPress, ce sont une extension de cache et la réduction des images qui aident le plus ; la formation WordPress approfondit ce sujet au module 6. Chez d'autres créateurs de sites et hébergeurs, le principe est le même : les boutons diffèrent, les causes sont identiques.

Résumé

• Les Core Web Vitals sont le LCP (bon jusqu'à 2,5 s), l'INP (bon jusqu'à 200 ms, à la place du FID depuis mars 2024) et le CLS (bon jusqu'à 0,1), mesurés au 75e centile par type d'appareil.
• Les données de terrain (CrUX, 28 jours) déterminent l'évaluation ; les données de laboratoire (Lighthouse) aident à trouver les causes.
• Google utilise les Core Web Vitals dans son classement, mais la pertinence passe avant : un score parfait n'est pas un but en soi.
• Les plus gros gains : une réponse rapide du serveur avec cache et compression, des images légères avec width et height, la photo principale non chargée en différé, moins de JavaScript tiers.

Quiz

Exercice

Exercice A4.3 : Réponse rapide et images légères. Saisissez l'adresse d'une page. Le programme mesure trois fois le temps jusqu'au premier octet (TTFB) depuis notre serveur et retient la valeur médiane, vérifie si le HTML est envoyé compressé (gzip, Brotli ou zstd), compte les images sans width ni height, et vérifie que l'image principale en haut de page n'est pas chargée avec loading="lazy". Attention : il s'agit d'une mesure depuis un seul endroit, pas d'une mesure de vos visiteurs. Vous n'avez pas de site ? Utilisez www.wikipedia.org.

Exercice D4.3 : Vos Core Web Vitals. Lancez PageSpeed Insights sur votre page d'accueil et sur une autre page importante, d'abord sur Mobile. Notez pour chaque page : existe-t-il des données de terrain (pour la page ou pour tout le site), le LCP, l'INP et le CLS issus des données de terrain, le score Lighthouse et l'élément que Lighthouse désigne comme élément LCP. Choisissez l'amélioration qui, selon vous, rapportera le plus, et expliquez pourquoi.

Pour aller plus loin

• web.dev, Web Vitals : https://web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP) : https://web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP) : https://web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS) : https://web.dev/articles/cls
• web.dev, Time to First Byte (TTFB) : https://web.dev/articles/ttfb
• web.dev, Browser-level image lazy loading : https://web.dev/articles/browser-level-image-lazy-loading
• Google Search Central, Understanding page experience in Google Search results : https://developers.google.com/search/docs/appearance/page-experience
• PageSpeed Insights, About PageSpeed Insights : https://developers.google.com/speed/docs/insights/v5/about
• Aide Search Console, Core Web Vitals report : https://support.google.com/webmasters/answer/9205520