Un client ouvre rarement une conversation en posant des questions sur Interaction to Next Paint. Il l’ouvre en disant que le site "paraît lent", ou que celui d’un concurrent "paraît plus réactif", et c’est alors mon travail de transformer cette impression en un chiffre et le chiffre en un correctif. Les Core Web Vitals restent le meilleur vocabulaire public pour cette conversation, et les détails qui valent la peine d’être connus en 2026 ont évolué depuis la dernière modification de l’ensemble des métriques.
Voici la version pratique : ce que mesurent les trois métriques, là où chacune casse réellement sur les sites clients que j’audite, et comment prouver que le correctif a fonctionné au lieu de simplement l’affirmer.
Les trois métriques qui comptent encore
Largest Contentful Paint mesure le temps que met le plus grand élément visible à s’afficher : l’image principale, un titre, la vignette d’une vidéo. En dessous de 2.5 secondes, c’est bon. Interaction to Next Paint mesure le délai entre un appui ou un clic et la mise à jour visuelle suivante, en dessous de 200 millisecondes c’est bon, et elle a remplacé First Input Delay comme métrique de réactivité parce que FID ne mesurait que la première interaction, pas celles qui surviennent après qu’une page a fini de charger et est devenue lente. Cumulative Layout Shift mesure à quel point le contenu visible saute de façon inattendue, en dessous de 0.1 c’est bon.
Les trois sont en réussite ou en échec au 75e centile des visites réelles, pas une moyenne ni un score de laboratoire. Un site rapide pour la plupart des visiteurs et catastrophique pour un sur cinq sur une connexion bridée échoue quand même à la métrique, parce que le seuil est délibérément fixé pour refléter une visite réaliste et plus lente, pas un ordinateur portable haut de gamme sur la fibre.
Là où LCP casse réellement
Sur les sites que j’audite, ce n’est presque jamais le framework. C’est une image principale non optimisée servie à quatre fois la taille d’affichage, une police web qui bloque le rendu du texte parce qu’elle n’a pas été préchargée, ou un script tiers — un widget de chat, une balise d’analytics, un pixel marketing — chargé de façon synchrone avant le contenu qu’il est censé mesurer.
Le correctif est rarement spectaculaire : servez l’image principale à la taille à laquelle elle s’affiche, dans un format moderne, avec une priorité de chargement élevée et sans chargement différé sur la seule image assurée d’être au-dessus de la ligne de flottaison ; préchargez le fichier de la police au lieu de laisser le navigateur la découvrir après avoir analysé le CSS ; et chargez tous les scripts tiers de façon asynchrone, un point c’est tout, sauf s’ils ont une raison précise de bloquer.
INP est un problème de JavaScript
Là où LCP est surtout un problème de chargement, INP est presque entièrement un problème de thread principal : une tâche longue qui empêche le navigateur de répondre à un appui, généralement causée par trop de JavaScript qui s’exécute, s’hydrate ou se re-rend en même temps. Un seul composant qui re-rend une longue liste entière à chaque frappe échouera à INP même sur une connexion rapide, parce que le délai n’a rien à voir avec le réseau.
Le correctif qui a le plus compté sur les projets React et Next.js cette année, c’est de choisir délibérément ce qui doit réellement être un composant client par rapport à ce qui peut rester rendu côté serveur, et de découper les gros bundles client pour qu’une interaction sur une partie de la page n’attende pas que le JavaScript d’une partie sans rapport finisse de s’exécuter. Appliquer un debounce aux gestionnaires coûteux et virtualiser les longues listes valent toujours la peine.
CLS : le correctif bon marché que personne ne se donne la peine de faire
Le décalage de mise en page est généralement causé par les trois mêmes choses : une image ou une vidéo intégrée sans largeur ni hauteur réservées, une police web qui s’affiche avec une largeur nettement différente de celle de la police de repli qu’elle remplace, et du contenu — généralement un emplacement publicitaire, une bannière de cookies ou une barre promotionnelle — injecté au-dessus du contenu existant après que la page a déjà été mise en page.
Les trois ont un correctif qui ne coûte presque rien : fixez des dimensions explicites sur chaque image et chaque élément intégré, choisissez une police de repli métriquement proche de la police web (ou acceptez un bref clignotement plutôt qu’un décalage), et réservez de l’espace pour tout ce qui s’injecte tardivement au lieu de le laisser pousser vers le bas tout ce qui se trouve en dessous.
Bien le mesurer
Un score Lighthouse dans les outils de développement, ce sont des données de laboratoire : une seule exécution, sur une seule machine, sur une connexion rapide, utile pour diagnostiquer la cause d’un problème. Ce n’est pas le chiffre sur lequel Google juge réellement la page, qui provient du Chrome User Experience Report : des visites réelles, des appareils réels, des réseaux réels, agrégés sur 28 jours. Une page peut obtenir 100 dans Lighthouse et échouer malgré tout à ses Core Web Vitals sur le terrain si assez de visiteurs réels sont sur un téléphone de milieu de gamme avec une 4G capricieuse.
Le rapport Core Web Vitals de la Search Console et PageSpeed Insights font tous deux remonter les données de terrain dès qu’un site a assez de trafic pour être éligible. Pour un site client plus petit qui n’a pas atteint le seuil de trafic de CrUX, je suis les trois mêmes métriques via un script léger dans le navigateur lui-même, envoyé à l’analytics, afin que le client obtienne de vrais chiffres plutôt qu’une estimation de laboratoire qui en tienne lieu.
Pourquoi cela conclut encore des contrats
La plupart des clients potentiels ne savent pas lire un rapport Lighthouse, et ils n’en ont pas besoin : ils peuvent ressentir un site qui répond instantanément à un appui face à un autre avec une fraction de seconde de latence, et ils remarquent que la page d’un concurrent se charge avant que la leur ait terminé son décalage de mise en page. La performance est l’une des rares pièces d’artisanat directement perceptible sans aucun vocabulaire de design, ce qui la rend exceptionnellement persuasive dans un pitch.
Elle se cumule aussi avec le reste du site : une page magnifiquement conçue qui saccade au premier chargement passe pour inachevée, et une page sobre qui répond instantanément passe pour soignée. La vitesse n’est pas séparée du travail de design, elle fait partie de ce sur quoi le design est jugé au moment où un vrai visiteur l’ouvre.
