Core Web Vitals : ce qui fait réellement bouger LCP, INP et CLS

Les Core Web Vitals sont évalués sur ce qu'ont vécu les vrais visiteurs, agrégé au 75e centile sur vingt-huit jours, et rapporté via le Chrome User Experience Report. Le rapport Core Web Vitals de la Search Console reprend ces données groupées par motif d'URL, ce qui en fait le bon point de départ. Les outils de laboratoire comme Lighthouse simulent un chargement, depuis un lieu, sur un profil bridé — précieux pour le diagnostic, inutile comme verdict.

L'écart entre les deux surprend régulièrement les équipes. Une page notée 95 en laboratoire peut se trouver dans la catégorie « médiocre » sur le terrain, parce que les vrais visiteurs sont sur des téléphones de milieu de gamme, en réseau mobile, avec un bandeau de cookies, trois conteneurs de gestion de balises et un widget de chat que le développeur a désactivé localement il y a des mois. Quand laboratoire et terrain divergent, le terrain est ce qu'ont vécu vos clients et ce qu'utilise Google.

Travaillez par gabarit plutôt que par URL. Le rapport terrain groupe les pages similaires précisément parce qu'une URL isolée a rarement assez de trafic pour un centile fiable. Corriger le gabarit produit fait bouger des milliers de pages ; optimiser une page d'accueil en fait bouger une, et ce n'est presque jamais la page d'accueil qui échoue.

Le Largest Contentful Paint mesure le moment où le contenu principal devient visible ; sous 2,5 secondes, c'est bon. Il se décompose en quatre parties, et savoir laquelle domine fait gagner des semaines : temps jusqu'au premier octet, délai avant chargement de la ressource, durée de chargement, délai de rendu. Une page au serveur lent a un problème de TTFB qu'aucune optimisation d'image ne corrigera ; une page au serveur rapide avec un LCP de 4 secondes est en général bloquée par le CSS, les polices ou une image d'en-tête que personne n'a priorisée.

Les correctifs les plus fiablement rentables : servir l'image LCP dans un format moderne à la taille réellement affichée, la précharger, retirer les scripts bloquants de l'en-tête, et s'assurer que les polices ne retiennent pas le texte en otage. Sur les sites rendus côté serveur, la mise en cache en périphérie divise fréquemment le TTFB par deux pour une fraction du coût de n'importe quel travail front-end.

L'erreur structurelle la plus fréquente consiste à charger l'élément LCP en lazy loading. Une image d'en-tête marquée `loading="lazy"` est différée par le navigateur après la mise en page, exactement l'inverse de l'effet recherché : le lazy loading appartient sous la ligne de flottaison, jamais au-dessus.

L'Interaction to Next Paint a remplacé le First Input Delay en mars 2024, et c'est une mesure bien plus sévère : là où son prédécesseur ne regardait que la première interaction, l'INP retient la pire de toute la visite. Sous 200 millisecondes, c'est bon. C'est presque toujours un problème de JavaScript — tâches longues bloquant le fil principal, gestionnaires d'événements surdimensionnés, hydratation de composants jamais atteints.

Ce qui rend l'INP organisationnellement difficile, c'est que les scripts fautifs n'appartiennent souvent pas à l'ingénierie. Plateformes de gestion du consentement, gestionnaires de balises, analytics, enregistrement de session, widgets de chat et outils de test A/B se disputent le même fil principal, et chacun a été ajouté par quelqu'un qui ne pensait pas à la latence d'interaction. Un audit d'INP est souvent, en pratique, un audit de balises.

Les correctifs techniques sont bien établis : découper les tâches longues en morceaux pour que le navigateur puisse répondre entre eux, différer tout ce qui n'est pas nécessaire à la première interaction, et charger les scripts tiers après l'interactivité plutôt qu'avant. Sur beaucoup de sites, le principal gain d'INP consiste à supprimer des balises que personne n'a regardées depuis deux ans — gratuit, immédiat, et exigeant seulement que quelqu'un accepte de demander qui possède chacune.

Le Cumulative Layout Shift mesure l'ampleur des déplacements inattendus du contenu visible ; sous 0,1, c'est bon. Les causes forment une liste courte et connue : images et iframes sans attributs de largeur et de hauteur, publicités et intégrations injectées au-dessus du contenu existant, polices web qui basculent avec des métriques différentes, et bandeaux de cookies qui poussent la page après le premier affichage.

Chaque cause a le même correctif : réserver l'espace avant l'arrivée du contenu. Fixez des dimensions ou des ratios explicites, donnez aux emplacements publicitaires un conteneur de taille fixe, utilisez des stratégies de chargement de polices qui ne recomposent pas la page, et affichez les bandeaux de consentement en surimpression plutôt qu'en bloc qui déplace le contenu. Rien de difficile ; c'est simplement invisible sur la connexion rapide où travaillent les développeurs, tout se chargeant avant la première image.

Le CLS mérite d'être corrigé même là où il ne dépasse pas le seuil, car c'est la métrique que l'utilisateur ressent le plus directement. Un décalage qui fait glisser un bouton sous le doigt n'est pas un score, c'est une commande passée sur le mauvais produit et un ticket de support. Testez sur un profil mobile bridé et sur les gabarits à fort trafic, pas sur la page d'accueil.

Comme signal de classement, l'expérience de page est réelle et modeste. Google a été constant : elle départage des résultats de pertinence comparable, elle ne promeut pas une page rapide devant une page lente plus utile. Quiconque vend un sprint de performance comme une stratégie de classement survend ; quiconque ignore un site noté médiocre sur ses gabarits principaux laisse de la valeur sur la table.

Le business case est la conversion, et les preuves y sont bien plus solides. Les études publiques — les travaux retail de Deloitte, l'expérience LCP de Vodafone, les cas publiés sur web.dev — retombent régulièrement dans la même fourchette : environ 0,4 à 1,0 pour cent de variation relative de conversion par tranche de 100 millisecondes de LCP, effet maximal sur mobile, sur les parcours longs et sur l'intention transactionnelle. Notre simulateur de ROI Core Web Vitals vous laisse fixer cette élasticité au lieu de la dissimuler dans une constante.

Deux règles de planification en découlent. Les rendements ne sont pas linéaires : faire passer un gabarit de 5 à 3 secondes change visiblement les comportements, passer de 2,2 à 1,9 ne change presque rien pour un coût d'ingénierie souvent supérieur. Et la vérification se fait sur le terrain, vingt-huit jours après le déploiement — pas sur un score de laboratoire relevé le jour de la mise en ligne, qui mesure le portable du développeur plutôt que le téléphone du client.