Core Web Vitals : rendre votre site rapide (LCP, INP, CLS)

Un site lent ne se voit pas toujours depuis le bureau, sur une bonne connexion et un ordinateur récent. Il se voit chez vos visiteurs : sur un téléphone d’entrée de gamme, en 4G, quand le bouton ne répond pas ou que le texte saute au moment de cliquer. Les Core Web Vitals servent précisément à mesurer cette expérience réelle, avec trois chiffres et des seuils publics.

Ce guide donne les définitions et les seuils officiels, explique comment lire PageSpeed Insights et la Search Console sans se tromper, puis détaille les corrections qui comptent vraiment. Avec un exemple concret : ce site, dont l’accueil pèse moins de 150 Ko au premier chargement, polices mises à part.

Les trois métriques et leurs seuils officiels

Les Core Web Vitals sont trois métriques choisies par Google parmi les « Web Vitals » pour résumer l’expérience d’une page :

• LCP (Largest Contentful Paint) mesure le chargement : c’est le temps d’affichage du plus grand élément visible à l’écran (une image, une vidéo ou un bloc de texte), compté depuis le début de la navigation. Voir la définition détaillée du LCP.
• INP (Interaction to Next Paint) mesure la réactivité : le délai entre un clic, un appui ou une touche du clavier et l’affichage de la réponse à l’écran. Le défilement et le survol ne comptent pas. Voir la définition de l’INP.
• CLS (Cumulative Layout Shift) mesure la stabilité visuelle : il additionne les décalages inattendus de la mise en page, par rafales, et retient la plus forte. Voir la définition du CLS.

Ces seuils ne s’appliquent pas à une visite isolée : Google recommande de les atteindre au 75e centile des chargements de page, séparément sur mobile et sur ordinateur. Autrement dit, trois visites sur quatre doivent être dans le vert. Une page qui s’affiche vite chez vous mais lentement chez plus d’un quart de vos visiteurs n’est pas « bonne ».

L’INP est un Core Web Vital stable depuis le 12 mars 2024. Il a remplacé le FID (First Input Delay), qui ne mesurait que le délai avant le traitement de la première interaction. Si un outil ou un article vous parle encore du FID, il est daté.

Ce que Google en fait vraiment pour le référencement

La documentation de Google est nette sur deux points. D’un côté, les Core Web Vitals sont utilisés par ses systèmes de classement. De l’autre, il n’existe pas de « signal unique » d’expérience de page, Google cherche toujours à afficher le contenu le plus pertinent même si l’expérience est médiocre, et de bons résultats dans les rapports ne garantissent pas d’être en tête.

Mon avis : traitez les Core Web Vitals comme une condition d’hygiène, pas comme une stratégie SEO. Ils ne vous feront pas gagner face à une page plus utile, mais une page lente ou instable perd des visiteurs avant même qu’ils lisent, et c’est souvent là que se joue la conversion. Le bon ordre reste : un contenu qui répond, une technique propre, puis la vitesse.

Données terrain ou données de labo : lire les outils sans se tromper

Deux familles de mesures coexistent, et la confusion entre les deux est l’erreur la plus fréquente.

Les données terrain (CrUX)

Le Chrome UX Report (CrUX) rassemble des mesures anonymisées issues de vrais visiteurs utilisant Chrome, sur une période glissante de 28 jours. Ce sont ces données que Google Search utilise pour l’expérience de page. Limite importante : une page ou un site n’y figure que s’il est public et suffisamment visité. Beaucoup de sites de PME n’ont donc pas de données terrain, ou seulement au niveau du domaine entier.

Les données de laboratoire (Lighthouse)

Lighthouse charge la page dans un environnement simulé et calcule un score sur 100. C’est utile pour diagnostiquer et comparer avant et après une correction, mais ce score n’est pas un Core Web Vital. Un outil de labo ne peut pas mesurer l’INP, faute de vrai visiteur qui clique : Lighthouse s’appuie sur le Total Blocking Time comme indicateur approché.

Les trois outils à utiliser

