Core Web Vitals : ce

que Google mesure, et

comment on le corrige

Ce que chaque mesure décrit, et pourquoi ces trois-là

Le LCP (Largest Contentful Paint) mesure le délai entre le début du chargement et l'affichage du plus grand bloc de contenu visible dans la fenêtre. C'est presque toujours une image de bandeau ou un gros titre. Google situe le seuil de qualité à 2,5 secondes et considère l'expérience comme mauvaise au-delà de 4 secondes. Ce n'est pas le temps de chargement complet de la page : c'est le moment où le visiteur voit enfin quelque chose qui ressemble à ce qu'il attendait.

L'INP (Interaction to Next Paint) a remplacé le FID en mars 2024. Il mesure le délai entre une interaction — clic, appui, frappe — et la mise à jour visuelle qui en découle, en retenant les pires interactions de la visite plutôt qu'une moyenne. Google place le seuil de qualité à 200 millisecondes, le seuil de mauvaise expérience à 500. Un site peut s'afficher vite et rester désagréable à utiliser : c'est ce que l'INP attrape.

Le CLS (Cumulative Layout Shift) additionne les déplacements de contenu que l'utilisateur n'a pas provoqués. Google fixe le seuil de qualité à 0,1 et le seuil de mauvaise expérience à 0,25. Ce n'est pas une mesure de vitesse mais une mesure d'agacement : le bouton qui se décale au moment précis où le doigt arrive dessus.

Ces trois-là couvrent trois moments distincts de la visite — voir, agir, et ne pas être trahi par la page. Un indicateur unique de « vitesse » en aurait laissé deux sur trois passer sans bruit.

Lighthouse ne mesure pas ce que Google regarde

Deux sources de données coexistent et on les confond en permanence. Lighthouse simule un chargement en laboratoire : une machine, une connexion bridée, une visite. Les données que Google utilise viennent du terrain, via le Chrome User Experience Report — les visites réelles des utilisateurs Chrome ayant activé le partage.

Google évalue ces mesures au 75e percentile des chargements, sur une fenêtre glissante de vingt-huit jours. Trois visites sur quatre doivent donc passer sous le seuil. Votre propre connexion en fibre, devant un écran de développeur, ne compte pour rien dans ce calcul.

Viser le 100 sur Lighthouse est un mauvais objectif, et c'est pourtant ce qu'on demande le plus souvent. Le laboratoire ignore votre bandeau de cookies, votre script de test A/B, et l'utilisateur en 4G dans un train. Un site noté 98 en laboratoire peut être classé « mauvais » sur le terrain, et l'inverse arrive aussi.

La répartition utile est simple : le laboratoire sert au diagnostic, le terrain sert au verdict. Le premier dit pourquoi, le second dit si. Conséquence à anticiper : la fenêtre du terrain étant de vingt-huit jours, une correction déployée aujourd'hui ne se lit pleinement que le mois suivant. Prévoyez ce délai avant de conclure qu'un correctif n'a rien changé.

LCP : la cause est presque toujours en amont du rendu

Quatre causes reviennent, dans cet ordre de fréquence. Le serveur répond lentement. La chaîne de requêtes retarde la découverte de l'image. L'image elle-même est trop lourde ou dans un mauvais format. Enfin, des ressources bloquantes retardent le premier rendu.

Le cas le plus courant tient en une phrase : l'image du bandeau n'est découverte par le navigateur qu'après l'analyse du CSS et le montage d'un composant JavaScript. Le navigateur ne peut pas télécharger ce qu'il n'a pas encore vu. Écrire cette image directement dans le HTML, avec un attribut de priorité de chargement, change souvent le LCP plus que n'importe quelle optimisation de poids.

L'erreur inverse est encore plus fréquente : appliquer le chargement différé à toutes les images du site, bandeau compris. C'est un réglage par défaut de beaucoup d'extensions et il retarde précisément l'élément qui sert de mesure. Le chargement différé est fait pour ce qui est hors écran, jamais pour ce qui est visible d'emblée.

Les polices comptent quand l'élément mesuré est un texte. Une police distante qui bloque le rendu décale le LCP de tout son temps de téléchargement. Préchargez le fichier réellement utilisé et laissez le texte s'afficher avec la police de substitution pendant ce temps.

Reste le temps de réponse serveur, qui est un problème d'architecture et non de réglage. Si une page est reconstruite depuis la base à chaque visite alors que son contenu change une fois par semaine, aucune optimisation d'image ne compensera. Mettre en cache le rendu, ou le générer à la publication, traite la cause.

INP : ce qui occupe le fil d'exécution

