Comment améliorer les Core Web Vitals de son site ?

Les Core Web Vitals sont les trois indicateurs par lesquels Google mesure l’expérience vécue par les visiteurs d’une page : la vitesse d’affichage du contenu principal, la réactivité aux interactions et la stabilité visuelle. Ils parlent un jargon un peu abscons (LCP, INP, CLS), mais traduisent des sensations très concrètes : une page qui tarde, un bouton qui ne répond pas, un texte qui saute au moment où l’on veut cliquer. Chez Netamorphoz, nous les abordons comme un chantier de qualité plutôt que comme une course au score. Voici ce que mesurent ces indicateurs, les seuils à viser, les outils fiables pour les suivre et les corrections qui produisent réellement des effets.

Que mesurent vraiment les Core Web Vitals ?

Google a présenté les Core Web Vitals en 2020 pour donner aux propriétaires de sites un petit nombre de mesures communes de l’expérience utilisateur, applicables à toutes les pages. Ils sont aujourd’hui au nombre de trois. Le LCP (Largest Contentful Paint) mesure le temps nécessaire pour afficher le plus grand élément visible dans la fenêtre au chargement, souvent une image principale ou un bloc de titre. L’INP (Interaction to Next Paint) mesure le délai entre une interaction (clic, toucher, touche du clavier) et la mise à jour visuelle qui suit. Le CLS (Cumulative Layout Shift) mesure l’ampleur des décalages inattendus de mise en page. Ces signaux font partie de ce que Google appelle l’expérience sur la page, prise en compte par ses systèmes de classement, et c’est à ce titre qu’ils intéressent le référencement SEO. Mais ils mesurent d’abord la qualité ressentie par vos visiteurs, ce qui suffit à justifier qu’on s’y intéresse.

Il faut néanmoins remettre ces indicateurs à leur juste place. La documentation de Google Search Central est claire : une bonne expérience sur la page ne remplace pas un contenu pertinent, et une page très utile peut bien se classer malgré des indicateurs moyens. Les Core Web Vitals jouent plutôt comme un critère de départage entre des pages de pertinence comparable, et comme un facteur de conversion : un visiteur qui attend ou qui clique au mauvais endroit à cause d’un décalage a plus de chances de repartir. Autre précision importante : ce que Google prend en compte, ce sont les données de terrain collectées auprès de vrais utilisateurs de Chrome, et non le score obtenu une fois dans un outil de test. Les données sont agrégées sur une période glissante de 28 jours, ce qui explique qu’une correction ne se traduise pas immédiatement dans les rapports. Enfin, depuis le 12 mars 2024, l’INP a officiellement remplacé le FID (First Input Delay), un indicateur de réactivité jugé trop indulgent car il ne mesurait que le délai de la toute première interaction.

Quels sont les seuils à atteindre pour LCP, INP et CLS ?

Google publie, sur le site web.dev et dans la documentation Search Central, des seuils qui classent chaque indicateur en trois catégories : bon, à améliorer et médiocre. Pour qu’une page ou un groupe de pages soit jugé satisfaisant, il faut que le seuil « bon » soit respecté pour au moins 75 % des visites, mesurées séparément sur mobile et sur ordinateur. Ce choix du 75e percentile a une conséquence pratique majeure : il ne suffit pas que la page soit rapide sur votre ordinateur de bureau relié à la fibre, il faut qu’elle le soit aussi pour une large majorité de visiteurs, y compris ceux qui consultent votre site sur un téléphone d’entrée de gamme avec une connexion mobile moyenne, au fond d’un entrepôt ou dans un train. Le tableau ci-dessous récapitule les seuils officiels, à garder en tête comme objectifs de référence pour chaque type de page.

Ces seuils appellent quelques remarques. Le CLS n’a pas d’unité : c’est un score calculé à partir de la surface de la fenêtre touchée par un décalage et de la distance parcourue par les éléments, cumulé par fenêtres de session (des rafales de décalages rapprochés, dans une limite de cinq secondes), et c’est la pire de ces fenêtres qui est retenue. Les décalages qui surviennent juste après une action de l’utilisateur, comme l’ouverture d’un menu qu’il vient de toucher, ne sont pas comptés, car ils sont attendus. L’INP, lui, observe l’ensemble des interactions de la visite et retient l’une des plus lentes, en écartant les valeurs aberrantes sur les pages très interactives. Il est donc plus exigeant que l’ancien FID, et de nombreux sites qui passaient au vert ont découvert des problèmes de réactivité lors du changement. Enfin, Google évalue souvent des groupes d’URL similaires : un modèle de page lent peut pénaliser des dizaines de pages à la fois, ce qui oriente vers des corrections au niveau des gabarits.

