Loading...

Performance · 9 min de lecture

Core Web Vitals : corriger LCP, INP et CLS là où ça compte

Les Core Web Vitals sont les trois chiffres par lesquels Google résume le ressenti d’une page : la vitesse d’apparition du contenu principal (LCP), la rapidité de réaction aux interactions (INP), et l’ampleur des sauts de mise en page pendant le chargement (CLS). Ils comptent deux fois — comme signal de classement, et parce qu’ils mesurent exactement ce qui fait fuir les visiteurs. Ce guide explique ce que chacun mesure vraiment, quelles données croire, et les correctifs dans l’ordre de l’impact plutôt que dans l’ordre du folklore d’internet.

Updated

Core Web Vitals : corriger LCP, INP et CLS là où ça compte

Ce que mesurent réellement les trois chiffres

LCP — Largest Contentful Paint — est le temps jusqu’au rendu du plus grand élément visible : l’image de couverture, le bloc de titre. C’est la métrique la plus proche de « quand la page a-t-elle semblé chargée ». Le bon seuil est sous 2,5 secondes au 75e percentile des visites réelles.

INP — Interaction to Next Paint — mesure le temps que met la page à répondre visiblement après un tap, un clic ou une frappe clavier, sur l’ensemble de la visite. Le bon seuil est sous 200 ms. Il a remplacé le FID en 2024 et il est plus strict : il capture la lourdeur que ressentent les utilisateurs sur les pages chargées de JavaScript, pas seulement la première interaction.

CLS — Cumulative Layout Shift — note l’ampleur des déplacements de contenu visible sans action de l’utilisateur : le paragraphe que vous lisiez qui saute quand une publicité se charge, le bouton qui a bougé au moment où vous tapiez. Le bon seuil est sous 0,1, et contrairement aux deux autres, c’est un score sans unité, pas un temps.

Données terrain vs labo : quels chiffres croire

PageSpeed Insights montre deux mondes différents. La section du haut — « ce qu’ont vécu les utilisateurs réels » — provient des données terrain d’utilisateurs Chrome sur 28 jours, et c’est ce que Google utilise réellement. Le score du bas est une simulation en laboratoire sur du matériel bridé : utile pour diagnostiquer, trompeur comme objectif.

Conséquences pratiques : un score labo de 60 avec des données terrain vertes signifie que tout va bien ; un labo parfait avec du terrain rouge signifie que les visiteurs réels sur des réseaux réels souffrent, et pas la machine de labo. Optimisez pour les chiffres terrain, servez-vous du rapport labo pour comprendre POURQUOI ils sont ce qu’ils sont, et rappelez-vous que les données terrain sont en retard — un correctif d’aujourd’hui met jusqu’à 28 jours à apparaître pleinement.

Corriger le LCP : avant tout un problème de diffusion

Core Web Vitals : corriger LCP, INP et CLS là où ça compte — Corriger le LCP : avant tout un problème de diffusion
Options d’image optimization et de compression pour une règle de diffusion.

Le LCP se décompose en : temps d’obtention du HTML, temps de découverte de l’image principale, temps de téléchargement, temps de rendu. Trois de ces quatre étapes relèvent de la diffusion — c’est pourquoi le LCP est le vital qu’un CDN fait le plus bouger, et la bonne première cible.

Les leviers par ordre d’impact : servir le HTML et les ressources depuis le cache de périphérie pour que les premiers octets viennent de tout près plutôt que de votre origine ; convertir les images de couverture en WebP/AVIF et les dimensionner à l’affichage réel au lieu d’expédier des fichiers en résolution d’appareil photo ; compresser le texte qui doit arriver avant le rendu. Sur cdn.com.tr, ces trois leviers sont des réglages de règle de diffusion — cache en périphérie, optimisation d’images WebP/AVIF automatique, et Brotli/Gzip — si bien que les plus gros leviers du LCP sont des interrupteurs, pas une refonte. Côté application, donnez à l’image de couverture une priorité de chargement élevée et ne la chargez jamais en lazy-loading : lazy-loader l’élément LCP est la blessure auto-infligée la plus courante.

