Vitesse d'un site : les Core Web Vitals expliqués simplement

Les Core Web Vitals sont trois mesures définies par Google pour juger l’expérience d’une page : le temps d’affichage du contenu principal (LCP), la réactivité aux clics (INP) et la stabilité de la mise en page (CLS). Une page est jugée bonne si elle affiche son contenu principal en 2,5 secondes au plus, réagit en 200 millisecondes au plus et ne bouge presque pas pendant le chargement. Ces mesures comptent pour le référencement, mais surtout pour vos visiteurs, qui partent quand un site est lent.

Que sont les Core Web Vitals ?

« Core Web Vitals » se traduit par « signaux web essentiels ». Ce sont des mesures de l’expérience réelle des visiteurs, choisies par Google pour résumer en trois chiffres ce qu’on ressent en ouvrant une page :

• est-ce que ça s’affiche vite ? C’est le LCP ;
• est-ce que ça réagit quand on touche ? C’est l’INP ;
• est-ce que ça reste en place ? C’est le CLS.

Leur intérêt est d’être mesurés chez les vrais visiteurs, sur leurs vrais téléphones et leurs vraies connexions, et pas seulement sur l’ordinateur rapide du développeur. Les définitions de référence sont publiées sur web.dev, le site de l’équipe Chrome de Google.

Mesure	Ce qu’elle mesure	Bon	Mauvais
LCP (Largest Contentful Paint)	Temps d’affichage du plus grand élément visible	2,5 s ou moins	Plus de 4 s
INP (Interaction to Next Paint)	Délai entre un clic et la réaction visible	200 ms ou moins	Plus de 500 ms
CLS (Cumulative Layout Shift)	Ampleur des décalages de mise en page	0,1 ou moins	Plus de 0,25

Entre les deux, Google parle de valeurs « à améliorer ». Ces seuils sont publiés sur web.dev, dans l’article qui explique comment ils ont été choisis.

LCP : le contenu principal s’affiche-t-il vite ?

Le LCP mesure le temps qu’il faut pour afficher le plus grand élément visible à l’ouverture de la page : souvent la grande photo du haut, parfois le titre principal ou un bloc de texte.

C’est la mesure qui correspond le mieux à l’impression de « site lent ». Quand un client ouvre la page d’un artisan depuis un résultat Google et ne voit qu’un écran blanc pendant cinq secondes, il revient souvent en arrière pour essayer le résultat suivant.

Les causes les plus fréquentes d’un mauvais LCP :

• une image de bandeau trop lourde, envoyée en pleine résolution à un téléphone ;
• un serveur lent à répondre, souvent un hébergement d’entrée de gamme surchargé ;
• des polices, scripts ou feuilles de style qui bloquent l’affichage tant qu’ils ne sont pas chargés ;
• une page construite entièrement en JavaScript, qui n’affiche rien tant que le script n’a pas fini.

INP : la page réagit-elle quand on clique ?

L’INP mesure le délai entre une interaction (un clic, une pression sur l’écran, une touche du clavier) et le moment où la page affiche une réaction. Il tient compte de toutes les interactions de la visite et retient l’une des plus lentes.

Un mauvais INP se ressent ainsi : on touche le bouton « Menu » et rien ne se passe pendant une demi-seconde, alors on touche encore, et le menu s’ouvre puis se referme. Le visiteur a l’impression que le site est cassé.

En général, le coupable est trop de JavaScript qui occupe le téléphone : widgets de réseaux sociaux, outils de suivi, carrousels, bandeaux de cookies lourds, extensions qui s’empilent. Sur un téléphone d’entrée de gamme, chaque script supplémentaire se paie.

CLS : la page reste-t-elle en place ?

Le CLS mesure les déplacements inattendus de la mise en page pendant la visite. Tout le monde a vécu ce moment : on s’apprête à toucher un lien, une image finit de charger au-dessus, le texte descend et l’on touche autre chose.

Les causes classiques :

• des images sans dimensions déclarées, qui poussent le contenu en apparaissant ;
• des bandeaux ou publicités insérés en haut de page après le chargement ;
• des polices qui remplacent la police provisoire avec une taille différente.

Le CLS est souvent le plus simple à corriger : réserver la place des images et des éléments qui arrivent tard suffit dans la plupart des cas.

Les Core Web Vitals comptent-ils pour le référencement Google ?

Oui, mais pas comme on le lit parfois. Google indique dans sa documentation Search Central qu’il recommande vivement d’obtenir de bons Core Web Vitals, et que cela va dans le sens de ce que ses systèmes de classement cherchent à récompenser.

