Core Web Vitals : obtenir un site qui charge en moins d'une seconde
LCP, INP, CLS : ce que mesurent vraiment les Core Web Vitals, les outils pour les auditer sans se tromper, et la méthode concrète pour faire passer un site sous la seconde de chargement.
Un site qui met plus de trois secondes à s’afficher perd une bonne partie de ses visiteurs avant même d’avoir fini de charger. Google le sait, et en a fait un critère de classement officiel via trois métriques précises : les Core Web Vitals. Voici ce qu’elles mesurent réellement, comment les auditer sans se fier au premier chiffre venu, et la méthode pour faire passer un site sous la seconde.
Que mesurent réellement les Core Web Vitals
Trois métriques, chacune avec un seuil « bon » à viser :
| Métrique | Ce qu’elle mesure | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Temps d’affichage du plus gros élément visible à l’écran | ≤ 2,5 s | ≤ 4 s | > 4 s |
| INP (Interaction to Next Paint) | Réactivité du site à un clic, un tap ou une saisie | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Stabilité visuelle pendant le chargement (les éléments qui « sautent ») | ≤ 0,1 | ≤ 0,25 | > 0,25 |
L’INP a remplacé le FID (First Input Delay) en 2024 : il ne mesure plus seulement le premier délai de réaction, mais la réactivité sur toute la durée de la visite. Un site peut répondre vite au premier clic et devenir poussif ensuite ; l’INP capture ce cas.
Pourquoi ça compte autant
Deux raisons, indépendantes l’une de l’autre. La première est le référencement : depuis 2021, les Core Web Vitals font partie des signaux de classement de Google. Ce n’est pas le facteur numéro un, mais à contenu équivalent, il départage deux pages concurrentes.
La seconde raison, plus concrète, est le comportement des visiteurs. Un site lent, ou dont les boutons se dérobent au moment où on clique dessus, génère de l’abandon et des formulaires jamais envoyés. Sur mobile, avec une connexion moins stable et un processeur moins puissant, ces défauts sont amplifiés : c’est souvent là que se joue la différence entre un visiteur qui reste et un qui repart.
Les outils pour savoir où on en est, avant d’agir
Avant de corriger quoi que ce soit, il faut mesurer correctement, ce qui suppose de distinguer deux types de données :
- Les données de labo (Lighthouse dans Chrome DevTools, PageSpeed Insights en mode « diagnostics ») : une simulation ponctuelle, sur un appareil et une connexion standardisés. Utile pour déboguer, mais ce n’est pas ce que vivent vos vrais visiteurs.
- Les données de terrain (l’onglet « Expérience » de PageSpeed Insights, ou le rapport « Signaux Web essentiels » de Search Console) : des mesures agrégées sur les 28 derniers jours, prises sur les appareils et connexions réels de vos visiteurs. C’est la seule donnée qui compte pour le classement Google.
Un site peut très bien obtenir un excellent score en labo et rester mauvais en conditions réelles, si une majorité de son trafic vient de mobiles bas de gamme. Toujours croiser les deux avant de conclure.
La méthode : les leviers qui font vraiment la différence
Réduire le LCP
L’essentiel du gain vient de trois réglages : servir les images au bon format (AVIF ou WebP) et à la bonne taille, ne pas laisser du JavaScript bloquer l’affichage du contenu principal, et précharger (preload) l’image ou la police qui compose l’élément le plus visible de la page.
Stabiliser le CLS
La cause la plus fréquente est simple : des images ou des vidéos sans dimensions (width/height ou aspect-ratio) définies à l’avance, qui poussent le contenu au moment où elles se chargent. Réserver l’espace dès le départ élimine la quasi-totalité des décalages visuels.
Améliorer l’INP
Le vrai levier est la quantité de JavaScript exécutée pendant le chargement. C’est un des principes que j’applique sur mes propres projets, détaillé dans cet article sur Astro et GSAP : livrer zéro JavaScript par défaut, et ne charger les scripts d’interaction qu’au moment où ils deviennent réellement utiles.
Un exemple concret : avant / après
Sur une refonte technique typique, partant d’un site construit sur un thème générique surchargé de scripts, voici l’ordre de grandeur des gains obtenus en repartant sur une base plus saine :
| Métrique | Avant refonte | Après refonte |
|---|---|---|
| LCP | 4,1 s | 0,9 s |
| INP | 340 ms | 110 ms |
| CLS | 0,22 | 0,01 |
Ce n’est pas de la magie : c’est le résultat d’une refonte technique du site qui traite la performance comme une contrainte de conception dès le départ, plutôt que comme un correctif appliqué après coup.
Ce qu’il faut retenir
Les Core Web Vitals ne sont pas un score à obtenir pour cocher une case Google. Ce sont trois symptômes concrets — lenteur, instabilité, lourdeur — qui, une fois corrigés, se traduisent directement en visiteurs qui restent et en formulaires envoyés jusqu’au bout.
Discutons de votre projet
Si votre site accumule les signaux au rouge dans Search Console, ou si vous voulez simplement repartir sur une base rapide dès la conception, envoyez-moi un message : je peux auditer la situation actuelle et vous dire précisément ce qui pèse sur vos performances.