Core Web Vitals : ce que LCP, CLS et TBT coûtent en conversion, et comment les corriger

Le diagnostic SEO affiche quatre chiffres de performance mobile : LCP, CLS, FCP et TBT. Deux seulement sont des Core Web Vitals, et celui qui mesure la réactivité (INP) n'y figure pas, car il ne se mesure qu'auprès de vrais visiteurs. Je reprends chaque indicateur sur une page de mon site, avec les seuils officiels vérifiés le 9 octobre 2026, les correctifs qui comptent et ce qu'on sait réellement de leur effet sur la conversion.

Les quatre chiffres du diagnostic et les seuils officiels

Les Core Web Vitals selon web.dev sont trois : LCP (affichage du contenu principal), INP (réactivité aux interactions) et CLS (stabilité visuelle). FCP est un indicateur d'appoint, utile pour comprendre un LCP lent. TBT est une mesure de laboratoire : web.dev la présente comme un indicateur de substitution raisonnable pour INP dans les outils de test, tout en précisant qu'elle ne le remplace pas.

Entre les deux colonnes, la valeur est « à améliorer ». Pour les trois Core Web Vitals, web.dev recommande de juger le 75e centile des chargements, séparément sur mobile et sur ordinateur.

J'ai lancé le diagnostic SEO gratuit sur ma page d'expertise CRO. Résultat : 96 sur mobile, 100 sur ordinateur, et pourtant un LCP mobile de 2,9 s, au-dessus du seuil de 2,5 s. Une note verte ne garantit pas que chaque indicateur soit « bon » : lisez les chiffres, pas seulement la note. Le diagnostic n'ouvre d'ailleurs sa fiche de résolution « Performance » qu'en dessous de 90 ; ici, elle reste masquée.

Corriger un LCP lent en partant de l'image principale

Sur ma page CRO, comme sur beaucoup de pages vitrines, l'élément LCP est la photo du haut de page. Le guide d'optimisation du LCP de web.dev découpe ce temps en quatre parts (temps de réponse du serveur, délai avant le téléchargement de l'image, durée du téléchargement, délai de rendu) et donne trois règles prioritaires : rendre l'image visible dès le HTML initial, lui donner une priorité haute, ne jamais la charger en différé.

<!-- Image LCP : découverte immédiate, priorité haute, jamais en lazy-loading -->
<img src="/hero-1200.avif" width="1200" height="675"
     alt="Description utile de l'image"
     fetchpriority="high" decoding="async">
<!-- loading="lazy" est réservé aux images situées sous la ligne de flottaison -->

Ma page coche déjà ces trois cases et reste pourtant autour de 2,7 s dans l'émulation mobile de Lighthouse (réseau d'environ 1,6 Mbit/s, processeur ralenti quatre fois). Le poids n'est pas en cause : l'image fait 13 Ko en WebP. Dans la ventilation de Lighthouse, le poste dominant est le délai avant le début du téléchargement de l'image, et la seule ressource bloquante signalée est la feuille CSS. C'est la piste que je creuse, sans avoir encore isolé la cause.

Stabiliser la mise en page pour faire tomber le CLS

Le CLS, selon web.dev, mesure les décalages inattendus. Causes citées : médias sans dimensions, polices web plus grandes ou plus petites que la police de secours, publicités et widgets qui se redimensionnent, contenu injecté au-dessus de l'existant. Le correctif de base tient en deux gestes : déclarer width et height (ou un aspect-ratio) sur chaque média, et réserver la hauteur des bandeaux (cookies, promotion) avant leur apparition.

Sur un de mes articles de blog, Lighthouse mesure un CLS de 0,008, causé par les boutons de partage qui se décalent légèrement au chargement. C'est très loin du seuil de 0,1 : je ne le corrigerai pas en priorité. Savoir ne pas corriger fait partie du diagnostic.

TBT et INP : ce que le laboratoire peut dire de la réactivité

Le TBT additionne, pour chaque tâche de plus de 50 ms sur le fil principal, la part qui dépasse 50 ms. En pratique, il grimpe avec le JavaScript : frameworks lourds, scripts tiers (chat, tags publicitaires, tests A/B côté client). Le correctif : différer ou supprimer les scripts non essentiels, et découper les longues tâches.

C'est aussi l'indicateur le plus instable. J'ai lancé Lighthouse 13.5.0 cinq fois de suite depuis mon poste sur la même page : 780 ms au premier passage, en rouge, puis entre 23 et 128 ms. Lighthouse classe la plus longue tâche du premier passage comme « non attribuable » ; je soupçonne la charge de ma machine, sans pouvoir le prouver. Une mesure isolée de TBT ne prouve rien : lisez la médiane de plusieurs passages (ici 120 ms).

Données de laboratoire et données terrain : pourquoi elles divergent

Le diagnostic interroge PageSpeed Insights, qui exécute Lighthouse : un appareil, un réseau, un instant. Les données terrain viennent du Chrome UX Report (CrUX), qui agrège l'expérience de vrais utilisateurs de Chrome sur 28 jours. web.dev explique l'écart (cache, diversité des appareils, interactions réelles) et recommande de prioriser avec le terrain, puis de tester ses correctifs en laboratoire.

Limite : CrUX ne couvre que les pages et origines qui ont assez de visiteurs, et je n'ai pas pu obtenir de données terrain pour ces pages le jour de la rédaction. Sur un petit site, le laboratoire reste souvent la seule mesure, à lire en médiane. Pour un état des lieux plus large (poids, requêtes, accessibilité), le scan santé du site complète le diagnostic.

Ce que la vitesse change vraiment à la conversion

Côté Google, la documentation Search Central dit que de bons Core Web Vitals s'alignent avec ce que ses systèmes de classement cherchent à récompenser, sans en faire une garantie de position. Côté conversion, la référence la plus solide que j'aie trouvée est l'étude de cas Vodafone publiée par web.dev en 2021 : un test A/B sur du trafic payant, où la seule différence entre les deux versions était l'optimisation des Web Vitals. LCP amélioré de 31 %, ventes en hausse de 8 %. Trois nuances : la version rapide cumulait plusieurs optimisations (rendu serveur, images, widget), donc le gain ne s'attribue pas au seul LCP ; les deux versions restaient au-dessus de 4 s (8,3 s et 5,7 s), donc l'étude montre qu'aller plus vite vend mieux, pas qu'il existe un effet de seuil à 2,5 s ; et c'est un site, un test.

Je lis donc la performance comme une friction parmi d'autres, au même titre que celles décrites dans pourquoi vos pages produit ne convertissent pas assez. Quand je lis un tunnel de conversion, je la traite quand elle touche les pages qui portent la conversion, et je mesure l'effet d'un correctif plutôt que de le supposer, avec les précautions détaillées dans tests A/B : pourquoi vos résultats ne sont pas toujours significatifs.

Sources : web.dev, Web Vitals ; web.dev, LCP ; web.dev, Optimiser le LCP ; web.dev, CLS ; web.dev, INP ; web.dev, FCP ; Chrome for Developers, Total Blocking Time ; web.dev, données de laboratoire et de terrain ; Chrome UX Report ; Google Search Central, Core Web Vitals ; web.dev, étude de cas Vodafone ; mesures sur ce site (diagnostic SEO et Lighthouse 13.5.0, 9 octobre 2026).

Pour aller plus loin : CRO, c'est quoi ?, A/B testing : et si votre trafic ne suffisait pas ?