Sommaire
Les Core Web Vitals, appelés signaux web essentiels en français, sont trois mesures de Google qui décrivent ce que vit réellement un visiteur quand votre page se charge : le temps d'affichage de l'élément principal (LCP, sous 2,5 secondes), la réactivité aux clics (INP, sous 200 millisecondes) et la stabilité de la mise en page (CLS, sous 0,1). Elles se mesurent gratuitement avec PageSpeed Insights, et la plupart des sites de petites entreprises les améliorent nettement avec dix corrections classées par impact. Voici le guide.
Les trois métriques expliquées simplement#
Google a choisi trois mesures parce qu'elles correspondent aux trois questions qu'un visiteur se pose sans les formuler : est-ce que ça s'affiche, est-ce que ça réagit, est-ce que ça bouge dans tous les sens.
LCP : le temps d'affichage de l'élément principal#
Le Largest Contentful Paint mesure le moment où le plus grand élément visible de l'écran est affiché : souvent une photo de couverture, parfois un gros titre ou une vidéo. C'est l'instant où le visiteur a le sentiment que la page est là. Google considère qu'un LCP est bon sous 2,5 secondes, à améliorer entre 2,5 et 4 secondes, mauvais au-delà.
Le LCP est presque toujours le point faible des sites de TPE : une image de héros de plusieurs mégaoctets, chargée après une dizaine de scripts, sur une connexion mobile moyenne.
INP : la réactivité aux interactions#
L'Interaction to Next Paint mesure le délai entre une action du visiteur (un clic sur un menu, un bouton, un champ de formulaire) et la réaction visible de la page. Il a remplacé l'ancienne mesure FID en 2024 et il est plus exigeant, car il regarde toutes les interactions de la visite, pas seulement la première. Un INP est bon sous 200 millisecondes, à améliorer jusqu'à 500, mauvais au-delà.
Un INP dégradé vient de scripts qui occupent le processeur du téléphone au moment où le visiteur agit : outils de suivi, widgets de chat, carrousels, animations lourdes.
CLS : la stabilité visuelle#
Le Cumulative Layout Shift mesure les déplacements inattendus des éléments pendant le chargement : le texte qui saute parce qu'une image ou une publicité s'insère au-dessus, le bouton qui bouge au moment où l'on clique. Un CLS est bon sous 0,1, à améliorer jusqu'à 0,25, mauvais au-delà.
Le CLS se corrige bien : il suffit le plus souvent de réserver la place des images, des vidéos et des bandeaux avant leur chargement.
| Métrique | Ce qu'elle mesure | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP | Affichage de l'élément principal | ≤ 2,5 s | 2,5 à 4 s | > 4 s |
| INP | Réactivité aux interactions | ≤ 200 ms | 200 à 500 ms | > 500 ms |
| CLS | Stabilité de la mise en page | ≤ 0,1 | 0,1 à 0,25 | > 0,25 |
Google publie et met à jour ces seuils dans sa documentation sur web.dev.
Données terrain et données de laboratoire : ne pas confondre#
C'est la source de la plupart des malentendus sur la vitesse.
Les données terrain viennent de vrais visiteurs, sur leurs appareils et leurs connexions, collectées par Chrome. Ce sont elles que Google utilise pour évaluer votre site. Elles portent sur les 28 derniers jours, sont collectées surtout sur mobile (Google indexe en mobile-first) et ne sont publiées que si le site reçoit assez de visites.
Les données de laboratoire sont produites par un test automatisé, sur un appareil et une connexion simulés, au moment où vous lancez l'outil. Elles sont reproductibles et détaillées, mais elles ne représentent pas l'expérience réelle : un test en laboratoire simule souvent un téléphone d'entrée de gamme sur une connexion lente, ce qui donne des chiffres bien plus sévères que ce que vivent la plupart de vos visiteurs.
Conséquence pratique : si votre site a des données terrain, c'est elles qu'il faut regarder en premier. Les données de laboratoire servent ensuite à trouver quoi corriger. Si votre site n'a pas de données terrain, faute de trafic, travaillez sur le laboratoire sans paniquer devant un score rouge : il est calculé dans des conditions défavorables.
Comment mesurer les Core Web Vitals#
Deux outils gratuits suffisent.
PageSpeed Insights. Rendez-vous sur pagespeed.web.dev, entrez l'adresse d'une page et lancez l'analyse. Le rapport s'ouvre sur les données réelles (si elles existent) pour la page et pour l'ensemble du site, puis affiche les mesures de laboratoire et une liste de recommandations classées par gain estimé. Testez en priorité la page d'accueil, vos pages de services les plus visitées et une fiche produit ou un article : les problèmes diffèrent d'un gabarit à l'autre.
La Search Console. Le rapport « Signaux Web essentiels » de la Search Console regroupe les adresses de votre site par état (bon, à améliorer, mauvais) et par problème, sur mobile et sur ordinateur. C'est l'outil pour voir l'ensemble d'un coup et suivre l'effet des corrections dans le temps.
Notre audit SEO gratuit intègre aussi une lecture de la performance dans son score sur 100, avec les autres points techniques et éditoriaux : c'est un bon point de départ si vous voulez tout voir sur un seul rapport en deux minutes.
Les 10 corrections par ordre d'impact#
L'ordre ci-dessous correspond à ce que nous constatons le plus souvent sur les sites de TPE et PME : on commence par ce qui fait gagner le plus de temps pour le moins d'effort.
1. Les images#
Le premier poste dans la quasi-totalité des cas. Trois actions : compresser (une photo de couverture n'a pas besoin de dépasser quelques centaines de kilo-octets), utiliser un format moderne (WebP ou AVIF, plus légers que JPEG et PNG à qualité égale), et servir des dimensions adaptées à l'écran (une image affichée en 400 pixels de large ne doit pas peser comme une image de 4 000 pixels). La plupart des CMS et des thèmes récents font ces conversions automatiquement une fois activées. Profitez-en pour vérifier la balise alt de chaque image : elle ne pèse rien et compte pour le référencement.
2. Les scripts tiers#
Outils de suivi publicitaire, pixels, widgets de chat, cartes, vidéos intégrées, boutons de partage : chacun charge des dizaines ou des centaines de kilo-octets de code et occupe le processeur. Faites l'inventaire, supprimez ce qui ne sert pas, et chargez le reste après l'affichage du contenu principal plutôt qu'avant.
3. Les polices#
Chaque police web téléchargée retarde l'affichage du texte. Limitez-vous à une ou deux familles, à deux ou trois graisses, hébergez les fichiers sur votre propre domaine et autorisez l'affichage d'une police de remplacement en attendant (l'option d'échange de police, disponible dans la plupart des thèmes et des CMS).
4. Le cache#
Le cache permet au navigateur de conserver les fichiers qui ne changent pas (images, feuilles de style, scripts) au lieu de les retélécharger à chaque page. Sur WordPress, il s'active par une extension ; sur la plupart des hébergements, par un réglage. Un cache côté serveur évite en plus de reconstruire la page à chaque visite, ce qui aide aussi Googlebot à explorer plus de pages dans le même temps (le budget de crawl).
5. L'hébergement#
Un hébergement mutualisé d'entrée de gamme répond lentement, surtout aux heures chargées. Le temps de réponse du serveur, visible dans PageSpeed Insights, devrait rester bien en dessous d'une seconde. Si ce n'est pas le cas, l'offre supérieure de votre hébergeur ou un réseau de diffusion de contenu (CDN) règle souvent le problème.
6. Le HTML trop lourd#
Une page qui embarque des centaines de blocs, des menus géants, des carrousels de dizaines d'éléments ou des sections dupliquées met du temps à être analysée et affichée. Simplifiez : une page d'accueil n'a pas besoin de tout dire. Nous avons nous-mêmes réduit de plus d'un tiers le poids de notre page d'accueil en septembre 2026 en allégeant un mur d'avis qui répétait trois fois la même liste.
7. Le CSS bloquant#
Les feuilles de style se chargent avant l'affichage. Un thème qui charge la totalité de son CSS sur chaque page, plus celui de dix extensions, retarde le premier affichage. Les extensions d'optimisation savent générer le CSS critique et différer le reste.
8. Le chargement différé#
Les images et les vidéos situées sous la ligne de flottaison n'ont pas besoin d'être chargées tout de suite : l'attribut de chargement différé (lazy loading) les fait attendre que le visiteur s'en approche. Attention à ne pas l'appliquer à l'image principale de la page, qui doit au contraire être chargée en priorité.
9. Les dimensions des médias#
Pour éviter les sauts de mise en page (CLS), chaque image, vidéo, iframe ou bandeau doit avoir une largeur et une hauteur déclarées, afin que le navigateur réserve la place avant le chargement. Même chose pour les polices : un texte qui change de taille quand la police arrive fait bouger toute la page.
10. Le thème#
Certains thèmes, surtout les thèmes « tout-en-un » vendus avec des dizaines de démonstrations, chargent l'intégralité de leurs fonctions sur chaque page. Si après les neuf corrections précédentes le site reste lent, le thème est probablement la cause. Un thème léger, ou une configuration qui désactive les modules inutilisés, change tout.
Le cas WordPress et le cas Shopify#
Les deux plateformes les plus répandues chez les TPE ont chacune leurs pièges.
WordPress cumule souvent un thème lourd, des extensions redondantes et un hébergement sous-dimensionné. Les corrections passent par une extension de cache et d'optimisation, la conversion des images, le tri des extensions et le choix d'un hébergement adapté. Nous avons détaillé chaque point dans notre audit SEO WordPress.
Shopify gère l'hébergement et le cache, ce qui règle une partie du problème. Le poids vient alors du thème et surtout des applications installées, dont chacune ajoute son script sur toutes les pages. L'inventaire des applications et des images produits est la priorité, comme l'explique notre audit SEO Shopify.
Ce que les Core Web Vitals changent vraiment pour votre classement#
Il faut être précis sur ce point, parce que le sujet est souvent exagéré dans un sens ou dans l'autre.
Google a confirmé que l'expérience de page, dont les Core Web Vitals font partie, est un signal de classement. Mais c'est un signal parmi beaucoup d'autres, et il ne l'emporte jamais sur la pertinence du contenu. Une page lente qui répond exactement à la recherche restera devant une page rapide qui n'y répond pas. Dans une comparaison entre deux pages de qualité proche, la vitesse peut faire la différence, sans qu'il soit possible de chiffrer cet effet.
Ce qui est certain, en revanche, c'est l'effet sur les visiteurs. Une page qui met plusieurs secondes à s'afficher sur mobile perd une partie de son audience avant même d'avoir été lue, et un formulaire qui réagit avec retard fait abandonner des demandes de contact. Les Core Web Vitals méritent votre attention d'abord pour cette raison : ils mesurent ce que vos clients vivent.
Ils font donc partie de tout audit sérieux, à leur juste place : après l'indexation, le contenu et les balises, avant le vernis. Notre méthode d'audit SEO en 12 étapes les traite à la troisième étape, et notre checklist SEO en fait l'un de ses cinquante points.
Conclusion#
Trois mesures, des seuils clairs, deux outils gratuits et dix corrections dont les trois premières règlent l'essentiel : les Core Web Vitals n'ont rien d'inaccessible pour une petite entreprise. Commencez par les images, les scripts tiers et les polices, mesurez avant et après, et ne courez pas après un score de laboratoire parfait si vos visiteurs réels sont déjà bien servis.
Pour situer la performance de votre site parmi les autres points qui comptent, lancez notre audit SEO gratuit : score sur 100 et corrections priorisées en deux minutes. Et si vous préférez confier le sujet à une équipe, notre agence SEO prend en charge la technique, les contenus et les liens avec un conseiller dédié : essayez Get Ranking gratuitement.
