Tutoriel, Performance web

Ameliorer la vitesse de son site : le guide des Core Web Vitals

LCP, INP, CLS : trois indicateurs suffisent a decrire ce que ressent un visiteur sur votre site. Voici ce que chacun mesure en langage clair, les corrections classees par rentabilite, et pourquoi un score de 100 dans un outil de test ne prouve absolument rien.

Par Yanis Zedira. Publié le 23 août 2026. 10 min de lecture.

La vitesse d'un site se resume souvent a une phrase vague : il rame. Google a traduit cette impression en trois mesures precises, les Core Web Vitals, qui decrivent trois moments distincts de l'experience d'un visiteur. Comprendre ce que chacune mesure suffit a savoir quoi corriger, et dans quel ordre.

Ce tutoriel suit une progression simple : d'abord ce que les trois indicateurs veulent dire, ensuite les corrections classees par rapport entre effort et gain, enfin la maniere de mesurer sans se raconter d'histoires.

Etape 1 : comprendre les trois indicateurs

Les seuils publies par Google sont un LCP sous 2,5 secondes, un INP sous 200 millisecondes et un CLS sous 0,1. Une page est consideree comme bonne quand elle respecte les trois pour 75 % des visites reelles.

Le LCP repond a la question : quand la page a-t-elle l'air arrivee ?

Le LCP, ou Largest Contentful Paint, mesure le temps au bout duquel le plus gros element visible de l'ecran est affiche. En pratique, c'est presque toujours l'image de banniere ou le grand titre en haut de page. C'est l'instant ou le visiteur cesse de regarder une zone vide et commence a lire.

L'INP repond a la question : la page reagit-elle quand je clique ?

L'INP, ou Interaction to Next Paint, mesure le delai entre une action du visiteur, clic, appui ou frappe au clavier, et le moment ou l'ecran montre qu'il s'est passe quelque chose. Un INP eleve produit cette sensation de bouton mort sur lequel on appuie deux fois. La cause est presque toujours du JavaScript qui monopolise le navigateur.

Le CLS repond a la question : la page bouge-t-elle sous mes yeux ?

Le CLS, ou Cumulative Layout Shift, mesure les deplacements imprevus du contenu pendant le chargement. C'est le paragraphe qui descend d'un coup parce qu'une image sans dimensions vient de s'inserer au-dessus, ou le bouton que vous ratez parce qu'un bandeau est apparu. Le CLS n'a pas d'unite de temps : c'est un score de perturbation.

Etape 2 : les corrections, de la plus rentable a la moins rentable

L'ordre compte. Les trois premieres actions traitent l'essentiel du retard sur la grande majorite des sites vitrines et des boutiques.

Correction 1 : les images au bon format et aux bonnes dimensions

C'est le gain le plus important pour l'effort le plus faible. Une photo de 4 000 pixels de large affichee dans un bloc de 800 pixels fait telecharger environ vingt-cinq fois trop de donnees pour un resultat identique a l'ecran.

Trois regles suffisent. Exportez chaque image a la taille maximale reellement affichee, en tenant compte des ecrans haute densite, soit environ le double. Servez-la en format moderne, WebP ou AVIF, qui divisent souvent le poids par deux a trois par rapport au JPEG. Fournissez plusieurs largeurs et laissez le navigateur choisir, avec l'attribut srcset et l'attribut sizes.

<img src="banniere-1200.webp"

srcset="banniere-800.webp 800w, banniere-1200.webp 1200w, banniere-1600.webp 1600w"

sizes="(max-width: 768px) 100vw, 1200px"

width="1200" height="675" alt="...">

Les attributs width et height ne servent pas a dimensionner l'image, la feuille de style s'en charge. Ils permettent au navigateur de reserver l'espace avant l'arrivee du fichier, ce qui supprime le decalage visuel.

Correction 2 : precharger l'image principale, ne jamais la differer

Le chargement differe, ou lazy loading, est excellent pour tout ce qui est plus bas dans la page, et contre-productif sur l'image du haut. Une image de banniere en lazy loading est demandee plus tard que necessaire : votre LCP en paie directement le prix.

Declarez donc l'image principale en chargement immediat, donnez-lui une priorite haute, et annoncez-la des l'en-tete du document pour que le navigateur la demande sans attendre d'avoir analyse toute la page.

<link rel="preload" as="image" href="banniere-1200.webp">

Appliquez le lazy loading a toutes les autres images, celles qui sont sous la ligne de flottaison.

Correction 3 : heberger vos polices vous-meme

