Core Web Vitals : optimiser les performances, le guide qui change tout

Un client m'appelle un mardi matin, un peu paniqué. Son site e-commerce tourne bien, les ventes sont là, mais depuis quelques semaines, le trafic organique décroche doucement. Pas de chute brutale, pas de pénalité visible. Juste une érosion. Je jette un œil à sa Search Console : un tiers des URL classées sont passées en « À améliorer » sur les Core Web Vitals. Rien d'alarmant en apparence. Sauf que sur les pages produit qui comptaient le plus, l'INP dépassait les 500 ms. Voilà le coupable.

Optimiser les Core Web Vitals, ce n'est pas un projet technique qu'on lance une fois pour cocher une case. C'est un travail de fond, souvent mal priorisé, et dont les vrais gains se mesurent en visibilité et en conversions, pas en points PageSpeed. Dans cet article, je vous montre comment je m'y prends concrètement, ce qui marche, et surtout ce que j'ai longtemps fait de travers.

Core Web Vitals : comprendre ce qui est réellement mesuré

Beaucoup de développeurs confondent encore le score Lighthouse et les Core Web Vitals. Ce sont deux choses différentes, et cette confusion coûte cher. Le score Lighthouse est une simulation, faite sur un serveur, avec une connexion artificielle. Les Core Web Vitals, eux, sont calculés à partir de ce que vivent vos vrais visiteurs.

Les trois métriques en bref

Voici les seuils à garder en tête, ceux que Google considère comme « bons » :

• LCP (Largest Contentful Paint) : le temps d'affichage du plus gros élément visible. Objectif : moins de 2,5 secondes.
• INP (Interaction to Next Paint) : le délai entre une action utilisateur et la réaction de la page. Objectif : moins de 200 ms.
• CLS (Cumulative Layout Shift) : la stabilité visuelle, quand des éléments bougent pendant le chargement. Objectif : moins de 0,1.

L'INP a remplacé le FID il y a quelques années. Et franchement, c'est une bonne nouvelle pour la mesure, une moins bonne pour ceux qui pensaient avoir fini leur chantier. Le FID ne captait que le premier clic ; l'INP mesure toutes les interactions, tout au long de la visite. Résultat : des sites qui passaient haut la main se retrouvent à découvert.

Terrain contre laboratoire, la distinction qui change tout

Un score Lighthouse à 98 ne veut pas dire que vos Core Web Vitals sont bons. J'ai vu des sites notés quasi parfaitement en laboratoire rester bloqués en « À améliorer » dans la Search Console, simplement parce que leurs visiteurs naviguaient sur des téléphones d'entrée de gamme avec une 4G capricieuse. La donnée terrain, agrégée sur des utilisateurs réels, ne triche pas. C'est elle qu'il faut écouter.

Pour la consulter, deux points d'entrée : PageSpeed Insights (qui affiche les deux volets), et le rapport dédié dans la Search Console. Si vous voulez descendre plus finement dans le détail, le web developer en vous ouvrira les DevTools et l'onglet Performance. Avouons-le, c'est là que je passe le plus de temps.

Optimiser le LCP : attaquer le chargement à la source

Le LCP est souvent le plus facile à améliorer, et celui qui donne les gains les plus visibles. Quand une image de bannière met trois secondes à apparaître, l'utilisateur est déjà parti. Et ce n'est pas qu'une impression : passé un certain délai, la majorité des visiteurs mobiles abandonnent.

Ce que je regarde en premier

Je commence toujours par identifier l'élément LCP réel. Souvent, c'est une image d'en-tête, parfois un gros titre, plus rarement une vidéo. Une fois que je sais de quoi il s'agit, la liste des interventions est courte :

1. Servir l'image en format moderne (WebP, AVIF) et à la bonne dimension.
2. Ajouter fetchpriority="high" sur l'élément LCP pour qu'il passe devant le reste.
3. Précharger la police critique, ou accepter un rendu de secours le temps qu'elle arrive.
4. Mettre en cache côté serveur ce qui ne change pas.

Sur un projet récent — une boutique avec un catalogue photo lourd — j'ai fait passer le LCP mobile de 4,1 à 2,2 secondes en trois semaines. Rien de miraculeux : conversion des images, suppression d'un script de carrousel inutile et un vrai cache serveur. Le trafic organique a suivi dans les deux mois.

Le piège du premier écran

