Les Core Web Vitals, en clair

01Les Core Web Vitals, qu’est-ce que c’est ?

On parle souvent de « vitesse du site ». C’est flou. Rapide pour qui ? Sur quel téléphone ? Avec quelle connexion ? Les Core Web Vitals transforment ces sensations en chiffres.

Google en a retenu trois. Chacun répond à une frustration précise que tout le monde a vécue au moins une fois cette semaine.

• « Ça charge ou pas ? » C’est le LCP.
• « J’ai cliqué, il se passe quoi ? » C’est l’INP.
• « Pourquoi tout a bougé ? » C’est le CLS.

Ils font partie du SEO technique, aux côtés du crawl et de l’indexation. Mais ils parlent d’abord de vos visiteurs, avant de parler de Google.

02LCP, INP, CLS, que mesure chaque indicateur ?

Selon la documentation web.dev de Google, une bonne expérience correspond à trois seuils. Ils s’évaluent séparément sur mobile et sur ordinateur.

L’INP est devenu un Core Web Vital stable en 2024. Il a remplacé le FID, qui ne mesurait que la première interaction. L’INP, lui, regarde toute la visite.

Autrement dit, plus moyen de cacher une page poussive derrière un premier clic rapide.

03Pourquoi Google juge au 75e percentile

Une page n’a pas un temps de chargement unique. Il varie selon l’appareil, la connexion, le lieu, l’heure.

Évaluer au 75e percentile, c’est exiger qu’au moins trois visites sur quatre atteignent le seuil. Pas la moyenne. Pas le meilleur cas.

On juge donc la page sur l’expérience de la grande majorité. Y compris le visiteur avec un téléphone de quatre ans et deux barres de réseau dans le TER.

04Terrain ou laboratoire, quelles données croire ?

Deux familles de mesures coexistent. Les confondre, c’est la première source d’erreur que je rencontre.

Les données de terrain

Elles viennent des visites réelles d’utilisateurs de Chrome. Dans la Search Console, chaque groupe de pages est évalué sur les 28 derniers jours.

Ce sont elles qui servent à évaluer la page. Mais elles n’existent que si la page reçoit assez de trafic.

Les données de laboratoire

Elles viennent d’un test simulé, sur un appareil et une connexion choisis. Disponibles tout de suite, elles servent à diagnostiquer et à vérifier une correction.

Le score sur 100 affiché par les outils de test ? Une note de laboratoire. Pas un Core Web Vital.

L’INP, en particulier, ne se mesure vraiment qu’avec de vraies interactions. En labo, on utilise un indicateur approchant : le temps de blocage total.

05Où consulter ses Core Web Vitals ?

Google recommande d’obtenir de bons Core Web Vitals. Selon lui, cela correspond à ce que ses principaux systèmes de classement cherchent à récompenser.

• Le rapport Core Web Vitals de la Search Console : vos URL regroupées en pages similaires, classées « bonnes », « à améliorer » ou « médiocres »
• PageSpeed Insights : pour une URL, les données de terrain quand elles existent, puis un diagnostic de laboratoire
• Les outils de développement du navigateur : pour disséquer ce qui ralentit une page

Le rapport de la Search Console est mon point de départ. Il dit où agir. PageSpeed Insights dit ensuite quoi faire, page par page.

Quand vous validez une correction dans la Search Console, une période de suivi de 28 jours s’ouvre. Pas la peine de rafraîchir le rapport toutes les heures.

06Comment améliorer le LCP ?

• Alléger l’image principale. La cause numéro un. Redimensionnez à la taille affichée, passez en WebP ou AVIF, compressez.
• Ne pas différer l’élément du haut. Le chargement différé, c’est pour le bas de page. L’image de tête se charge en priorité.
• Accélérer le serveur. Hébergement sous-dimensionné, pas de cache, base encombrée : tout le reste attend.
• Réduire les ressources bloquantes. Styles et scripts en tête de page retardent l’affichage. Gardez l’essentiel pour le haut.

Le temps de réponse du serveur est la première brique du LCP. Si elle est bancale, aucune compression d’image ne sauvera la page. Mon guide sur l’hébergeur de site web aide à choisir.

Une photo de couverture téléversée telle qu’elle sort de l’appareil, je la croise encore régulièrement. C’est le gain le plus facile de tout le guide.

07Comment améliorer l’INP ?

L’INP souffre presque toujours du même mal : trop de JavaScript qui occupe le navigateur au moment où le visiteur veut agir.

• Réduire le JavaScript. Carrousel, chat, widget social, suivi publicitaire : faites l’inventaire et retirez l’inutile.
• Limiter les scripts tiers. Outils d’analyse en double, pixels, cartes intégrées : seulement sur les pages qui en ont besoin, et plus tard.
• Découper les tâches longues. Côté développement, un traitement lourd se fractionne pour laisser la page répondre.

