Core Web Vitals : la vitesse d’un site expliquée

« Mon site est-il assez rapide pour Google ? » Google répond avec trois mesures, les Core Web Vitals, ou signaux web essentiels. Elles sont relevées chez de vrais visiteurs, sur leurs vrais téléphones, et décrivent ce qu’ils ressentent : la page arrive-t-elle vite, répond-elle quand on touche, reste-t-elle en place ?

Voici ce qu’elles mesurent, les seuils à viser, comment les relever sans être développeur, et ce qu’elles pèsent réellement dans le classement.

Trois mesures, trois sensations

• LCP (Largest Contentful Paint) : le temps qu’il faut pour afficher le plus grand élément visible au premier écran, une image, un bloc de texte, l’affiche ou la première image d’une vidéo. C’est la sensation de chargement.
• INP (Interaction to Next Paint) : le délai entre un geste du visiteur (un toucher, un clic, une touche du clavier) et la réaction visible de la page, observé sur toute la visite. Le survol et le défilement ne comptent pas. INP a remplacé l’ancienne mesure FID en mars 2024.
• CLS (Cumulative Layout Shift) : les sauts de mise en page, quand un texte descend d’un coup parce qu’une image ou un bandeau s’est chargé au-dessus. C’est la stabilité.

Les seuils, tels que Google les publie :

La règle du 75e centile

Un seuil ne se juge pas sur une visite. Google regarde le 75e centile des visites, séparément sur mobile et sur ordinateur. Dit autrement : au moins trois visites sur quatre doivent être dans le vert. Une page passe le test si elle tient les trois seuils à la fois, et dans la Search Console, un groupe de pages prend la note de sa plus mauvaise mesure.

Peu de sites y arrivent. En juillet 2025, 48 % des sites passaient les trois seuils sur mobile, contre 44 % un an plus tôt. Le LCP est le plus difficile : 62 % des sites l’avaient bon sur téléphone, contre 77 % pour l’INP et 81 % pour le CLS (Web Almanac 2025, HTTP Archive).

Les mesurer sans être développeur

1. PageSpeed Insights. Collez l’adresse de votre site. Le haut de la page montre les données réelles des utilisateurs de Chrome sur les 28 derniers jours. Le bas montre un test de laboratoire : un chargement simulé, sur un appareil et une connexion fixés.
2. Le rapport Core Web Vitals de la Search Console. Les mêmes données réelles, par groupes de pages, sur mobile et sur ordinateur. Seules les pages indexées y figurent. Après une correction, le bouton de validation lance une surveillance de 28 jours.
3. Lighthouse, dans les outils de développement de Chrome, pour tester pendant que vous modifiez la page. Il ne mesure pas l’INP, faute de vrai visiteur, et le remplace par une estimation.

Un petit site n’a souvent pas assez de visites pour que Chrome publie ses données réelles. PageSpeed Insights se rabat alors sur l’ensemble du site, ou n’affiche que le test de laboratoire. Complétez par un essai sur votre propre téléphone, en 4G, dans la rue.

Ce que la vitesse pèse dans Google

Google le dit clairement : ses systèmes de classement cherchent à récompenser les pages qui offrent une bonne expérience, et ils tiennent compte des Core Web Vitals. Il n’existe pas pour autant de « signal d’expérience de page » unique.

Mais Google ajoute que la recherche montre toujours le contenu le plus pertinent, même si l’expérience de page laisse à désirer. De bonnes mesures ne garantissent pas d’être en tête. Elles comptent surtout quand de nombreuses pages utiles répondent aussi bien à la même question.

En clair : une page rapide qui ne répond à rien ne battra pas une page plus lente qui répond. Le contenu d’abord. La vitesse départage, et surtout, elle retient vos visiteurs.

Ce qui ralentit le plus souvent un petit site

Le poids. En juillet 2025, la page d’accueil médiane pesait plus de 2 Mo sur mobile, et les images représentaient la plus grosse part des octets (Web Almanac 2025). L’aide de la Search Console donne un repère bien plus sévère : moins de 500 Ko pour une page et toutes ses ressources, et au plus 50 ressources sur mobile. Une page à fond vidéo le dépasse vite ; raison de plus pour que la vidéo soit courte, compressée, et que tout le reste soit léger.

Le LCP. Les conseils de web.dev pour l’accélérer :

• l’image principale est déclarée directement dans la page, et non découverte plus tard par un script ;
• elle n’est jamais chargée en différé : on réserve le chargement paresseux aux images plus bas ;
• elle est servie à la bonne taille, dans un format moderne comme WebP ou AVIF ;
• les polices ne bloquent pas l’affichage du texte pendant leur chargement.

Un détail utile pour un premier écran plein cadre : Chrome écarte du calcul les éléments qui couvrent tout l’écran, qu’il traite comme un fond. Le plus grand élément mesuré peut alors être votre titre. Qu’il s’affiche tôt, sans attendre une police ou un script.

Le CLS. Les causes classiques : des images et des vidéos sans dimensions déclarées, une police de remplacement plus grande ou plus petite que la police finale, un bandeau ou un widget inséré au-dessus du contenu après coup.

L’INP. Il souffre quand le navigateur est occupé à exécuter de longs scripts au moment où le visiteur touche l’écran. Chaque script ajouté, ceux des services tiers compris, peut y contribuer.

Sur les sites composés dans l’atelier de 29webs, la vidéo de fond est réencodée et allégée, sans piste son, et accompagnée d’une affiche. Si le visiteur a demandé moins d’animations à son appareil, la vidéo s’efface et l’affiche reste. Le détail est sur la page du fond vidéo.

En résumé : visez un affichage en 2,5 secondes, une réaction en 200 millisecondes et une page qui ne saute pas, pour trois visites sur quatre. Mesurez avec PageSpeed Insights et la Search Console. Et gardez l’ordre de Google : la pertinence d’abord, la vitesse ensuite.