Attention au reflexe « je charge tout en priorité ». Si vous préchargez trop de ressources, elles se battent toutes pour la bande passante et le LCP empirera. La priorisation, c'est choisir une seule chose importante et laisser le reste attendre. C'est un arbitrage, pas une accumulation.

INP : le vrai défi 2026 des performances web

Ici, on touche le sujet que la plupart des audits survolent. Le LCP est un problème de réseau et de serveur. L'INP, c'est un problème de code. Et quand une page répond lentement, ce n'est presque jamais la faute de l'hébergement.

Pourquoi l'INP déraille

Le navigateur exécute le JavaScript sur un seul fil. Si une longue tâche l'occupe, il ne peut pas réagir à ce que l'utilisateur fait. Cliquez sur un bouton, il ne se passe rien pendant un instant. Voilà l'INP qui s'envole.

Les causes que je rencontre le plus :

• Des scripts tiers (chat, tracking, A/B testing) qui s'exécutent au pire moment.
• Des gestionnaires d'événements qui font trop de travail d'un coup.
• Une hydratation côté client qui bloque le fil au chargement.

Une fois, sur un site de réservation, un simple script de gestion de consentement ajoutait 300 ms à chaque interaction. Personne ne l'aurait deviné sans profiler. Trois lignes de code déplacées plus tard, l'INP repassait au vert.

Comment j'améliore l'INP concrètement

La recette est moins spectaculaire qu'on l'imagine. Découper les longues tâches, déplacer le travail non critique après le chargement, charger les scripts tiers en différé. Et surtout : mesurer avant de toucher. Sans profil de performance, on corrige à l'aveugle.

CLS : stabiliser ce qui bouge sous les doigts

Un décalage de mise en page, c'est ce moment où vous visez un bouton et où le texte a bougé juste avant votre clic. Ça agace l'utilisateur, et ça se paie en frustration. Heureusement, le CLS est le plus simple des trois à corriger.

Les déclencheurs classiques

Dans la grande majorité des cas que j'ai traités, le CLS vient de deux choses : des images sans dimensions déclarées et des polices qui arrivent après coup. Réservez l'espace dès le départ, avec des attributs de largeur et hauteur, et le problème disparaît. Pour les bannières publicitaires ou les contenus injectés, prévoyez un conteneur de taille fixe. Simple, mais souvent oublié.

Métrique	Seuil « bon »	Cause principale	Levier prioritaire
LCP	< 2,5 s	Image ou ressource bloquante	Serveur, cache, format d'image
INP	< 200 ms	JavaScript bloquant	Découpage des tâches, scripts tiers
CLS	< 0,1	Éléments sans dimensions	Réserver l'espace, polices

Évaluer et prioriser sans se ruiner

Question qu'on me pose souvent : « Par où je commence quand j'ai un budget limité ? » Ma réponse est toujours la même, et elle surprend : ne commencez pas par les pages les plus visitées. Commencez par celles qui convertissent.

Une page produit qui génère des ventes avec un LCP de 3,5 secondes vous coûte de l'argent chaque jour. Une page de blog ultra-visitée avec un CLS moyen, beaucoup moins. Pour évaluer, vous n'avez pas besoin d'un outil payant : l'analyse de performance via PageSpeed Insights, la Search Console et les DevTools suffisent pour un premier diagnostic gratuit. Le vrai coût, c'est le temps de correction.

L'audit qui ne sert à rien

Un audit qui liste 200 recommandations et laisse le client seul face à l'écran ne sert à rien. Ce qui marche, c'est un classement par rapport gain/effort. Sur mon dernier projet, on a obtenu un meilleur résultat en corrigeant huit pages ciblées qu'en retravaillant tout le site. Huit pages, deux mois, un trafic stable en hausse.

Et surtout : mesurez après. J'ai déjà corrigé un LCP sans vérifier la donnée terrain, pour découvrir trois semaines plus tard que le problème s'était déplacé ailleurs. Le progrès se constate, il ne se suppose pas.

Les Core Web Vitals ne sont pas un examen à réussir une fois, puis à oublier. Un site change, les scripts tiers évoluent, les images s'accumulent. Ce qui se maintient, ce n'est pas un score figé : c'est une habitude de mesurer ce que vivent vos visiteurs, page par page, et de corriger là où ça compte vraiment. Le jour où vous arrêterez de regarder, la dérive aura déjà commencé.