Une police chargee depuis un service externe impose au navigateur une resolution de nom de domaine, une connexion, un echange de securite, puis le telechargement du fichier, le tout avant d'afficher le moindre texte. Sur mobile, cela ajoute regulierement plusieurs centaines de millisecondes.

Copiez les fichiers de police sur votre propre domaine, au format WOFF2, en ne conservant que les graisses reellement utilisees. Deux graisses suffisent presque toujours. Ajoutez un affichage de repli immediat pour que le texte soit lisible pendant le chargement, plutot que de laisser une zone blanche.

@font-face {

font-family: "Inter";

src: url("/fonts/inter-400.woff2") format("woff2");

font-weight: 400;

font-display: swap;

}

Choisissez une police de repli aux proportions proches, sinon le remplacement produit un saut de mise en page qui degrade le CLS.

Correction 4 : differer le JavaScript non essentiel

C'est le levier principal sur l'INP. Tout script charge de maniere bloquante retarde a la fois l'affichage et la reactivite. Les coupables habituels sont les outils de suivi, les widgets de chat, les bandeaux de consentement mal integres, les carrousels et les cartes interactives.

Trois arbitrages, dans cet ordre. Supprimez ce qui ne sert plus, et il y en a toujours. Passez le reste en chargement differe, avec les attributs defer ou async selon la dependance. Enfin, ne chargez ce qui est lourd qu'au moment ou l'utilisateur en a besoin : une carte n'a pas a etre chargee tant que personne n'a fait defiler jusqu'a elle.

Correction 5 : reserver la place de ce qui arrive en retard

Tout element insere apres coup doit avoir sa place reservee des le depart : bandeau de cookies, message promotionnel, publicite, contenu charge dynamiquement. Fixez une hauteur minimale au conteneur, ou affichez le bandeau en superposition plutot qu'en poussant le contenu vers le bas. Cette seule habitude ramene la plupart des CLS sous le seuil.

Correction 6 : le reste

Compression du serveur, mise en cache, reseau de diffusion de contenu, reduction des redirections. Ces sujets ont un vrai effet, mais ils arrivent apres, et ils relevent plutot de l'hebergement que du contenu. Ne commencez jamais par la.

Etape 3 : mesurer sans se tromper

Un score de 100 dans un outil de test ne garantit rien, et c'est le malentendu le plus courant sur ce sujet.

Les donnees de laboratoire proviennent d'un test que vous declenchez, sur une machine simulee, dans des conditions fixees. Elles sont reproductibles, donc parfaites pour diagnostiquer une cause et verifier qu'une correction agit. Elles ne decrivent pas vos visiteurs.

Les donnees de terrain proviennent des visites reelles, sur une fenetre glissante de vingt-huit jours, avec de vrais telephones, de vrais reseaux et de vraies extensions de navigateur. C'est ce que Google evalue. Un site peut afficher 100 en laboratoire et echouer sur le terrain, par exemple parce que la moitie de son audience navigue en 4G instable sur un telephone de milieu de gamme.

Utilisez le laboratoire pour trouver la cause, le terrain pour confirmer le resultat. Jamais l'inverse.

Deux consequences pratiques. Premierement, attendez environ quatre semaines avant de juger une correction sur les donnees de terrain, le temps que la fenetre se renouvelle. Deuxiemement, regardez toujours vos pages les plus visitees separement, pas seulement la page d'accueil : c'est souvent une fiche produit ou un article qui recoit le trafic et qui pose probleme.

Par ou commencer concretement

Si vous ne devez faire qu'une seule chose cette semaine, ouvrez votre page la plus visitee, identifiez l'image du haut, verifiez son poids et ses dimensions reelles. Sur les sites que nous auditons, ce point isole represente regulierement la plus grande part du retard de LCP.

Ensuite, listez les scripts tiers actifs et supprimez ceux dont personne ne lit plus les donnees. C'est gratuit et immediat.

Si votre site est une boutique, la performance se joue aussi sur les pages de catalogue et le tunnel de commande, ou chaque centaine de millisecondes se traduit en paniers abandonnes. Nous traitons ce sujet du cote outillage dans notre offre d'automatisation e-commerce, et du cote structure dans le SEO technique et local.

Passer a l'action

Un audit technique permet de savoir en quelques jours ce qui coute reellement des secondes sur votre site, et ce qui ne vaut pas la peine d'etre touche. Comptez environ 600 € pour un audit SEO technique et local complet, avec un plan de correction priorise.

Si vous voulez d'abord savoir si le jeu en vaut la chandelle, parlons-en quinze minutes : nous regardons vos chiffres de terrain ensemble et vous repartez avec les deux ou trois actions les plus rentables, meme si vous les faites sans nous.

Reserver un echange de 15 minutes, gratuit et sans engagement