Core Web Vitals regroupe trois mesures que Google utilise pour décrire à quel point une page est agréable à utiliser — pas à quoi elle ressemble ni comment elle se lit. Largest Contentful Paint (LCP) chronomètre la vitesse d’affichage du contenu principal. Cumulative Layout Shift (CLS) mesure à quel point la page bouge pendant son chargement. Interaction to Next Paint (INP) mesure la rapidité de réponse de la page dès qu’on clique ou touche quelque chose. Chacune a un seuil publié pour « bon », « à améliorer » et « médiocre ».
Aucune des trois ne mesure si une page convertit, si les textes sont bons ou si le design respecte l’image de marque — seulement si la page est agréable à utiliser sur un vrai appareil, avec une vraie connexion, dès la première visite.
Rien de tout ça n’échappe à un visiteur, même s’il n’a jamais entendu le terme. Une page qui met quatre secondes à afficher son titre paraît lente avant même qu’on en lise un mot. Une page où le bouton « Ajouter au panier » glisse de quelques centimètres vers la droite au moment où on le touche finit par se faire toucher une deuxième fois, sur le mauvais élément. Un menu qui prend une demi-seconde à s’ouvrir après un toucher semble brisé, pas juste lent. Core Web Vitals met des chiffres exactement sur ces trois moments.
Les trois mesures et leurs seuils
Les trois se mesurent de la même façon : au 75e percentile des visites réelles d’une page, suivi séparément pour le mobile et le bureau. Ce détail change ce que le chiffre signifie vraiment. Un site n’est pas noté sur son meilleur chargement ni sur sa moyenne — la barre est fixée par l’extrémité la plus lente de cette distribution : une page réussit seulement si trois visites sur quatre passent sous le seuil, ce qui est beaucoup moins indulgent qu’une moyenne.
“To ensure you’re hitting this target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” (Pour vous assurer d’atteindre cette cible pour la majorité de vos utilisateurs, un bon seuil à mesurer est le 75e percentile des chargements de page, réparti entre les appareils mobiles et de bureau.)
Cette citation vient de la page de web.dev sur Largest Contentful Paint, et la même règle de percentile s’applique aux trois mesures.
| Mesure | Ce qu’elle évalue | Bon | À améliorer | Médiocre |
| LCP — Largest Contentful Paint | Temps avant que le plus grand élément visible termine de s’afficher | 2,5 s ou moins | 2,5–4,0 s | plus de 4,0 s |
| INP — Interaction to Next Paint | Délai entre un toucher et le moment où la page répond visiblement | 200 ms ou moins | 200–500 ms | plus de 500 ms |
| CLS — Cumulative Layout Shift | Combien le contenu visible se déplace sans avertissement | 0,1 ou moins | 0,1–0,25 | plus de 0,25 |
Largest Contentful Paint : la vitesse d’affichage du contenu principal
Le LCP ne porte pas sur le chargement complet de la page — il porte sur le plus grand élément visible pour le visiteur : le plus souvent une image d’en-tête, une image d’aperçu vidéo ou un gros bloc de titre. Le moment où cet élément termine de s’afficher, c’est le chiffre qui compte.
La cause la plus fréquente d’un LCP raté sur le premier écran, c’est le carrousel. Une bannière rotative doit charger plusieurs images (ou une vidéo) avant même que le navigateur puisse déterminer quel élément est le « plus grand », et cette décision retarde l’affichage pour tout le monde, sur tous les appareils, peu importe la vitesse de connexion. Une seule image d’en-tête bien dimensionnée donne au navigateur une chose à afficher plutôt que plusieurs — c’est pourquoi elle bat le carrousel sur ce point, peu importe à quel point le carrousel a l’air réussi.
La correction n’exige pas toujours une refonte. Compresser l’image d’en-tête, la servir dans un format moderne et s’assurer que rien d’autre ne se charge avant elle dans la file peut faire passer le LCP de médiocre à bon sans toucher à la mise en page. C’est seulement quand le plus grand élément est réellement en concurrence avec plusieurs autres pour la même place — un carrousel, une vidéo en arrière-plan, un défilement de témoignages en haut de page — que la correction devient structurelle.
Cumulative Layout Shift : à quel point la page bouge
Le CLS mesure le mouvement, pas la vitesse. Il pénalise une page où le texte saute parce qu’une police web s’est chargée en retard, où un bouton glisse vers le bas parce qu’une bannière est apparue au-dessus, ou où une image fait s’effondrer la mise en page autour d’elle parce que ses dimensions n’étaient pas connues à l’avance.
La cause la plus fréquente qu’on rencontre est une bannière de cookies ou de consentement injectée par un script après que le reste de la page se soit déjà stabilisé. La mise en page semble correcte jusqu’à ce que cette bannière apparaisse et repousse tout ce qui se trouve en dessous de quelques centaines de pixels — et le CLS compte chacun de ces déplacements non annoncés, pendant tout le temps où la page reste ouverte, pas seulement au chargement initial.
Les publicités et les contenus intégrés tiers causent le même problème sous un autre angle. Une publication de réseau social, un widget d’avis ou un espace publicitaire qui ne réserve pas sa taille finale s’insère dans la page après que tout ce qui l’entoure s’est déjà affiché, poussant le reste du contenu vers le bas. Réserver une hauteur fixe pour cet espace avant le chargement du contenu intégré — même vide — élimine le déplacement sans retirer le contenu.
Interaction to Next Paint : la rapidité de réponse de la page
L’INP mesure l’écart entre une action — un clic, un toucher, une touche pressée — et le moment où le navigateur met visiblement à jour l’affichage en réponse. Il ne se limite pas au premier clic d’une visite : il observe les interactions pendant tout le temps que quelqu’un passe sur la page, et retient la plus lente qui compte encore comme typique.
“An INP below or at 200 milliseconds means a page has good responsiveness… An INP above 500 milliseconds means a page has poor responsiveness.” (Un INP à 200 millisecondes ou moins signifie que la page a une bonne réactivité… Un INP au-dessus de 500 millisecondes signifie que la page a une mauvaise réactivité.)
Ce seuil vient directement de la documentation de web.dev sur cette mesure.
L’INP est la plus récente des trois. Elle a remplacé une ancienne mesure appelée First Input Delay en mars 2024 — donc si une liste de vérification ou un vieux billet de blogue mentionne encore le « FID » comme Core Web Vital, ou affirme que le bon seuil est sous 100 millisecondes, c’est qu’il décrit une mesure que Google a retirée.
Sur les pages de commerce en ligne, les interactions qui échouent le plus souvent sont justement les plus importantes commercialement : ajouter un article au panier, ouvrir un filtre de taille ou de couleur, agrandir une image de produit. Si le script derrière l’une de ces actions charge en même temps tout ce dont la page pourrait éventuellement avoir besoin, le clic doit attendre derrière un travail qui n’a rien à voir avec lui.
Un score Core Web Vitals influence-t-il le classement Google ?
Oui, mais pas de la façon dont on le décrit habituellement. Google a été précis là-dessus, publiquement, à plus d’une reprise :
“Core Web Vitals are used by our ranking systems. We recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.” (Core Web Vitals est utilisé par nos systèmes de classement. Nous recommandons aux propriétaires de sites d’obtenir de bons résultats Core Web Vitals pour réussir dans la recherche et pour assurer une excellente expérience utilisateur en général.)
C’est toute l’affirmation, tirée de la documentation de Google sur l’expérience de page : Core Web Vitals n’est qu’un signal parmi d’autres, recommandé surtout pour le visiteur, pas pour le classement. La même page est tout aussi directe sur les limites de ce signal :
“There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.” (Il n’existe pas de signal unique. Nos systèmes de classement principaux examinent une variété de signaux qui correspondent à l’expérience globale de la page.)
Et, quelques lignes plus loin :
“…there’s more to great page experience than Core Web Vitals scores alone.” (…une excellente expérience de page implique davantage que les seuls résultats Core Web Vitals.)
Google n’a jamais publié de poids pour ce facteur, et ne qualifie pas un mauvais résultat de pénalité — il n’y a ni sanction pour un échec, ni promesse de bond dans le classement pour un succès. Corriger les Core Web Vitals vaut la peine parce que ça change ce que vit un visiteur sur votre page. Ce n’est pas un levier garantissant une position.
Pourquoi PageSpeed Insights affiche 92 alors que Search Console est au rouge
C’est l’écart derrière la plupart des questions confuses qu’on reçoit sur ces chiffres, et ce n’est un bogue dans aucun des deux outils — ce sont deux types de mesure différents qui répondent à deux questions différentes.
PageSpeed Insights, lancé à la demande, produit un score de laboratoire : une visite simulée, sur un appareil et une connexion simulés, au moment où vous avez lancé le test. Le rapport Core Web Vitals de Search Console, et les « données de terrain » affichées en haut d’un résultat PageSpeed Insights, proviennent du Chrome UX Report — de vraies visites de vraies personnes, recueillies sur une fenêtre glissante de 28 jours. Une page peut obtenir 92 en laboratoire et quand même apparaître au rouge sur le terrain, pour des raisons qui n’ont rien à voir avec un mensonge de l’un ou l’autre outil :
- Un test en laboratoire tourne habituellement avec un cache vide; le navigateur d’un visiteur qui revient a déjà mis en cache votre logo, vos polices et votre feuille de style — pas celui d’un nouveau visiteur.
- L’élément que le laboratoire identifie comme « le plus grand » n’est pas toujours celui que voient les vrais visiteurs — un fenêtrage différent, un script de personnalisation ou un test A/B peut le remplacer complètement.
- L’INP ne peut tout simplement pas se mesurer en laboratoire, puisqu’aucune vraie personne n’y clique sur rien. Les données de terrain en sont la seule source.
- Sur le terrain, le CLS est suivi pendant tout le temps qu’une vraie page reste ouverte, y compris les déplacements causés par le défilement et par des éléments qui se chargent en retard — le laboratoire ne surveille que le chargement initial.
Les systèmes de classement regardent le chiffre de terrain, pas celui du laboratoire. Un score de laboratoire de 92 est un diagnostic utile — il indique où chercher — mais ce n’est pas le score sur lequel qui que ce soit d’autre est jugé, et ce n’est pas la preuve qu’un vrai visiteur a trouvé la page utilisable.
Ce qui fait habituellement échouer chaque mesure — et comment la corriger
Une mesure au rouge n’exige pas toujours le même genre de travail. Parfois, c’est un simple réglage à changer. Parfois, ça veut dire reconstruire une section. Parfois, ça ne se corrige pas sans changer l’hébergement du site.
| Mesure | Cause typique | Se corrige habituellement par |
| LCP | Carrousel ou vidéo d’en-tête chargeant plusieurs ressources avant que le navigateur puisse afficher quoi que ce soit | Reconstruction du premier écran |
| LCP | Polices, scripts de suivi ou feuille de style complète d’un constructeur de pages qui se chargent avant le contenu visible | Réglages ou construction |
| CLS | Bannière de cookies ou de consentement injectée sans espace réservé | Réglages |
| CLS | Images, publicités ou contenus intégrés sans largeur ni hauteur définies | Construction |
| INP | Thème ou constructeur qui exécute toute sa bibliothèque de scripts à chaque clic au lieu du strict nécessaire | Construction |
| INP | Widgets de clavardage, trackers lourds ou scripts tiers qui se disputent le même fil d’exécution | Réglages — retirer ou différer |
| Les trois | Hébergement partagé qui ralentit sous un trafic normal | Hébergement |
Lire un rapport ligne par ligne ne donne que le symptôme. Savoir si ce symptôme se règle en cinq minutes ou exige de reconstruire une section, c’est ce qu’aucune liste de vérification ne peut déterminer à votre place — et c’est toute la différence entre une petite correction et un vrai projet.
Comment tester les Core Web Vitals de votre propre site
Deux outils gratuits couvrent presque tout le monde :
- PageSpeed Insights — collez une adresse URL, obtenez un score de laboratoire immédiatement, et des données de terrain si la page a assez de trafic pour en générer.
- Le rapport Core Web Vitals dans Search Console — regroupe vos pages par gabarit et indique lesquelles sont Bonnes, À améliorer ou Médiocres, en utilisant la même fenêtre de 28 jours que les systèmes de classement de Google.
Si un site tout neuf, ou une page à faible trafic, n’affiche aucune donnée de terrain dans aucun des deux outils, ce n’est pas un bris — c’est normal. Le Chrome UX Report a besoin d’un volume minimal de vraies visites avant de rapporter quoi que ce soit pour une page donnée; une page lancée la semaine dernière, ou qui reçoit une poignée de visites par mois, n’a tout simplement pas encore accumulé assez de trafic. Testez-la en laboratoire, regardez les données de terrain se remplir à mesure que le trafic augmente, et ne lisez pas un rapport de terrain vide comme un échec.
Où on voit ces chiffres avant qu’ils deviennent un problème
On voit les Core Web Vitals bien avant qu’un client ouvre un rapport à leur sujet, parce que les décisions qui déterminent le LCP et le CLS sont de toute façon des décisions qu’on prend en construisant un premier écran : une seule image d’en-tête plutôt qu’un carrousel, une bannière de cookies avec son espace réservé dès le départ, un menu qui ne traîne pas tout un lot de scripts juste pour s’ouvrir. Bien prendre ces décisions à la construction est un travail très différent de les diagnostiquer après coup sur une page dont personne n’a pensé la structure au départ.
C’est aussi là que la réponse honnête n’est parfois pas un réglage du tout. Si un LCP ou un CLS lent vient de la façon dont une page est construite plutôt que de sa configuration, ajuster les réglages sur cette structure a un plafond, et les gabarits assez vieux pour l’atteindre coûtent souvent moins cher à reconstruire qu’à continuer de rafistoler — nos propres sites partent à 1 900 $ pour jusqu’à huit pages, rédaction incluse. Cet ordre des opérations, et le point où reconstruire l’emporte sur d’autres ajustements, c’est le sujet de l’ordre des correctifs de vitesse. Si la plateforme en dessous est WordPress en particulier, les causes qui lui sont propres sont couvertes dans l’optimisation de la vitesse WordPress.
Si la page en question reçoit du trafic payant, un mauvais score Core Web Vitals se répercute aussi directement dans Google Ads, dans le cadre de l’évaluation de l’expérience de la page de destination — ce qui fait grimper ce que vous payez par clic avant même qu’un visiteur atteigne la page. Et si vous construisez une nouvelle page de destination à partir de zéro, les mêmes décisions de premier écran couvertes ici représentent la moitié de ce qui sépare une page qui donne de bons résultats d’une page qui a simplement l’air finie.
On construit des sites web d’entreprise plutôt que d’écrire des rapports à leur sujet, c’est pourquoi ces chiffres surgissent de notre côté dès l’étape de conception, pas des mois plus tard dans un audit.
Passez d’abord votre propre adresse dans PageSpeed Insights ou dans le rapport Core Web Vitals de Search Console — les données de terrain, pas le score de laboratoire. Si le résultat revient au rouge et que vous voulez un second avis pour savoir si c’est un réglage ou un problème de structure, envoyez-la-nous.
