Comprendre PageSpeed Insights : les Core Web Vitals en langage clair
Vous avez testé votre site dans PageSpeed Insights et vous voyez un chiffre en rouge, par exemple 45. Qu'est-ce que cela signifie, et est-ce grave ? Dans cet article, vous découvrez comment lire le rapport, ce que mesurent les trois Core Web Vitals et ce que vous pouvez améliorer vous-même.
Les trois mesures
| Mesure | Ce qu'elle mesure | Bon | Amélioration nécessaire | Mauvais |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | La vitesse à laquelle le plus grand élément de contenu s'affiche, souvent la grande image en haut de page | jusqu'à 2,5 s | de 2,5 à 4 s | plus de 4 s |
| INP (Interaction to Next Paint) | La vitesse à laquelle la page réagit lorsque vous cliquez, touchez ou tapez | jusqu'à 200 ms | de 200 à 500 ms | plus de 500 ms |
| CLS (Cumulative Layout Shift) | De combien la page bouge pendant le chargement (un score, pas une durée) | jusqu'à 0,1 | de 0,1 à 0,25 | plus de 0,25 |
Une page respecte les Core Web Vitals si au moins 75 pour cent des visites obtiennent un bon score sur les trois mesures, séparément pour mobile et pour ordinateur. Ce n'est donc pas votre ordinateur rapide qui compte, mais l'expérience de la majorité des visiteurs, y compris sur un téléphone plus ancien. En mars 2024, l'INP a remplacé l'ancienne mesure FID. Si vous rencontrez encore le FID quelque part, cette information est obsolète.
Données de terrain et données de laboratoire
PageSpeed Insights affiche deux types de mesures, qui donnent souvent des chiffres différents :
- Données de terrain (en haut) : des mesures effectuées auprès de vrais visiteurs utilisant Chrome au cours des 28 derniers jours. C'est ce qui détermine si vous respectez les Core Web Vitals. Si votre page a trop peu de visiteurs, vous voyez les chiffres de l'ensemble de votre site, ou aucune donnée de terrain du tout.
- Données de laboratoire (en dessous) : un test avec Lighthouse, qui charge la page une seule fois sur un téléphone et une connexion moyens simulés. C'est de là que vient le chiffre de 0 à 100. Lighthouse ne peut pas mesurer l'INP, car personne ne clique.
Utilisez les données de laboratoire pour trouver les causes et pour voir immédiatement, après une amélioration, si celle-ci porte ses fruits. Commencez par l'onglet Mobile : les résultats y sont généralement moins bons, et Google tient surtout compte de la version mobile de votre site.
Quel poids cela a-t-il pour Google ?
Google indique que les Core Web Vitals entrent en compte dans le classement. Mais Google affiche toujours le contenu le plus pertinent, même si cette page n'est pas la plus rapide. Le chiffre de 0 à 100 provient du test de laboratoire et n'est pas une évaluation de Google ; cette évaluation provient des données de terrain. Selon Google lui-même, obtenir un score parfait uniquement pour Google n'est pas la meilleure utilisation de votre temps. Veillez à vous situer dans la zone verte ou au moins orange, notamment parce que les visiteurs abandonnent une page lente ou instable.
Ce que vous pouvez améliorer dans la page elle-même
- Des images plus petites. Une photo de plusieurs milliers de pixels de large pour un emplacement de 800 pixels est la cause la plus fréquente d'un LCP lent. Réduisez la taille des photos avant de les mettre en ligne et utilisez un format moderne comme WebP ou AVIF.
- La largeur et la hauteur pour chaque image. Sans
widthetheight, le navigateur ne sait pas quelle place réserver à une photo, et le texte bouge lorsqu'elle apparaît. Cela augmente le CLS :<img src="bouquet.webp" width="800" height="600" alt="Bouquet de mariée avec des roses blanches">
- Ne pas charger paresseusement l'image principale.
loading="lazy"convient pour les photos plus bas sur la page, mais pas pour l'image déjà visible à l'ouverture. Sinon, le navigateur fait justement attendre la photo qui détermine votre LCP. - Ne rien insérer plus tard au-dessus du contenu. Une bannière de cookies, une publicité ou un widget qui pousse la page vers le bas fait tout bouger. Il est préférable qu'une telle bannière se superpose à la page.
- Moins de scripts tiers. Un mauvais INP est presque toujours dû à trop de JavaScript : thèmes lourds, sliders, fenêtres de chat et trackers. Examinez chaque extension ou service intégré d'un œil critique.
Ce que fait le serveur
Tout commence par la première réponse du serveur, le Time to First Byte (TTFB). Il ne s'agit pas d'un Core Web Vital en soi, mais avec une première réponse lente, un bon LCP est presque impossible. À titre indicatif, 0,8 seconde ou moins est une bonne valeur. Les causes sont souvent un site sans cache, une puissance de calcul insuffisante ou des redirections. Le serveur doit également envoyer les fichiers texte de manière compressée (compression gzip ou Brotli). Pour savoir comment agir du côté serveur, consultez Mon site est lent ou utilise trop de CPU : voici comment l'accélérer et le guide DirectAdmin, Mon site est lent.
Dans l'IA Bouwer et WordPress
Un site créé avec l'IA Bouwer définit la largeur et la hauteur des images dont la taille est connue, charge la première image d'une page immédiatement et en priorité, charge le reste uniquement lorsqu'elles deviennent visibles, et crée une version réduite des grandes photos lors de la publication. Sous WordPress, une extension de cache et la réduction de la taille des images apportent le plus de bénéfices. Vous en apprendrez plus dans le cours WordPress gratuit, leçons Qu'est-ce qui rend un site lent, et comment le mesurer ? et Images, PHP et autres gains de vitesse.
Pour aller plus loin
- web.dev : Web Vitals (en anglais)
- À propos de PageSpeed Insights (en anglais)
- Google : expérience de page et recherche Google (en anglais)
- Google : le rapport Signaux Web essentiels