Core Web Vitals : diagnostiquer et corriger vos pages
Ce qu’il faut retenir
- Les Core Web Vitals sont trois mesures d’expérience de page : l’affichage du contenu principal (LCP), la réactivité à l’interaction (INP) et la stabilité visuelle (CLS).
- Les valeurs cibles publiées par Google sont 2,5 secondes, 200 millisecondes et 0,1, appréciées au 75e centile des visites réelles (documentation Web Vitals, Google).
- Le verdict se joue sur les données de terrain, jamais sur le score de laboratoire affiché par un outil d’audit.
- Trois causes expliquent la plupart des dépassements : un serveur qui répond tard, des images et des polices mal livrées, des scripts tiers ajoutés sans arbitrage.
- Corriger n’impose pas une refonte : l’ordre des chantiers pèse plus lourd que leur ampleur.
Un site d’entreprise ne bascule pas au rouge du jour au lendemain. Il se dégrade balise après balise : un outil de mesure ici, un bandeau de consentement là, une bannière qui pousse le contenu vers le bas. Six mois plus tard, trois URL sur quatre sont hors seuil.
Core Web Vitals : que mesure Google exactement ?
Les Core Web Vitals sont trois mesures que Google collecte sur les visites réelles d’un site pour qualifier l’expérience de page. Elles portent sur ce que le visiteur perçoit : le moment où le contenu principal apparaît, le délai de réponse après un clic, les déplacements d’éléments pendant le chargement. Aucune ne juge la qualité du code.
Core Web Vitals est le nom des trois mesures retenues par Google
Core Web Vitals est le nom donné par Google à un sous-ensemble stable de trois indicateurs de performance web, communs à tous les sites. Le reste de la famille Web Vitals — temps de réponse serveur, premier affichage — sert au diagnostic, pas au verdict.
La distinction compte en comité de pilotage : trois seuils et trois chantiers se pilotent, dix courbes noient la décision.
Données de terrain et données de laboratoire : deux lectures à ne pas confondre
Les données de terrain proviennent du Chrome User Experience Report (rapport d’expérience utilisateur de Chrome), qui agrège les visites réelles sur une fenêtre glissante de vingt-huit jours, d’après la documentation de Google. Ce sont elles, et elles seules, qui déterminent si une page est conforme.
Les données de laboratoire viennent d’un outil qui charge la page dans des conditions simulées : Lighthouse, intégré à PageSpeed Insights et aux navigateurs. Elles servent à reproduire un problème et à vérifier un correctif.
Le 75e centile, la règle qui décide du verdict
Un seuil n’est pas une moyenne. Google retient le 75e centile : il faut que trois visites sur quatre respectent la valeur cible pour qu’une page soit considérée comme bonne.
LCP, INP, CLS : les trois seuils à tenir
Google publie trois valeurs cibles : 2,5 secondes pour le LCP, 200 millisecondes pour l’INP et 0,1 pour le CLS, appréciées au 75e centile des visites (documentation Web Vitals de Google). Chacune décrit un moment différent de la visite.
LCP : afficher le contenu principal en moins de 2,5 secondes
Le Largest Contentful Paint (affichage du plus grand élément) mesure le délai avant que le bloc visuel principal apparaisse : le plus souvent l’image d’en-tête, ou le titre sur une page d’article. Entre 2,5 et 4 secondes, Google classe la page « à améliorer » ; au-delà, « médiocre ».
INP : répondre à une interaction en moins de 200 millisecondes
L’Interaction to Next Paint (délai jusqu’au prochain affichage) mesure le temps entre un clic, un appui ou une frappe et le premier retour visuel. Il a remplacé le First Input Delay comme signal officiel en mars 2024, d’après l’annonce publiée par Google.
Le changement n’a rien de cosmétique : le First Input Delay ne regardait que la première interaction, l’INP retient la pire de la visite. Un menu qui met une seconde à s’ouvrir suffit à faire sortir la page du seuil.
CLS : empêcher la page de bouger sous le doigt
Le Cumulative Layout Shift (décalage cumulé de mise en page) additionne les déplacements d’éléments survenus sans action du visiteur. Le seuil est 0,1, une valeur sans unité.
C’est le seul des trois que l’on ressent physiquement : vous visez un lien, une bannière s’insère, vous cliquez ailleurs. Les coupables récurrents sont les images sans dimensions déclarées, les polices substituées après coup et les encarts injectés après le rendu.
Il se corrige en réservant l’espace à l’avance, ce qui se décide au moment de la conception des gabarits d’interface, pas après la mise en ligne.
| Signal | Ce que vit le visiteur | Valeur cible au 75e centile |
|---|---|---|
| LCP — affichage du plus grand élément | Le contenu principal met du temps à apparaître | 2,5 secondes ou moins |
| INP — délai jusqu’au prochain affichage | La page tarde à réagir au clic ou à l’appui | 200 millisecondes ou moins |
| CLS — décalage cumulé de mise en page | Les éléments bougent pendant la lecture | 0,1 ou moins |
| TTFB — temps de réponse du serveur | Rien ne s’affiche après la saisie de l’adresse | Indicateur de diagnostic, sans seuil de classement |
| Score Lighthouse sur 100 | Aucun : mesure simulée, pas une visite | Outil de diagnostic, sans effet sur le verdict |
Pourquoi un site d’entreprise dépasse les seuils Core Web Vitals
Trois causes expliquent l’essentiel des dépassements constatés sur les sites d’ETI et de grands comptes : un hébergement sous-dimensionné, des médias livrés sans règle, et une accumulation de scripts tiers que personne n’a jamais arbitrée.
Un temps de réponse serveur qui part trop tard
Tant que la première réponse n’arrive pas, le navigateur n’a rien à afficher. Un hébergement mutualisé, une base de données non optimisée ou l’absence de cache de pages consomment la moitié du budget LCP avant le premier octet utile.
C’est le correctif le moins visible et le plus rentable : dimensionner l’hébergement et activer un cache de pages règle une partie du problème sans toucher au design. Sur un site publié sous WordPress, le gain se mesure dès la première semaine.
Des images et des polices livrées sans discipline
Une photographie d’en-tête exportée à 3 000 pixels de large et servie telle quelle à un téléphone, c’est un budget LCP consommé par un seul fichier. Formats modernes, redimensionnement côté serveur et chargement différé des images hors écran traitent la majorité des cas.
Les polices de caractères posent le problème inverse : chargées tard, elles provoquent un changement d’apparence qui alimente le CLS. Les précharger et déclarer une police de substitution aux métriques proches supprime l’à-coup.
Les scripts tiers : balises marketing, bandeau de consentement, messagerie
Chaque outil ajouté par une équipe laisse du code à exécuter dans le navigateur du visiteur : mesure d’audience, test A/B, carte de chaleur, messagerie, pixels publicitaires. Pris un par un, aucun ne pose problème ; additionnés sur cinq ans, ils dominent l’INP. L’arbitrage n’est donc pas technique, il est marketing.
Vos pages sortent des seuils et personne ne sait par quel bout commencer ? Envoyez-nous trois adresses représentatives de votre site : nous vous renvoyons les trois correctifs à engager en premier, chiffrés en jours.
Dans quel ordre corriger, et avec quel effort ?
L’ordre compte davantage que l’ampleur. On mesure d’abord sur les données de terrain, on corrige ensuite les causes communes à plusieurs gabarits, et on ne descend au détail qu’en dernier.
Mesurer avant de corriger : trois outils, trois usages
La Search Console donne la vue de terrain par groupe d’adresses et désigne les familles de pages hors seuil. PageSpeed Insights affiche, pour une adresse donnée, les deux lectures côte à côte. Lighthouse, dans le navigateur, sert à reproduire un problème et à vérifier un correctif.
Commencez par la Search Console : optimiser une page prise au hasard, c’est travailler sur un gabarit qui n’est peut-être pas celui qui pénalise le site.
Les correctifs qui rapportent le plus pour le moins d’effort
Quatre chantiers règlent la majorité des situations : activer un cache de pages et un réseau de diffusion de contenu, servir les images au bon format et à la bonne taille, réserver l’espace des blocs insérés après le rendu, différer les scripts tiers non essentiels au premier affichage.
Aucun ne suppose de refondre le site. Tous se mènent gabarit par gabarit, ce qui permet de mesurer l’effet avant de passer au suivant. Un audit de site web en neuf points de contrôle fixe cet ordre de bataille.
Optimiser l’existant ou refondre : comment trancher
La question se tranche sur l’origine du problème. Si les dépassements viennent de l’hébergement, des médias ou des scripts, l’optimisation suffit. S’ils viennent du socle — thème surchargé, constructeur de pages qui regénère du code à chaque affichage — chaque correctif sera repris au chantier suivant.
Dans ce second cas, la performance devient un argument de plus dans un dossier de refonte, rarement le seul. Notre méthode complète de création et refonte de site web place la mesure des trois signaux au cadrage, avant le choix des gabarits.
Core Web Vitals et référencement : ce que la performance change
Google compte l’expérience de page parmi ses signaux de classement, sans en faire un facteur dominant. La performance ne compense pas un contenu faible ; elle départage des pages comparables, sur des requêtes où plusieurs contenus se valent.
Un critère de classement réel, mais secondaire face à la pertinence
La documentation de Google Search Central décrit l’expérience de page comme un ensemble de signaux pris en compte au classement, la pertinence restant première. Une page lente qui répond exactement à la question posée garde sa position devant une page rapide qui répond à côté.
Ce que les seuils changent pour vos équipes dans la durée
Le point dur n’est pas la mise à niveau, c’est le maintien. Un site conforme en janvier 2026 ressort des seuils six mois plus tard si chaque campagne ajoute sa balise. Rattacher ce contrôle au contrat de tierce maintenance applicative évite le glissement.
Chez Venise Activation, agence marketing et digitale indépendante basée à Paris depuis 1989, nous inscrivons les trois seuils dans le cahier des charges et les vérifions à la recette : un gabarit hors seuil ne passe pas en production. Le cadre vaut pour tout projet de création de site internet comme pour une refonte.
Core Web Vitals : questions fréquentes des directions marketing
Comment savoir si mon site respecte les Core Web Vitals ?
Ouvrez le rapport « Signaux web essentiels » de la Google Search Console : il classe vos adresses par groupe de pages et signale celles qui sortent des seuils, à partir des visites réelles. PageSpeed Insights complète la lecture adresse par adresse. Commencez par la Search Console : elle désigne le gabarit en cause, pas une page isolée.
Quelle différence entre le score PageSpeed et les Core Web Vitals ?
Le score sur cent affiché par PageSpeed Insights vient de Lighthouse, qui charge la page dans des conditions simulées : c’est un diagnostic. Les Core Web Vitals proviennent des visites réelles collectées par le Chrome User Experience Report et décident seuls du verdict. Un score de laboratoire élevé avec des données de terrain au rouge est courant.
Combien de temps faut-il pour corriger des Core Web Vitals hors seuil ?
Les correctifs d’infrastructure — cache de pages, réseau de diffusion, dimensionnement de l’hébergement — produisent un effet mesurable en quelques jours. Les corrections de gabarit, images et polices comprises, se comptent en semaines. Comptez ensuite vingt-huit jours avant que les données de terrain reflètent le gain : elles reposent sur une fenêtre glissante de cette durée.
Par où commencer si toutes mes pages sont au rouge ?
Par le temps de réponse du serveur, puis par le gabarit qui porte le plus de trafic. Un site entièrement hors seuil a presque toujours une cause commune à toutes ses pages : hébergement sous-dimensionné, absence de cache, script bloquant appelé dans l’en-tête. La traiter fait basculer des familles entières de pages.
Est-ce que je dois refondre mon site pour passer les Core Web Vitals ?
Rarement. Si les dépassements viennent de l’hébergement, des images ou des scripts tiers, l’optimisation de l’existant suffit et coûte une fraction d’une refonte. La refonte se justifie quand le socle produit le problème : thème surchargé, constructeur de pages qui génère du code à chaque affichage. Posez le diagnostic avant d’arbitrer le budget.
Les Core Web Vitals comptent-ils autant sur mobile que sur ordinateur ?
Google évalue les deux séparément et affiche deux verdicts distincts dans la Search Console. Le mobile est le plus souvent le maillon faible : réseau variable, appareil moins puissant, écran étroit qui rend les décalages plus visibles. Si vous devez arbitrer, traitez le mobile en premier.
Un site conforme aux Core Web Vitals ne se remarque pas : les pages s’affichent, les boutons répondent, rien ne bouge sous le doigt. L’objectif est l’absence d’irritant, pas une courbe de plus. Venise Activation, agence indépendante à Paris depuis 1989 publie régulièrement sur ces arbitrages de projet web.
Une refonte prévue dans les prochains mois ? Prenez trente minutes avec nos consultants avant d’arrêter les gabarits : c’est le moment où la performance coûte le moins cher à obtenir.