• PageSpeed Insights affiche les deux : en haut, l’évaluation des Core Web Vitals sur les 28 derniers jours (données réelles) ; en dessous, le diagnostic Lighthouse. La page réussit l’évaluation quand les trois métriques sont bonnes au 75e centile. Sans données suffisantes pour l’URL, l’outil se rabat sur celles du domaine.
• Le rapport Core Web Vitals de la Search Console regroupe les pages qui se ressemblent et donne à chaque groupe le statut de sa plus mauvaise métrique. Après une correction, la validation se suit sur 28 jours.
• Les outils de développement de Chrome (onglet Performances) mesurent les trois métriques pendant que vous naviguez, y compris l’INP de vos propres clics.

Améliorer le LCP : afficher vite l’élément principal

Google décompose le LCP en quatre temps : la réponse du serveur, le délai avant que le navigateur commence à charger la ressource principale, la durée de ce chargement, puis le délai d’affichage. Le guide d’optimisation du LCP en tire des règles simples :

1. Un serveur qui répond vite : pages en cache, HTML statique quand c’est possible, hébergement proche des visiteurs (réseau de diffusion, ou CDN).
2. Une image principale trouvable dans le HTML, et non injectée plus tard par JavaScript ou cachée dans un fond CSS.
3. Une priorité explicite : fetchpriority="high" sur l’image principale, et jamais de loading="lazy" sur elle. Le chargement différé est fait pour les images situées plus bas.
4. Des images au bon format et à la bonne taille : le WebP avec perte est 25 à 34 % plus léger que le JPEG à qualité équivalente, et les attributs srcset et sizes laissent le navigateur choisir le fichier adapté à l’écran.
5. Peu de ressources bloquantes : feuilles de style réduites, scripts chargés avec defer.

Exemple type : une page d’accueil avec un grand carrousel en tête, dont les images arrivent par un script. Le navigateur ne les découvre qu’après avoir exécuté ce script ; remplacer le carrousel par une image fixe, déclarée dans le HTML et prioritaire, fait souvent plus que n’importe quel réglage de serveur.

Améliorer l’INP : libérer le fil principal

Une interaction se découpe en trois phases : l’attente avant que le navigateur traite le clic, l’exécution du code associé, puis l’affichage de l’image suivante. Les trois s’allongent pour la même raison : le fil principal du navigateur est occupé. Toute tâche de plus de 50 millisecondes est une tâche longue qui retarde la réponse aux clics.

• Moins de JavaScript : chaque bibliothèque, module ou application ajoutée à un site s’exécute chez le visiteur. Faites l’inventaire de ce qui est vraiment utilisé.
• Moins de scripts tiers : fenêtres de discussion, outils de suivi, vidéos intégrées et gestionnaires de balises sont souvent les plus lourds. Chargez-les après l’affichage, ou seulement quand le visiteur en a besoin.
• Des tâches découpées : dans le code, rendre la main au navigateur entre deux étapes (avec scheduler.yield() ou, à défaut, setTimeout) lui permet de répondre au clic avant de finir le reste.
• Une page plus simple : le guide d’optimisation de l’INP rappelle que le travail d’affichage grandit avec la taille du DOM, c’est-à-dire le nombre d’éléments de la page.

Améliorer le CLS : réserver la place de chaque élément

Un décalage de mise en page survient quand un élément arrive après coup et pousse le reste. Les causes sont presque toujours les mêmes, et le guide d’optimisation du CLS les liste :

• Attributs width et height sur chaque image et vidéo (ou aspect-ratio en CSS), pour que le navigateur réserve la place avant le chargement
• Espace réservé pour les publicités, vidéos intégrées et widgets dont la hauteur varie
• Aucun contenu inséré au-dessus de ce que le visiteur lit, sauf en réponse à son action ; un bandeau de consentement peut se superposer en bas de l’écran plutôt que pousser la page
• Polices web maîtrisées : police de secours proche, préchargement de la police principale, réglage de font-display
• Animations réalisées avec transform, qui ne recalcule pas la mise en page

