Tutoriel, Performance web

Améliorer la vitesse de son site : le guide des Core Web Vitals

LCP, INP, CLS : trois indicateurs suffisent à décrire ce que ressent un visiteur sur votre site. Voici ce que chacun mesure en langage clair, les corrections classées par rentabilité, 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 résumé souvent à une phrase vague : il rame. Google à traduit cette impression en trois mesures précises, les Core Web Vitals, qui décrivent trois moments distincts de l'expérience d'un visiteur. Comprendre ce que chacune mesure suffit à 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 classées par rapport entre effort et gain, enfin la manière de mesurer sans se raconter d'histoires.

Étape 1 : comprendre les trois indicateurs

Les seuils publiés par Google sont un LCP sous 2,5 secondes, un INP sous 200 millisecondes et un CLS sous 0,1. Une page est considérée comme bonne quand elle respecte les trois pour 75 % des visites réelles.

Le LCP répond à la question : quand la page a-t-elle l'air arrivée ?

Le LCP, ou Largest Contentful Paint, mesure le temps au bout duquel le plus gros élément visible de l'écran est affiché. En pratique, c'est presque toujours l'image de bannière ou le grand titre en haut de page. C'est l'instant ou le visiteur cesse de regarder une zone vide et commence à lire.

L'INP répond à la question : la page réagit-elle quand je clique ?

L'INP, ou Interaction to Next Paint, mesure le délai entre une action du visiteur, clic, appui ou frappe au clavier, et le moment ou l'écran montre qu'il s'est passé quelque chose. Un INP élevé 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 répond à la question : la page bouge-t-elle sous mes yeux ?

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

Étape 2 : les corrections, de la plus rentable à la moins rentable

L'ordre compte. Les trois premières actions traitent l'essentiel du retard sur la grande majorité 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 affichée dans un bloc de 800 pixels fait télécharger environ vingt-cinq fois trop de données pour un résultat identique à l'écran.

Trois règles suffisent. Exportez chaque image à la taille maximale réellement affichée, en tenant compte des écrans haute densité, soit environ le double. Servez-la en format moderne, WebP ou AVIF, qui divisent souvent le poids par deux à trois par rapport au JPEG. Fournissez plusieurs largeurs et laissez le navigateur choisir, avec l'attribut srcset et l'attribut sizes.

<img src="bannière-1200.webp"

srcset="bannière-800.webp 800w, bannière-1200.webp 1200w, bannière-1600.webp 1600w"

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

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

Les attributs width et height ne servent pas à dimensionner l'image, la feuille de style s'en charge. Ils permettent au navigateur de réserver l'espace avant l'arrivée du fichier, ce qui supprime le décalage visuel.

Correction 2 : précharger l'image principale, ne jamais la différer

Le chargement différé, 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 bannière en lazy loading est demandée plus tard que nécessaire : votre LCP en paie directement le prix.

Déclarez donc l'image principale en chargement immédiat, donnez-lui une priorité haute, et annoncez-la des l'en-tête du document pour que le navigateur la demande sans attendre d'avoir analysé toute la page.

<link rel="preload" as="imagé" href="bannière-1200.webp">

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

Correction 3 : héberger vos polices vous-même

Une police chargée depuis un service externe impose au navigateur une résolution de nom de domaine, une connexion, un échange de sécurité, puis le téléchargement du fichier, le tout avant d'afficher le moindre texte. Sur mobile, cela ajoute régulièrement plusieurs centaines de millisecondes.

Copiez les fichiers de police sur votre propre domaine, au format WOFF2, en ne conservant que les graisses réellement utilisées. Deux graisses suffisent presque toujours. Ajoutez un affichage de repli immédiat pour que le texte soit lisible pendant le chargement, plutôt 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 dégrade le CLS.

Correction 4 : différer le JavaScript non essentiel

C'est le levier principal sur l'INP. Tout script charge de manière bloquante retarde à la fois l'affichage et la réactivité. Les coupables habituels sont les outils de suivi, les widgets de chat, les bandeaux de consentement mal intégrés, 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 différé, avec les attributs defer ou async selon la dépendance. Enfin, ne chargez ce qui est lourd qu'au moment ou l'utilisateur en a besoin : une carte n'a pas à être chargée tant que personne n'a fait défiler jusqu'à elle.

Correction 5 : réserver la place de ce qui arrive en retard

Tout élément inséré après coup doit avoir sa place réservée des le départ : bandeau de cookies, message promotionnel, publicité, contenu charge dynamiquement. Fixez une hauteur minimale au conteneur, ou affichez le bandeau en superposition plutôt qu'en poussant le contenu vers le bas. Cette seule habitude ramène la plupart des CLS sous le seuil.

Correction 6 : le reste

Compression du serveur, mise en cache, réseau de diffusion de contenu, réduction des redirections. Ces sujets ont un vrai effet, mais ils arrivent après, et ils relèvent plutôt de l'hébergement que du contenu. Ne commencez jamais par la.

Étape 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 données de laboratoire proviennent d'un test que vous déclenchez, sur une machine simulée, dans des conditions fixées. Elles sont reproductibles, donc parfaites pour diagnostiquer une cause et vérifier qu'une correction agit. Elles ne décrivent pas vos visiteurs.

Les données de terrain proviennent des visites réelles, sur une fenêtre glissante de vingt-huit jours, avec de vrais téléphones, de vrais réseaux et de vraies extensions de navigateur. C'est ce que Google évalue. Un site peut afficher 100 en laboratoire et échouer sur le terrain, par exemple parce que la moitié de son audience navigue en 4G instable sur un téléphone de milieu de gamme.

Utilisez le laboratoire pour trouver la cause, le terrain pour confirmer le résultat. Jamais l'inverse.

Deux conséquences pratiques. Premièrement, attendez environ quatre semaines avant de juger une correction sur les données de terrain, le temps que la fenêtre se renouvelle. Deuxièmement, regardez toujours vos pages les plus visitées séparément, pas seulement la page d'accueil : c'est souvent une fiche produit ou un article qui reçoit le trafic et qui pose problème.

Par où commencer concrètement

Si vous ne devez faire qu'une seule chose cette semaine, ouvrez votre page la plus visitée, identifiez l'image du haut, vérifiez son poids et ses dimensions réelles. Sur les sites que nous auditons, ce point isole représente régulièrement la plus grande part du retard de LCP.

Ensuite, listez les scripts tiers actifs et supprimez ceux dont personne ne lit plus les données. C'est gratuit et immédiat.

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

Passer à l'action

Un audit technique permet de savoir en quelques jours ce qui coûte réellement des secondes sur votre site, et ce qui ne vaut pas la peine d'être 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, même si vous les faites sans nous.

Réserver un échange de 15 minutes, gratuit et sans engagement

Outils associés, en libre accès : le compresseur d'images WebP. Sans inscription, le calcul se fait dans votre navigateur. Tous les outils sont sur la page Outils en ligne.