Le navigateur n'a qu'un fil principal pour exécuter le JavaScript, calculer la mise en page et peindre. Toute tâche qui dépasse une cinquantaine de millisecondes le retient. Une interaction qui arrive pendant ce temps attend son tour, et c'est cette attente que l'INP enregistre.

Trois coupables reviennent. Les scripts tiers ajoutés après la livraison — gestionnaire de balises, messagerie d'assistance, test A/B, empilement d'outils de mesure. L'hydratation complète d'une page dont neuf dixièmes sont statiques. Et les gestionnaires d'événements qui font trop de travail synchrone avant de rendre la main.

Le premier cas mérite qu'on le dise franchement : le site n'est pas lent à cause du code livré, il est lent à cause de ce qui a été branché dessus ensuite. Un gestionnaire de balises qui charge six scripts, chacun posant ses écouteurs, coûte plus cher en INP que tout le reste de la page. L'arbitrage est politique avant d'être technique, et il doit être posé : chaque outil ajouté se paie en réactivité.

Côté correction, le principe est de découper. Une tâche longue se fractionne en morceaux qui rendent la main au navigateur. Le travail non essentiel se reporte après la mise à jour visuelle. Les zones interactives s'hydratent séparément du contenu statique. Et une messagerie d'assistance se charge au premier clic sur son icône, pas au chargement de la page.

Un point de vigilance : l'INP se mesure sur l'ensemble des visites, et une seule page très interactive — un filtre de catalogue, un formulaire long — peut tirer la note de tout le site vers le bas.

CLS : quatre causes, toutes évitables dès la maquette

Les images et vidéos sans dimensions déclarées arrivent en tête. Tant que le navigateur ignore le rapport largeur-hauteur, il ne réserve aucune place et le contenu situé en dessous saute au moment de l'affichage. Déclarer les dimensions ou le rapport d'aspect dans le HTML règle le problème définitivement.

Les polices viennent ensuite. Le texte s'affiche avec la police de substitution, puis bascule sur la police distante dont les proportions diffèrent, et le paragraphe se recompose. Ajuster les métriques de la substitution, ou en choisir une aux proportions proches, supprime le saut.

Troisième cause : le contenu injecté au-dessus de l'existant. Bandeau de cookies, barre promotionnelle, message d'alerte. Soit il se superpose à la page, soit sa place est réservée d'avance — il ne pousse jamais le contenu vers le bas après coup.

Quatrième cause : tout ce qui arrive en retard. Contenus embarqués, publicités, blocs de recommandation. Leur réserver une hauteur minimale, même approximative, vaut mieux que de les laisser s'insérer dans un flux déjà lu.

Le CLS est la moins chère des trois à corriger et la plus négligée, pour une raison simple : sur une machine rapide avec les polices en cache, il est invisible. Il faut le cache vide et le réseau bridé pour le voir.

Dans quel ordre corriger, et ce que ça ne fera pas

Commencez par lire le terrain, pas le laboratoire. Le rapport Core Web Vitals de Search Console regroupe les URL par gabarit ; un site en a rarement plus de cinq ou six. On ne corrige pas une page, on corrige un gabarit, en commençant par celui qui porte le plus de visites.

Arrêtez-vous quand la mesure est dans le vert. Faire passer un LCP de 2,4 à 1,8 seconde ne rapporte rien dans la grille que Google publie, et ce temps serait mieux investi ailleurs. Les seuils sont des seuils, pas une échelle de mérite.

Protégez ensuite le résultat. Sans budget de performance vérifié à chaque déploiement, la prochaine balise marketing effacera six semaines de travail, et personne ne s'en apercevra avant le rapport du mois suivant. C'est le véritable mode d'échec de ces chantiers : non pas l'incapacité à corriger, mais l'incapacité à tenir.

Enfin, une mise au point utile en rendez-vous. Les Core Web Vitals sont un signal parmi beaucoup d'autres dans l'évaluation d'une page. Une page qui ne répond pas à la requête ne se positionnera pas parce qu'elle s'affiche en 1,2 seconde, et une page qui y répond se positionne avec un LCP moyen. Vendre un chantier de performance comme un levier de référencement autonome, c'est promettre ce que la mécanique ne tient pas.

La raison de le faire est ailleurs, et elle se raisonne sans statistique. Chaque visiteur a coûté quelque chose à faire venir : une campagne, un article, du temps. Celui qui abandonne avant d'avoir vu la page fait perdre la totalité de cette dépense, et il le fait silencieusement — il n'apparaît ni dans vos conversions, ni dans vos formulaires, ni dans vos retours. C'est une fuite qu'on ne voit pas, ce qui la rend facile à laisser durer.