Avec quels outils mesurer vos Core Web Vitals ?

Deux familles de mesures coexistent et se complètent. Les données de terrain, issues de vrais visiteurs, proviennent du Chrome User Experience Report (CrUX), qui agrège anonymement les mesures des utilisateurs de Chrome ayant accepté de partager leurs statistiques. Ce sont elles que Google utilise. Les données de laboratoire, elles, sont produites par un outil qui charge la page dans des conditions simulées et reproductibles, comme Lighthouse. Elles sont précieuses pour diagnostiquer et tester une correction avant publication, mais elles ne reflètent pas la diversité réelle des appareils et des connexions. Lighthouse ne peut d’ailleurs pas mesurer l’INP, faute d’interaction réelle : il fournit à la place le TBT (Total Blocking Time), un indicateur voisin qui signale le temps pendant lequel le navigateur est bloqué par des scripts. Un site peu visité n’a parfois pas assez de trafic pour figurer dans CrUX : il faut alors s’appuyer sur le laboratoire ou sur une mesure maison auprès de vos propres visiteurs.

Dans la pratique, nous conseillons une routine simple. Commencez par le rapport Signaux Web essentiels de la Google Search Console, qui regroupe vos URL par statut et par problème, et vous indique quels modèles de pages posent difficulté. Utilisez ensuite PageSpeed Insights sur une page représentative de chaque groupe : la partie haute affiche les données de terrain lorsque CrUX en dispose, la partie basse les diagnostics de Lighthouse, avec l’élément identifié comme LCP, les scripts qui bloquent le rendu ou les images mal dimensionnées. Pour aller plus loin, le panneau Performance des outils de développement de Chrome permet d’enregistrer une interaction et de voir précisément quelle tâche ralentit la réponse. Les sites à fort enjeu peuvent intégrer la bibliothèque open source web-vitals, maintenue par l’équipe Chrome, pour collecter les mesures de leurs propres visiteurs et identifier les pages réellement problématiques. Gardez en tête qu’un score Lighthouse de 100 n’est pas un objectif en soi : seuls comptent les seuils de terrain au 75e percentile.

Comment améliorer le LCP de vos pages ?

Le LCP se décompose en quatre temps : le délai de réponse du serveur (le TTFB, Time To First Byte), le délai avant que le navigateur ne commence à télécharger la ressource principale, la durée de ce téléchargement, puis le délai de rendu de l’élément. Identifier lequel de ces temps domine évite de s’acharner au mauvais endroit. Un serveur lent ou un site sans cache se corrige par un hébergement adapté, une mise en cache des pages et, si votre audience est dispersée, un réseau de diffusion de contenu. Une image principale découverte tardivement, parce qu’elle est chargée en arrière-plan CSS ou injectée par JavaScript, gagne à être déclarée directement dans le HTML et signalée comme prioritaire. Erreur fréquente : appliquer le chargement différé (lazy loading) à toutes les images, y compris celle du haut de page, ce qui retarde précisément l’élément que Google mesure. Le code ci-dessous illustre les bons réflexes sur un visuel de haut de page et sur une image plus bas dans la page.

<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">

<img src="/img/hero.webp" width="1200" height="800"
     fetchpriority="high" alt="Atelier de menuiserie">

<img src="/img/chantier.webp" width="800" height="600"
     loading="lazy" alt="Escalier posé">

Le poids des fichiers reste un levier majeur. Une photo de 4 Mo sortie d’un appareil photo et réduite par le navigateur au tiers de sa taille fait télécharger un fichier démesuré : redimensionnez vos images à la taille d’affichage réelle, proposez plusieurs tailles avec l’attribut srcset et utilisez des formats modernes comme WebP ou AVIF, largement pris en charge par les navigateurs actuels. Les polices web peuvent aussi retarder l’affichage d’un titre : limitez le nombre de graisses, hébergez les fichiers sur votre domaine et utilisez la propriété font-display pour que le texte s’affiche immédiatement avec une police de secours. Les feuilles de style et scripts qui bloquent le rendu doivent être allégés, différés ou chargés de façon asynchrone lorsqu’ils ne sont pas indispensables à l’affichage initial. Pensez aussi aux ressources externes appelées dès le haut de page, comme une carte interactive ou une vidéo intégrée : une image de remplacement cliquable, qui ne charge le lecteur qu’à la demande, allège considérablement l’affichage initial. Sur un site WordPress, une accumulation d’extensions et un thème trop lourd sont souvent la cause racine d’un LCP médiocre, et aucune extension d’optimisation ne compensera durablement un socle technique surchargé.

Comment corriger l’INP et le CLS ?

