Core Web Vitals : guide performance web
Un site peut être magnifique et parfaitement écrit : s'il met trois secondes à s'afficher ou s'il « saute » sous le doigt de l'internaute, il perd des visiteurs et recule dans les résultats de recherche. La performance n'est pas un détail technique, c'est une partie de l'expérience.
Pour rendre cette expérience mesurable, Google a défini les Core Web Vitals : trois indicateurs qui chiffrent la vitesse d'affichage, la réactivité aux actions et la stabilité visuelle d'une page. Dans ce guide, je détaille ce que recouvrent le LCP, l'INP et le CLS, pourquoi ils pèsent à la fois sur votre référencement et sur vos conversions, comment les mesurer correctement, et surtout quels leviers concrets activer pour accélérer durablement un site.
Les trois Core Web Vitals expliqués
Les Core Web Vitals sont trois mesures complémentaires. Chacune capte une dimension distincte du ressenti de l'internaute : la rapidité d'affichage, la réactivité, et la stabilité de la page. Pour chaque indicateur, Google fixe un seuil « bon » à atteindre pour au moins 75 % des visites réelles, mesurées sur mobile en priorité.
LCP — Largest Contentful Paint (vitesse d'affichage)
Le LCP chronomètre le temps nécessaire pour afficher le plus grand élément visible dans la fenêtre, le plus souvent l'image de couverture, une vidéo ou un gros bloc de titre. C'est le moment où le visiteur a le sentiment que « la page est arrivée ». L'objectif : un LCP inférieur à 2,5 secondes ; au-delà de 4 secondes, l'expérience est jugée mauvaise.
C'est l'indicateur le plus souvent dans le rouge, car il dépend à la fois de la qualité de l'hébergement, du poids de l'image principale et de tout ce qui bloque le rendu avant elle. C'est aussi celui qui réagit le mieux à une optimisation ciblée.
INP — Interaction to Next Paint (réactivité)
L'INP mesure le délai entre une action de l'internaute (clic, tap, frappe au clavier) et la réponse visible de la page. Il a remplacé le FID en mars 2024 et observe désormais l'ensemble des interactions d'une visite, pas seulement la première. Le seuil de référence est un INP inférieur à 200 millisecondes ; au-delà de 500 ms, l'interface paraît figée.
Un mauvais INP trahit presque toujours un excès de JavaScript : le navigateur est occupé à exécuter du code au lieu de réagir au geste de l'utilisateur. C'est un fléau des sites surchargés de scripts tiers.
CLS — Cumulative Layout Shift (stabilité visuelle)
Le CLS quantifie les déplacements inattendus des éléments pendant le chargement : ce bouton qui glisse sous le doigt au moment où l'on s'apprête à cliquer, ce texte poussé vers le bas par une publicité qui apparaît. Contrairement aux deux autres, ce n'est pas une durée mais un score sans unité : visez moins de 0,1, sachant qu'au-delà de 0,25 la page est instable.
Les coupables habituels sont les images et iframes sans dimensions déclarées, les bannières insérées tardivement et les polices web qui redessinent le texte une fois téléchargées. Bonne nouvelle : c'est souvent le plus simple des trois à corriger.
Pourquoi la performance compte vraiment
Soigner ses Core Web Vitals n'a rien d'un exercice cosmétique réservé aux développeurs. L'enjeu se joue sur deux terrains très concrets : la visibilité dans les moteurs et le chiffre d'affaires généré par le site.
Un signal de classement pour Google
- Depuis 2021, l'expérience sur la page (Page Experience) figure parmi les critères de classement, et les Core Web Vitals en forment la part mesurable.
- Ce n'est pas le facteur décisif : un contenu pertinent et bien structuré reste prioritaire dans l'algorithme.
- À pertinence équivalente, c'est la page la plus rapide qui prend l'avantage, surtout sur les requêtes concurrentielles.
- Google évalue ces scores sur la version mobile de votre site (index mobile-first), pas sur l'affichage ordinateur.
Un levier direct de conversion
- Chaque seconde de chargement supplémentaire fait grimper le taux de rebond : au-delà de 3 secondes, une part notable des visiteurs abandonne avant même de voir la page.
- Sur un site e-commerce, une page produit lente se traduit en paniers abandonnés et en ventes perdues, mois après mois.
- Un CLS élevé provoque des clics par erreur (on valide un bouton qui a bougé), une source de frustration et d'erreurs de commande.
- La performance pèse aussi sur l'image perçue : un site fluide inspire confiance, un site poussif suggère du négligé.
Une exigence renforcée sur mobile
- La majorité du trafic est désormais mobile, sur des appareils moins puissants et des réseaux moins stables que le poste de bureau.
- Un site rapide en Wi-Fi sur un ordinateur récent peut s'avérer pénible sur un smartphone d'entrée de gamme en 4G.
- Testez et optimisez d'abord pour le mobile : c'est la condition que Google retient et celle où se trouvent vos visiteurs.
- Une refonte de site bien menée intègre la performance dès la conception, pas après coup.
Comment mesurer vos Core Web Vitals
Avant d'optimiser, il faut mesurer juste. Deux types de données coexistent et ne disent pas la même chose : il est essentiel de comprendre la différence pour ne pas se tromper de diagnostic.
Données de terrain ou données de laboratoire ?
Les données de laboratoire (lab data) proviennent d'un test simulé, dans des conditions fixes : pratiques pour reproduire un problème et comparer deux versions. Les données de terrain (field data) agrègent les visites réelles de vos utilisateurs. Ce sont ces dernières que Google utilise pour le classement. Un test isolé peut être excellent alors que vos visiteurs, eux, subissent des lenteurs : fiez-vous toujours au terrain pour juger.
PageSpeed Insights
C'est l'outil gratuit le plus accessible. Il combine les deux mondes : en haut, vos données de terrain CrUX si votre page reçoit assez de trafic ; en dessous, une analyse de laboratoire Lighthouse avec un diagnostic détaillé et des recommandations chiffrées. Lancez toujours l'analyse en mode mobile, qui correspond à ce que Google évalue.
Le rapport CrUX et la Search Console
Le Chrome User Experience Report (CrUX) compile l'expérience réelle des internautes utilisant Chrome, sur une fenêtre glissante de 28 jours. C'est la source officielle des Core Web Vitals. Dans la Search Console, le rapport « Signaux web essentiels » s'appuie sur CrUX et regroupe vos URL par état (bonnes, à améliorer, mauvaises), ce qui permet d'agir par lot plutôt que page par page.
Lighthouse et les DevTools de Chrome
Intégré au navigateur (onglet Lighthouse des outils de développement), Lighthouse génère un audit complet en laboratoire. L'onglet Performance, lui, enregistre l'exécution réelle et révèle précisément quelles tâches JavaScript bloquent le thread principal et plombent l'INP. C'est l'outil de prédilection pour creuser une cause une fois le problème localisé.
Interpréter le score sur 100
PageSpeed affiche une note de performance sur 100, commode mais à manier avec prudence : c'est une mesure de laboratoire, pas le critère de classement. Inutile de viser obsessionnellement le 100 parfait. L'objectif réaliste est de faire passer vos trois Core Web Vitals dans le vert sur les données de terrain, pour 75 % de vos visites au moins.
Mesurer dans la durée, pas une seule fois
Les performances dérivent : un nouveau script marketing, une bannière, des images non optimisées ajoutées par un rédacteur, et les scores se dégradent sans prévenir. Surveillez vos Core Web Vitals régulièrement, idéalement après chaque mise en production. C'est un volet à part entière d'une démarche de référencement durable.
Les causes fréquentes de lenteur
Quand un site rame, les responsables sont presque toujours les mêmes. Identifier la bonne cause évite de s'épuiser sur de faux problèmes. Voici les coupables que je rencontre le plus souvent lors d'un audit de performance.
Des images trop lourdes
C'est de loin le frein numéro un, et le plus facile à sous-estimer. Une photo de 4 Mo téléversée telle quelle depuis un appareil, affichée dans un encart de 600 pixels de large, pénalise lourdement le LCP. Les bons réflexes : redimensionner à la taille d'affichage réelle, compresser, et servir des formats modernes comme WebP ou AVIF, deux à trois fois plus légers que le JPEG classique.
Un excès de JavaScript
Plus une page embarque de code à télécharger, analyser et exécuter, plus le navigateur tarde à répondre aux interactions : c'est la première cause d'un mauvais INP. Les bibliothèques surdimensionnées, les sliders gadgets et le code mort accumulé au fil des ans alourdissent inutilement le tout. Souvent, une part importante du JavaScript chargé n'est jamais utilisée sur la page concernée.
Les scripts tiers
Outils de chat, pixels publicitaires, gestionnaires de balises, A/B testing, bannières de consentement : chacun ajoute des requêtes et du code que vous ne maîtrisez pas. Empilés, ces scripts externes ruinent silencieusement la performance. Faites l'inventaire régulièrement et supprimez sans pitié ceux qui ne servent plus à rien.
Un hébergement sous-dimensionné
Un mutualisé bas de gamme met parfois plus d'une seconde à renvoyer la première réponse (le TTFB) : autant de retard pris avant même que le navigateur ne commence à dessiner la page. Sur un site qui génère du chiffre d'affaires, un hébergement à la hauteur est un investissement, pas une dépense superflue.
L'absence de cache et de mise en page stable
Sans cache navigateur ni cache serveur, chaque visite recalcule et retélécharge tout, inutilement. Côté CLS, les images et publicités sans dimensions réservées, ainsi que les polices web mal chargées, font sauter la mise en page. Ces réglages techniques relèvent du travail d'un expert SEO et performance qui connaît la pile sur le bout des doigts.
Les leviers d'optimisation concrets
Une fois le diagnostic posé, voici les actions qui produisent le plus d'effet. Je les classe ici par ordre de rentabilité, du gain le plus rapide au chantier le plus structurant. Inutile de tout faire d'un coup : commencez par ce qui pèse sur votre indicateur le plus dégradé.
Sur les images, redimensionnez à la taille réelle d'affichage, compressez, adoptez le WebP ou l'AVIF, et déclarez toujours les attributs width et height pour stabiliser le CLS. Préchargez l'image LCP avec fetchpriority="high" et activez le lazy loading sur tout ce qui se trouve sous la ligne de flottaison. Sur le JavaScript, supprimez le code inutilisé, différez ou chargez en asynchrone les scripts non critiques, et fractionnez les longues tâches pour rendre la main au navigateur : c'est le meilleur remède contre un mauvais INP.
Côté infrastructure, un hébergement performant, un cache serveur bien réglé et un CDN qui rapproche vos fichiers des visiteurs font chuter le TTFB et donc le LCP. Sur les polices, limitez le nombre de familles et de graisses, préchargez les fichiers essentiels et appliquez font-display: swap pour afficher le texte sans attendre. Enfin, faites la chasse aux scripts tiers superflus, première source de poids invisible. Sur un site existant, une refonte axée performance remet souvent ces fondations à plat plus efficacement qu'une série de rustines.
La performance web n'est pas une course au score parfait sur un outil de test, mais une discipline continue : on mesure sur les vraies visites, on corrige la cause qui pèse le plus, on revérifie après chaque mise en ligne. Un site rapide n'est jamais le fruit du hasard, c'est une exigence tenue dans la durée.
Driss Redouane, expert web indépendant ReydenWeb
Questions fréquentes
Pour aller plus loin
Refonte de site à Bordeaux
Reprendre un site lent ou daté en intégrant la performance dès la conception : la voie la plus efficace pour des Core Web Vitals au vert.
Référencement SEO à Bordeaux
La performance technique s'inscrit dans une stratégie SEO globale : contenu pertinent, structure saine et pages rapides travaillent ensemble.
Guide GEO / AEO
Une fois votre site rapide, rendez-le citable par les moteurs de réponse et les IA : optimisation pour la recherche générative.
Demander un audit de performance
Vous voulez savoir où en sont vos Core Web Vitals et quoi corriger en priorité ? Échangeons directement sur votre site.
Vous comparez des prestataires ?
Discutons-en ensemble.