Chaque outil marketing ajouté « juste pour tester » reste souvent des années. Et chacun grignote la réactivité.

Si votre site repose beaucoup sur les scripts, mon guide du SEO JavaScript complète celui-ci.

08Comment améliorer le CLS ?

• Donner des dimensions aux images et vidéos. Largeur et hauteur déclarées, le navigateur réserve la place.
• Réserver l’espace des éléments insérés. Bandeaux, publicités, recommandations : prévoyez leur emplacement.
• Gérer les polices. Préchargez les polices principales, choisissez des polices de secours de taille proche.
• Afficher les bandeaux en surimpression. Le bandeau cookies ou une promo ne doivent pas pousser la page.

Le bandeau de consentement est un coupable fréquent. Il apparaît en haut, pousse tout vers le bas, et le visiteur clique sur la mauvaise chose. Voyez mon guide sur le bandeau cookies.

Le CLS, c’est l’indicateur de la politesse. Une page bien élevée ne bouge pas pendant qu’on lui parle.

Trois indicateurs, trois familles de causes, et presque toujours les mêmes coupables. Une fois qu’on les connaît, on les repère au premier coup d’œil sur n’importe quel rapport.

Le plus dur n’est pas de savoir quoi faire. C’est de résister à l’envie d’ajouter un nouvel outil marketing la semaine suivante, sans retester.

09WordPress, gabarits et méthode de correction

Le rapport de la Search Console regroupe justement les pages similaires. Servez-vous de ces groupes pour prioriser. Le groupe qui pèse le plus de trafic passe en premier.

Le cas WordPress

Sur WordPress, les mauvais scores viennent souvent de l’empilement. Thème lourd, constructeur de pages, des dizaines d’extensions, images téléversées en pleine résolution.

• Une extension de cache bien réglée
• La conversion automatique des images
• La suppression des extensions inutiles
• Le chargement conditionnel des scripts
• Un hébergement adapté au trafic

Les réglages propres au CMS sont détaillés dans mon guide du SEO WordPress. Et l’entretien régulier, dans celui sur la maintenance WordPress.

Ma routine de diagnostic, dans l’ordre

Quand un client m’appelle parce que « le site est lent », je ne commence jamais par les réglages. Je suis toujours le même chemin, du plus large au plus précis.

• Le rapport de la Search Console, pour savoir quels groupes de pages posent problème, et sur quel appareil
• Le groupe le plus visité, choisi en premier, parce qu’il touche le plus de monde
• Une URL type de ce groupe, passée dans PageSpeed Insights
• L’indicateur en rouge, et lui seul, avec sa cause principale
• Une correction sur le gabarit, testée en labo, puis validée dans la Search Console

Cinq étapes, un indicateur à la fois. C’est moins grisant que de tout changer d’un coup, mais au moins on sait ce qui a marché.

Changer dix réglages le même jour, c’est se condamner à ne jamais savoir lequel a payé. Ou lequel a tout cassé.

Qui fait quoi ?

Certaines corrections sont à votre portée : compresser les images, retirer une extension, déplacer un bandeau. D’autres demandent un développeur, comme découper des tâches JavaScript longues.

Identifiez les deux listes dès le diagnostic. Vous gagnerez des semaines d’allers-retours.

10Quel poids réel sur votre référencement ?

Les Core Web Vitals sont un signal parmi d’autres. Une page lente qui répond parfaitement à une recherche peut rester bien classée. Une page rapide et creuse, non.

Leur effet se voit surtout quand plusieurs pages se valent sur le fond. Mais leur bénéfice le plus direct est ailleurs : une page rapide garde mieux ses visiteurs et les convertit mieux.

C’est une raison suffisante pour s’en occuper, classement ou pas. Ça rejoint tout le travail d’optimisation du taux de conversion.

Et les IA ? Leurs robots lisent les pages pour construire leurs réponses. Ils profitent aussi d’un site léger, même si les Core Web Vitals mesurent l’expérience humaine.

Les erreurs que je vois le plus

• Courir après le 100. Note de labo. Le terrain compte.
• Tester sur ordinateur seulement. Le gros des problèmes est sur mobile.
• Corriger page par page. Les causes sont dans les gabarits et les extensions.
• Attendre un effet immédiat. 28 jours de données, plusieurs semaines de patience.
• Ajouter des outils sans mesurer. Chaque script peut dégrader l’INP.

Photo redimensionnée en WebP, module chargé plus tard avec un emplacement réservé, bandeau en surimpression. Quatre semaines plus tard, les groupes passent en « bonnes ». Cas inventé pour l’illustration.