Un mauvais INP vient presque toujours d’un fil d’exécution principal du navigateur trop occupé. Quand un visiteur touche un bouton, le navigateur doit d’abord terminer la tâche en cours (délai d’entrée), puis exécuter le code associé à l’interaction (traitement), et enfin recalculer et dessiner la page (délai de présentation). Des scripts tiers nombreux (outils de suivi, widgets de discussion, publicités, vidéos intégrées), des bibliothèques JavaScript volumineuses ou des gestionnaires d’événements qui font trop de travail d’un coup allongent chacune de ces phases. Les remèdes consistent à réduire le JavaScript chargé sur chaque page, à supprimer les scripts tiers qui n’apportent plus de valeur, à découper les longues tâches en morceaux pour rendre la main au navigateur entre deux traitements, et à afficher immédiatement un retour visuel (un bouton qui change d’état) avant d’effectuer les calculs lourds. Les pages de filtres en e-commerce, les menus complexes et les formulaires dynamiques sont les zones à surveiller en priorité.

Le CLS se corrige souvent plus facilement, car ses causes sont bien identifiées. La première est l’absence de dimensions sur les images, les vidéos et les cadres intégrés : sans attributs width et height, ou sans ratio défini en CSS, le navigateur ne réserve pas la place et décale le texte quand le média arrive. La deuxième concerne les contenus injectés au-dessus de l’existant après le chargement : bandeaux promotionnels, bannières de consentement mal intégrées, encarts publicitaires sans emplacement réservé. La troisième tient aux polices web, dont le remplacement peut modifier la largeur des lignes : choisir une police de secours aux métriques proches et précharger les fichiers essentiels limite l’effet. Les animations, enfin, doivent utiliser les propriétés transform et opacity plutôt que de modifier la position ou la taille des éléments. Une règle simple résume l’essentiel : tout élément qui apparaîtra doit avoir sa place réservée dès le départ, pour que la page garde une mise en page stable du premier au dernier affichage.

Par où commencer pour améliorer les Core Web Vitals de son site ?

Face à une liste de diagnostics parfois longue, la tentation est de tout corriger d’un coup ou, à l’inverse, de baisser les bras. Une démarche par priorités donne de meilleurs résultats. Partez des données de terrain pour savoir quel indicateur pose problème, sur quels modèles de pages et sur quel type d’appareil : un site dont seul l’INP sur mobile est médiocre n’a pas besoin du même chantier qu’un site dont le LCP est mauvais partout. Concentrez-vous ensuite sur les gabarits les plus visités ou les plus stratégiques (accueil, pages de services, fiches produits) plutôt que sur des pages isolées. Corrigez, vérifiez en laboratoire, publiez, puis patientez le temps que les données de terrain se renouvellent sur leur fenêtre de 28 jours avant de juger l’effet réel. Pour un nouveau site ou une refonte, l’idéal reste d’intégrer ces exigences dès la conception : choix d’un thème sobre, images optimisées dès l’intégration et budget de performance partagé avec le prestataire.

1. Lire le terrainRapport Search Console et données CrUX : quel indicateur, quels gabarits.
2. DiagnostiquerPageSpeed Insights et DevTools sur une page type de chaque groupe.
3. Corriger le gabaritImages, scripts, polices, espaces réservés, cache serveur.
4. ValiderTest en laboratoire, puis validation dans la Search Console.
5. SurveillerContrôle mensuel et test avant chaque nouvel outil tiers.

Gardez enfin une vision d’ensemble de la qualité technique de votre site. Les Core Web Vitals évoluent d’ailleurs eux-mêmes : Google a déjà remplacé un indicateur et peut faire évoluer les définitions ou les seuils, ce qui plaide pour suivre la documentation officielle plutôt que des recettes figées trouvées sur des forums. Les bonnes pratiques de fond (pages légères, médias maîtrisés, scripts limités au nécessaire) restent en revanche valables quelles que soient les mesures retenues. Les Core Web Vitals ne sont qu’une facette de l’expérience utilisateur : un site rapide mais confus, mal structuré ou difficile à lire ne convaincra ni les visiteurs ni les moteurs. La même logique s’applique à la nouvelle génération de lecteurs que sont les assistants d’IA, qui apprécient les pages légères, accessibles sans exécution complexe de JavaScript et dont le contenu principal ressort clairement. C’est pourquoi nous traitons la performance comme une partie d’un tout, avec la structure des contenus, les données structurées et la lisibilité pour les machines, un sujet sur lequel certaines propositions récentes cherchent à aller plus loin, comme le fichier llms.txt, dont nous avons détaillé l’intérêt réel et les limites.