Les décalages qui suivent de près une action du visiteur, comme l’ouverture d’un menu dans la demi-seconde qui suit un clic, ne sont pas comptés : ils sont attendus.

Exemple réel : comment ce site reste léger

J’ai conçu ce site pour qu’il soit rapide par construction, plutôt que corrigé après coup. Voici les choix concrets, vérifiables dans le code de la page :

• Aucune dépendance : pas de framework ni de bibliothèque. Les pages sont générées en HTML statique, donc servies telles quelles, sans calcul côté serveur.
• Un budget de poids contrôlé : le chargement initial de l’accueil (HTML, CSS, JavaScript et images affichées d’emblée) doit rester sous 150 Ko hors polices. Le script de contrôle du site le mesure à chaque vérification et échoue au-delà.
• Des images WebP adaptées à l’écran : chaque image existe en plusieurs largeurs avec srcset et sizes, porte ses dimensions, et seules celles du haut de page sont chargées d’emblée. Le portrait de l’accueil a fetchpriority="high" ; les autres sont en loading="lazy".
• Des polices auto-hébergées : une seule famille, au format WOFF2, découpée en deux fichiers (alphabet latin de base et caractères étendus) grâce à unicode-range, avec le fichier principal préchargé et font-display: swap.
• Très peu de JavaScript : un petit script dans l’en-tête, qui applique le thème clair ou sombre avant l’affichage (sinon la page clignote) et, à l’arrivée sur le site, oriente un navigateur non francophone vers la version anglaise de la page, puis un script principal chargé en defer. Aucun script tiers : la mesure d’audience est prête mais désactivée, et si elle est activée, elle ne se chargera qu’après consentement.
• Un cache long : les fichiers CSS et JavaScript portent une empreinte de version dans leur adresse et sont mis en cache un an, comme les polices. Une mise à jour change l’adresse, donc le visiteur ne garde jamais une ancienne version.

Deux nuances honnêtes. Auto-héberger ses polices n’est pas automatiquement plus rapide : les bonnes pratiques de web.dev rappellent que le gain est incertain sans CDN ni HTTP/2, et conseillent de mesurer. Je l’ai choisi surtout pour ne faire aucune requête vers un tiers et garder une politique de sécurité stricte. Et swap affiche le texte tout de suite, au prix d’un léger changement d’apparence quand la police arrive : un compromis assumé.

Par où commencer : la méthode en cinq étapes

1. Repérer : ouvrez le rapport Core Web Vitals de la Search Console, côté mobile d’abord, et notez les groupes de pages en orange ou en rouge.
2. Diagnostiquer : passez une page représentative de chaque groupe dans PageSpeed Insights. Identifiez l’élément LCP, les tâches longues et les éléments qui bougent.
3. Corriger le plus gros d’abord : l’image principale, les scripts tiers et les dimensions d’images règlent la majorité des cas. Les micro-optimisations viennent après.
4. Vérifier en labo : relancez Lighthouse ou les outils de Chrome pour confirmer l’effet avant de mettre en ligne.
5. Attendre les données réelles : les données terrain portent sur 28 jours glissants. Lancez la validation dans la Search Console et jugez le résultat à la fin de cette période, pas le lendemain.

La performance se surveille aussi dans le temps : une nouvelle application, une vidéo en page d’accueil ou un module ajouté peut tout défaire. C’est un des points de la checklist d’audit SEO technique, et un contrôle à prévoir dans la recette avant chaque mise en ligne.

En résumé : la vitesse se décide à la conception

Retenez trois chiffres (2,5 s, 200 ms, 0,1), une règle (le 75e centile des vrais visiteurs) et une méthode : repérer dans la Search Console, diagnostiquer dans PageSpeed Insights, corriger l’image principale, le JavaScript et les dimensions réservées. Le plus efficace reste de ne pas alourdir le site au départ : chaque script, police ou module doit justifier sa place. C’est l’approche que j’applique pour la création de sites internet rapides et bien référencés.