Corriger le CLS : réservez l’espace

Le décalage de mise en page a une seule cause racine : du contenu qui arrive sans espace réservé. Les correctifs sont sans gloire et fiables. Donnez à chaque image et vidéo des attributs width et height explicites (ou un aspect-ratio en CSS) pour que le navigateur réserve la boîte avant l’arrivée du fichier. Donnez aux emplacements publicitaires et aux intégrations des conteneurs de taille fixe qui gardent leur place que le contenu se charge ou non. Préchargez les polices personnalisées et utilisez des stratégies font-display qui évitent les substitutions tardives refaisant couler la page. Et n’injectez jamais de bannières au-dessus du contenu existant après le chargement — ce seul schéma explique la plupart des scores CLS catastrophiques.

Le CLS est le vital où un week-end d’ajout d’attributs fait passer régulièrement une page en échec au vert.

Corriger l’INP : moins de JavaScript sur le thread principal

L’INP est le plus tenace, parce que sa cause est structurelle : trop de JavaScript faisant trop de travail sur le thread qui doit aussi répondre à l’utilisateur. La diffusion aide à la marge — des bundles plus petits et compressés arrivent et se parsent plus vite — mais les vrais correctifs sont dans l’application : découper les tâches longues pour que le navigateur puisse respirer entre elles, différer les scripts tiers qui n’ont pas besoin de tourner avant l’interaction, et tailler dans la charge du gestionnaire de balises accumulée au fil des ans. Mesurez d’abord : la vue des tâches longues du panneau de performance vous dit exactement quels scripts tiennent le thread.

Méfiez-vous de quiconque promet un correctif INP sans toucher à votre JavaScript — cette métrique existe précisément parce que la diffusion seule ne peut pas simuler la réactivité.

Un ordre de travail raisonnable

Vérifiez les données terrain des pages qui comptent commercialement, pas seulement la page d’accueil. Si le LCP échoue : cache en périphérie, format et dimensionnement des images, compression — le lot diffusion — puis la priorité de chargement. Si le CLS échoue : dimensions, emplacements réservés, chargement des polices. Si l’INP échoue : budgétez un vrai travail applicatif ; rien d’autre ne le fait bouger honnêtement. Re-mesurez sur le terrain après chaque cycle et attendez-vous au décalage de 28 jours.

Et gardez le cadre : le but n’est pas le badge. Les mêmes 2,5 secondes qui satisfont une métrique font la différence entre un visiteur qui reste et un qui part — le badge n’est que l’endroit où on peut le voir.

Questions fréquentes

Les Core Web Vitals influencent-ils vraiment le classement ?

Oui, comme un signal parmi beaucoup d’autres — un départage entre résultats comparables plutôt qu’un facteur dominant. L’effet business le plus important est généralement direct : la même lenteur qui fait échouer la métrique perd des visiteurs avant même que le classement entre en jeu.

Pourquoi mon score labo est-il mauvais alors que les données terrain sont vertes ?

Le labo simule un appareil lent sur un réseau bridé ; votre audience réelle est peut-être mieux équipée. Des données terrain vertes sont la réponse qui compte — utilisez le labo uniquement pour diagnostiquer, pas comme objectif.

En combien de temps un CDN améliore-t-il mes vitals ?

Le mécanisme est immédiat : le HTML mis en cache en périphérie et les images optimisées changent le LCP dès la prochaine visite non cachée. Les chiffres terrain RAPPORTÉS évoluent sur jusqu’à 28 jours, parce qu’ils sont une fenêtre glissante de visites réelles.

Quel vital corriger en premier ?

Celui qui échoue dans les données terrain sur vos pages qui rapportent. Quand plusieurs échouent : le LCP d’abord (réglages de diffusion, gain le plus rapide), le CLS ensuite (correctifs applicatifs bon marché), l’INP en dernier (vrai travail JavaScript).