Google précise aussi, dans sa page sur l’expérience sur la page, qu’il cherche toujours à montrer le contenu le plus pertinent, même si l’expérience de la page est médiocre. Une bonne expérience peut faire la différence quand beaucoup de pages répondent aussi bien à une recherche.

Un site rapide ne remplace pas un contenu utile. Mais à contenu égal, il a un avantage, et il garde mieux ses visiteurs.

En pratique, le gain le plus direct est ailleurs : un visiteur qui n’attend pas reste, lit et vous contacte. Pour un site vitrine, c’est ce qui compte.

Comment mesurer la vitesse de son site ?

Deux outils gratuits de Google suffisent pour commencer.

PageSpeed Insights

Sur PageSpeed Insights, entrez l’adresse d’une page. L’outil affiche deux types de résultats :

• les données réelles, issues des visiteurs qui utilisent Chrome, quand votre site a assez de trafic pour qu’elles existent : ce sont celles qui comptent ;
• un test en laboratoire, réalisé à l’instant sur un téléphone simulé, avec une note sur 100 et une liste de pistes d’amélioration.

Ne vous focalisez pas sur la note sur 100 : elle aide à trouver les problèmes, mais les données réelles disent ce que vivent vos visiteurs.

Le rapport de la Search Console

Si votre site est déclaré dans la Google Search Console, le rapport « Signaux Web essentiels » regroupe vos pages en bonnes, à améliorer et mauvaises, sur mobile et sur ordinateur.

Un point important : Google évalue ces mesures au 75e centile, c’est-à-dire qu’une page est jugée bonne si au moins trois visites sur quatre atteignent le seuil. Il ne suffit pas que votre propre ordinateur, avec une bonne connexion, affiche le site vite.

Comment rendre un site plus rapide ?

Les corrections les plus efficaces sont souvent les plus simples.

1. Alléger les images. Les redimensionner à la taille d’affichage, utiliser des formats modernes (WebP, AVIF), et ne charger les images du bas de page que quand on s’en approche.
2. Réduire les scripts tiers. Faire l’inventaire de tout ce que charge le site : outils de suivi, widgets, extensions. Chacun doit justifier sa présence. Notre propre site devolim.fr se passe de cookies et de traceurs, ce qui l’allège aussi.
3. Héberger ses polices sur son propre serveur, en nombre limité, plutôt que de les charger depuis un service externe.
4. Réserver la place des images, vidéos et blocs chargés tard, pour supprimer les décalages.
5. Choisir un hébergement adapté, avec un cache et un réseau de distribution (CDN) qui rapproche les fichiers des visiteurs.
6. Éviter l’empilement d’extensions sur un thème acheté : chaque extension ajoute ses scripts et ses styles, même sur les pages qui ne s’en servent pas.

Quand le site est trop lourd par conception, les corrections ponctuelles trouvent vite leurs limites. C’est souvent le signe qu’une refonte se justifie. Et si vous créez votre premier site, notre article sur le site vitrine d’artisan détaille ce qu’il doit contenir.

Questions fréquentes

Mon site est-il pénalisé s’il échoue aux Core Web Vitals ?

Google ne parle pas de pénalité. Les Core Web Vitals font partie des éléments d’expérience pris en compte par ses systèmes de classement, mais la pertinence du contenu reste prioritaire. Un site lent perd surtout des visiteurs, avant de perdre des positions.

Pourquoi PageSpeed Insights n’affiche-t-il pas de données réelles pour mon site ?

Les données réelles viennent d’un échantillon de visiteurs utilisant Chrome. Un site avec peu de trafic n’en a pas toujours assez pour que Google les publie. Le test en laboratoire reste alors le meilleur indicateur disponible.

Le score de PageSpeed change à chaque test, est-ce normal ?

Oui. Le test en laboratoire dépend des conditions du moment : charge du serveur, réseau, publicités affichées. Faites plusieurs mesures et regardez la tendance plutôt qu’un chiffre isolé.

Faut-il viser 100 sur 100 ?

Non. Passer les trois seuils des Core Web Vitals en données réelles est l’objectif utile. Au-delà, les gains sont rarement visibles pour vos visiteurs.

Nous construisons des sites internet légers, sans thème acheté ni extensions empilées, et nous suivons leurs Core Web Vitals dans le cadre du référencement. Si votre site vous semble lent, parlons-en.