Optimiser les Core Web Vitals : diagnostiquer et prioriser LCP, INP et CLS
1. Ce que mesure chaque indicateur : comprendre avant d’agir
Beaucoup d’équipes lancent Lighthouse immédiatement et corrigent au hasard dès qu’elles voient des croix rouges. Commencez par comprendre ce que mesure chaque indicateur pour cibler le bon problème.
| Indicateur | Ce qu’il mesure | Seuil de qualification | Causes fréquentes |
|---|---|---|---|
| LCP, Largest Contentful Paint | Temps de chargement du plus grand élément du premier écran | ≤ 2,5 s | Image du premier écran trop lourde, police bloquante, serveur lent |
| INP : de l’interaction à la prochaine peinture | Délai de réponse de l’interface après un clic | ≤ 200 ms | Tâches longues sur le thread principal, JS trop volumineux, scripts tiers |
| CLS : décalage cumulé de mise en page | Ampleur des décalages d’éléments pendant le chargement | ≤ 0,1 | Images sans dimensions, emplacements publicitaires sans réserve, changement de police |
La mesure doit se faire au 75e percentile : sur 100 visiteurs, il faut que les 75 premiers soient conformes. La moyenne ou la médiane n’ont aucun sens. Les données CrUX se consultent dans le rapport Expérience de Search Console : ce sont les mêmes données que celles utilisées pour le signal de classement Google.
Attention aussi aux interactions entre les trois indicateurs : compresser les images fait baisser le LCP, mais un mauvais lazy loading peut repousser l’élément LCP à la deuxième frame ; le preload des polices fait baisser le LCP, mais trop de polices en preload saturent les requêtes réseau et dégradent l’INP. Après chaque modification, attendez 14 jours pour observer les données utilisateurs réelles, et ne modifiez pas tout en chaîne.
2. Corriger le LCP : commencer par le gain le plus important
Le LCP représente généralement plus de 50 % du gain total des trois indicateurs. Il se décompose en quatre phases : identifiez d’abord celle qui vous bloque.
| Phase du LCP | Outil de diagnostic | Goulot fréquent | Correctif |
|---|---|---|---|
| TTFB : réponse du serveur | Cascade WebPageTest | Rendu PHP lent, absence de CDN | Cache en périphérie CDN, mise à niveau de PHP |
| Chargement des ressources | Performances Chrome DevTools | Image du premier écran non compressée, sans preload | WebP/AVIF, preload de l’image clé |
| Rendu des ressources | Opportunités Lighthouse | Police bloquant le rendu | font-display: swap + preload |
| Rendu côté client | Panneau Performances de Trace | SPA qui attend le téléchargement du JS pour afficher | SSR ou écran squelette |
Exemple concret : la première image produit d’un site B2B industriel pèse 1,8 Mo sans compression. Le TTFB est correct, mais le LCP plafonne à 4,2 secondes. Convertie en WebP et compressée à 320 Ko, avec fetchpriority=”high” ajouté, l’image fait passer le LCP à 1,9 seconde en une semaine. Une seule balise img a été modifiée, sans toucher à la configuration serveur.
Le choix des nœuds CDN et la stratégie de cache influent directement sur le TTFB, voir Accélération mondiale par CDN. Sur un site multilingue, la localisation des images doit aussi être pensée avec le traitement des graphiques sur un site multilingue.
III. Corriger l’INP : l’étape la plus longue, mais incontournable
L’INP a remplacé le FID en mars 2024. Il mesure le délai complet entre une interaction de l’utilisateur et la réaction réelle de l’interface. Il est plus difficile à corriger que le LCP, car les problèmes sont dispersés dans tout le bundle JS.
| Question | Méthode de diagnostic | Correctif | Gain attendu |
|---|---|---|---|
| Tâches longues du thread principal > 50 ms | Repérer les tâches longues dans le panneau Performance | Découpage du code, Web Worker | INP réduit de 100 à 200 ms |
| Scripts tiers bloquants | Voir leur part dans le panneau Coverage | Chargement différé, async/defer | INP réduit de 50 à 150 ms |
| Callbacks d’événements trop lourds | Repérer les fonctions coûteuses dans la pile d’appels | Debounce et throttle, découper les callbacks | INP réduit de 30 à 80 ms |
| Ressources bloquant le rendu | CSS/JS non utilisés dans Lighthouse | CSS critique en ligne, le reste différé | INP réduit de 50 à 100 ms |
Contre-intuitif : un mauvais INP ne vient pas forcément de votre code. Les sites B2B embarquent souvent un pixel LinkedIn, un plugin de formulaire HubSpot et un script de chat en ligne ; ensemble, ils peuvent bloquer le thread principal plus de 300 ms. Commencez par trier les scripts tiers par priorité de chargement : le gain est plus rapide qu’en retouchant le code métier.
IV. Corriger le CLS : le gain rapide qui reste stable
Le CLS est le plus simple des trois indicateurs à corriger : 90 % des problèmes viennent de deux causes, des images sans dimensions et des publicités ou contenus intégrés sans espace réservé.
| Cause du CLS | Méthode de diagnostic | Correctif |
|---|---|---|
| Images sans width/height | Observer les décalages dans DevTools | Ajouter width/height + aspect-ratio à la balise img |
| Changement de police qui saute | Phénomène FOIT/FOUT | font-display: swap + size-adjust |
| Publicité ou contenu intégré sans espace réservé | La publicité pousse le contenu une fois chargée | Réserver un conteneur de hauteur fixe |
| Bannière injectée dynamiquement | La barre de notification apparaît en haut | Réserver l’espace sans compresser le contenu |
Deuxième exemple : le blog d’un SaaS à l’international affiche un CLS de 0,35 depuis des mois. En cause, une bannière « S’abonner à la newsletter » insérée en haut de l’article après le chargement du JS, qui repousse tout le texte de 120 pixels. Rendue côté serveur avec 120 px d’espace réservé, la bannière fait tomber le CLS à 0,04 en une semaine.
V. Outils de diagnostic et procédure de validation
| Phase | Outil | Source des données | Délai de vérification |
|---|---|---|---|
| Identifier le problème | Rapport CrUX / rapport d’expérience GSC | Données réelles sur 28 jours | À consulter une fois par semaine |
| Reproduire en laboratoire | Lighthouse / WebPageTest | Simuler un Moto G4 en 4G lente | À lancer une fois avant correction |
| Surveillance en production | CrUX / outils RUM | Tendance des indicateurs au 75e percentile | 14 jours après la mise en ligne |
| Validation | Rapport Core Web Vitals dans GSC | Les trois indicateurs au statut « Réussi » | 28 jours après la mise en ligne |
L’erreur classique : ne regarder que le score Lighthouse en local. Lighthouse tourne dans un environnement propre, sans le réseau de vos vrais utilisateurs, sans scripts tiers, sans session connectée. Les sites à 95 en local mais recalés sur CrUX sont légion. Après correction, attendez impérativement la mise à jour des données glissantes sur 28 jours : ne concluez pas au succès trois jours après la mise en ligne.
Optimiser la performance et le système de Core Web Vitals est un travail d’ingénierie continu, pas un projet ponctuel.calendrier de maintenance du site doit inclure un rapport CWV mensuel parmi les points fixes.
Six. Comment intégrer le budget de performance au cycle d’itération
Corriger une vague de CWV ne veut pas dire que c’est réglé pour toujours. Chaque nouvelle fonctionnalité, extension ou script marketing fait repartir les indicateurs à la baisse. La bonne approche : inscrire le budget de performance dans le processus de publication et poser un verrou avant chaque mise en ligne.
| Type de page | Budget LCP | Budget INP | Budget CLS | Budget JS total |
|---|---|---|---|---|
| Page d’accueil et pages de destination | ≤ 2,0 secondes | ≤ 150 millisecondes | ≤ 0,05 | ≤ 250 Ko gzip |
| Page de détail produit | ≤ 2,5 s | ≤ 200 ms | ≤ 0,1 | ≤ 350 Ko gzip |
| Article de blog | ≤ 2,5 s | ≤ 200 ms | ≤ 0,1 | ≤ 300 Ko gzip |
| Pages contact et formulaire | ≤ 2,0 secondes | ≤ 150 millisecondes | ≤ 0,05 | ≤ 200 Ko gzip |
Avant chaque mise en production, faites tourner Lighthouse CI sur ces pages clés en environnement de préproduction : au-delà du budget, pas de fusion. Pour les pop-ups, scripts du service client ou pixels de suivi ajoutés à la hâte par le marketing, passez par une checklist de validation : ce script peut-il être chargé en différé, placé après le premier écran, chargé uniquement sur certaines pages ? Tous les trois mois, produisez un rapport CrUX mensuel, suivez la tendance du 75e percentile et, si un type de page recule deux mois de suite, lancez un chantier de correction.
Un autre point souvent négligé : la gestion des ressources images. Si un nouvel article de blog est publié avec l’original non compressé, le LCP se dégrade aussitôt. Branchez par défaut un pipeline de compression d’images dans le back-office : conversion automatique en WebP à l’upload, compression à un poids raisonnable, génération du srcset. C’est bien moins fatigant que de reprendre les articles un par un après coup. Ce pipeline s’aligne sur le processus de gestion des médias, voir Gouvernance des actifs médias.
Les scripts tiers sont le premier facteur de dégradation de l’INP. Les pixels, widgets de chat et formulaires intégrés ajoutés à la hâte par le marketing pour une nouvelle campagne ne sont souvent pas chargés en différé et saturent tous la phase de rendu du premier écran. Chaque trimestre, sortez la liste complète des scripts tiers du site et passez-la en revue : lesquels servent encore, lesquels peuvent être différés après le premier écran, lesquels ne sont plus consultés par personne et peuvent être supprimés. Faire de cette revue une étape fixe du processus de publication évite bien des optimisations curatives.
Un dernier point sur la méthode de validation : après correction, ne vous fiez pas au seul score Lighthouse en local, attendez la mise à jour des données CrUX réelles sur 28 jours glissants. Le score local sert à localiser un problème, pas à proclamer une réussite. Envoyez chaque mois le rapport CWV aux responsables technique et marketing : la performance devient un indicateur suivi par plusieurs équipes, et non le KPI d’une seule personne en SEO.
FAQ — Questions fréquentes
LCP, INP, CLS : lequel corriger en premier ?
Pourquoi Lighthouse affiche 95 mais Search Console me dit que je suis hors norme ?
Combien de temps pour faire passer l’INP de 500 ms à moins de 200 ?
Qu’est-ce qu’un CLS normal ?
Les Core Web Vitals influencent-ils directement le classement ?
Faut-il regarder les CWV du mobile et du bureau séparément ?
Pour conclure
Les Core Web Vitals sont l’élément du SEO technique au retour sur investissement le plus clair : chaque indicateur a son seuil, son outil de diagnostic et son correctif. Ne vous laissez pas aveugler par le score Lighthouse, regardez les données CrUX des vrais utilisateurs.
Trois étapes pour passer à l’action : cette semaine, repérez dans le rapport Expérience de GSC l’indicateur le plus mauvais ; la semaine suivante, corrigez le premier dans l’ordre LCP → CLS → INP ; après la mise en ligne, vérifiez au bout de 28 jours si le CrUX est entièrement conforme. Avec les trois indicateurs dans les seuils, vous dépassez déjà 70 % des sites B2B à l’international.
Une phrase à retenir : les CWV ne sont pas un jeu de scores, mais le temps d’attente réel des utilisateurs. Le LCP, c’est ce que l’œil voit ; l’INP, ce que la main ressent ; le CLS, ce que l’œil perçoit. Les trois doivent être au vert pour que ce soit bon.