Core Web Vitals : les 3 seuils et par quoi commencer

Les Core Web Vitals se résument à trois chiffres : un Largest Contentful Paint sous 2,5 secondes, une Interaction to Next Paint sous 200 millisecondes et un Cumulative Layout Shift sous 0,1. Trois conditions s’y ajoutent, et ce sont elles qui font la différence entre un site qui passe et un site qui croit passer : la mesure porte sur les visites réelles de vos utilisateurs, elle retient le 75e centile de ces visites, et elle évalue le mobile et l’ordinateur séparément.

Autrement dit, il ne suffit pas que la page soit rapide sur votre machine. Il faut qu’elle le soit pour trois visiteurs sur quatre, sur leur téléphone, avec leur connexion. Cet article explique ce que chaque indicateur mesure, pourquoi le score que vous voyez dans votre navigateur ne veut presque rien dire, et dans quel ordre corriger.

Les trois seuils, et ce qu’ils mesurent réellement

Google publie ces trois indicateurs sous le nom de Web Vitals. Ils couvrent trois dimensions distinctes de l’expérience : la vitesse d’affichage, la réactivité et la stabilité visuelle. Un site peut très bien exceller sur l’une et échouer sur les deux autres.

LCP : le temps d’affichage du plus gros élément

Le Largest Contentful Paint mesure le moment où le plus grand élément visible de la page apparaît à l’écran. En pratique, c’est presque toujours l’image d’en-tête, la vidéo de couverture ou le gros bloc de titre. Le seuil est de 2,5 secondes.

Ce que cet indicateur capture, c’est la question que se pose l’internaute pendant le chargement : est-ce que quelque chose d’utile est arrivé ? Un site qui affiche un fond blanc pendant quatre secondes puis tout d’un coup a un mauvais LCP, même si le total est identique à un site qui affiche progressivement.

INP : la réactivité quand on clique

L’Interaction to Next Paint mesure le délai entre une action de l’utilisateur et le moment où l’écran se met à jour en réponse. Il a remplacé le First Input Delay en mars 2024, et il est plus sévère : là où le précédent ne mesurait que le premier clic, celui-ci observe toutes les interactions de la visite. Le seuil est de 200 millisecondes.

La documentation détaille trois phases dans chaque interaction : le délai d’entrée avant que le code ne soit exécuté, la durée de traitement des fonctions déclenchées, et le délai de présentation avant que l’image suivante ne soit affichée. Savoir laquelle des trois domine change complètement le correctif à apporter.

CLS : la stabilité visuelle

Le Cumulative Layout Shift mesure les décalages inattendus de la mise en page pendant le chargement. Le seuil est de 0,1, et le calcul mérite d’être connu : ce n’est pas la somme de tous les décalages, mais la rafale la plus élevée. Une rafale regroupe les décalages séparés de moins d’une seconde, dans une fenêtre de cinq secondes maximum.

Les décalages provoqués par une action de l’utilisateur ne comptent pas, à condition de survenir dans les 500 millisecondes suivant l’interaction. Ouvrir un menu déroulant ne pénalise donc pas votre score. Une bannière de consentement qui s’insère toute seule après deux secondes, si.

Le piège numéro un : le score de votre navigateur n’est pas votre note

C’est la confusion la plus fréquente, et elle fait perdre des semaines. L’outil Lighthouse intégré à Chrome, comme l’onglet de gauche de PageSpeed Insights, produit une mesure dite de laboratoire : une simulation, sur une machine et une connexion simulées, à un instant donné. Le score sur 100 qui en sort n’est pas votre note Core Web Vitals.

Ce qui compte est la mesure de terrain, issue du Chrome UX Report, qui agrège les visites réelles des utilisateurs de Chrome ayant accepté le partage de statistiques. C’est cette source qu’utilisent la Search Console et le bloc supérieur de PageSpeed Insights. Trois conséquences pratiques.

• La donnée est glissante sur 28 jours. Une correction déployée aujourd’hui met environ quatre semaines à se refléter pleinement. Ne jugez pas un correctif au bout de trois jours.
• Un site à faible trafic peut ne pas avoir de données du tout. Le rapport exige un volume de visites suffisant pour être statistiquement significatif. En dessous, la Search Console reste vide et il faut se rabattre sur la mesure de laboratoire, en sachant qu’elle est indicative.
• Le 75e centile autorise 25 % de mauvaises visites. Le seuil est franchi dès que trois visites sur quatre sont bonnes. Ce choix est documenté par Google dans sa note sur la définition des seuils : il s’agit d’un compromis entre exigence et réalisme.

Trois outils, trois usages

La Search Console donne la vérité de terrain, groupée par gabarit de page : c’est là qu’on décide quoi corriger. PageSpeed Insights combine les deux mesures sur une URL précise, avec les données de terrain en haut et la simulation en bas : c’est là qu’on comprend pourquoi. L’extension Web Vitals pour Chrome affiche les trois indicateurs en direct pendant que vous naviguez : c’est là qu’on vérifie un correctif avant de le déployer, sans attendre quatre semaines.

Par quoi commencer, concrètement

L’ordre qui fait gagner le plus de temps consiste à traiter d’abord l’indicateur en échec sur mobile, puis à décomposer avant de corriger. Corriger sans décomposer, c’est optimiser au hasard.

Décomposer le LCP en quatre segments

La documentation d’optimisation du LCP découpe le délai en quatre parties, avec une répartition cible. Le temps de réponse du serveur, ou TTFB, devrait représenter environ 40 % du total. Le délai avant que le navigateur ne commence à charger la ressource, moins de 10 %. Le chargement de la ressource elle-même, environ 40 %. Le délai de rendu final, moins de 10 %.

Cette grille désigne le coupable en une minute. Un TTFB qui pèse 70 % renvoie vers l’hébergement, la base de données ou le cache, et c’est là qu’un CDN change la donne. Un chargement de ressource qui domine renvoie vers le poids de l’image d’en-tête, sujet que nous détaillons dans notre article sur la réduction du poids des images. Un délai de rendu élevé pointe vers une police personnalisée qui bloque l’affichage, ou un composant qui attend du JavaScript avant de peindre.

Trois corrections couvrent la majorité des cas : ne jamais mettre l’image d’en-tête en chargement différé, la servir en WebP ou en AVIF à la bonne dimension, et précharger la ressource identifiée comme élément LCP.

Situer l’INP dans ses trois phases

Un INP dégradé vient presque toujours du même endroit : trop de JavaScript exécuté sur le fil principal au moment où l’utilisateur clique. Le guide d’optimisation de l’INP recommande de découper les tâches longues, de reporter ce qui n’est pas nécessaire à l’interaction immédiate, et de rendre la main au navigateur pour qu’il puisse peindre.

Sur un site vitrine, le premier suspect n’est pas votre code mais les scripts tiers : gestionnaire de balises, chat, tests A/B, pixels publicitaires. Le test décisif consiste à recharger la page sans eux et à comparer. Si l’INP s’effondre, la discussion devient une discussion de priorités marketing, pas de technique.

Traquer les trois causes du CLS

Le guide dédié au CLS ramène l’essentiel à trois causes. Les images et les vidéos sans dimensions déclarées, qui poussent le contenu vers le bas en arrivant : renseigner les attributs de largeur et de hauteur suffit à réserver la place. Les contenus injectés au-dessus du contenu existant, bannières et bandeaux, à qui il faut réserver un espace ou qu’il faut afficher en superposition. Et les polices personnalisées qui provoquent un ressaut typographique au moment de leur chargement.

Le CLS est l’indicateur le moins coûteux à corriger et celui qui se voit le plus. Sur un tunnel de commande, un bouton qui se décale au moment précis du clic ne dégrade pas seulement un score : il coûte des commandes, comme nous l’expliquons dans notre article sur l’augmentation du taux de conversion.

Le cas particulier des sites no-code

Une plateforme hébergée comme Webflow ou Framer prend en charge une partie du travail sans que vous ayez à intervenir : réseau de diffusion de contenu, compression des réponses, images servies en plusieurs tailles, certificat et mise en cache. Sur le papier, le socle technique est sain, et c’est un vrai avantage de départ que nous détaillons dans notre article sur le CMS Webflow.

Ce que la plateforme ne fait pas à votre place, en revanche, se résume à quatre choses, et ce sont exactement celles qui font échouer les Core Web Vitals. Le poids des visuels que vous téléversez, parce qu’aucun outil ne redimensionne une photo de 4 000 pixels de large que vous affichez sur 800. Le nombre de polices personnalisées et de graisses, chacune étant un fichier à télécharger avant que le texte ne s’affiche proprement. Les scripts tiers ajoutés dans les paramètres du projet, qui pèsent directement sur l’INP. Et les animations au défilement, séduisantes en démonstration, coûteuses quand elles s’exécutent pendant le chargement.

Trois règles suffisent à tenir les seuils sur ce type de site : redimensionner les images avant téléversement plutôt qu’après, se limiter à deux graisses de police, et tenir la liste des scripts tiers avec, en face de chacun, la personne qui l’a demandé. Cette dernière colonne est la plus utile le jour où il faut arbitrer.

Ce que les Core Web Vitals ne feront pas pour vous

Une mise au point honnête évite beaucoup de déceptions. Google écrit dans sa documentation Search que de bons Core Web Vitals, avec les autres aspects de l’expérience de page, « correspondent à ce que nos systèmes de classement cherchent à récompenser ». La formulation est prudente, et elle est à prendre au pied de la lettre.

Concrètement : passer de rouge à vert ne fera pas remonter une page dont le contenu ne répond pas à la requête. En revanche, à pertinence comparable, l’expérience de page départage. Et surtout, l’effet le plus mesurable ne se joue pas dans le classement mais dans le comportement : moins d’abandons avant affichage, plus de pages vues par session, un tunnel qui va au bout.

Voyez donc ces trois seuils comme un critère de qualité opposable, pas comme un levier de référencement. C’est d’ailleurs leur meilleur usage : les inscrire dans un cahier des charges, où ils remplacent avantageusement l’adjectif « rapide ».

Une méthode en cinq étapes

• Partir de la Search Console, pas d’un outil tiers. Le rapport Signaux web essentiels groupe vos URL par similarité et distingue mobile et ordinateur. C’est la source qui fait foi.
• Traiter le mobile en premier. C’est presque toujours lui qui échoue, et c’est aussi lui que Google utilise pour indexer vos pages.
• Décomposer avant de corriger. Les quatre segments du LCP, les trois phases de l’INP, la rafale de décalages la plus élevée pour le CLS.
• Corriger un groupe d’URL à la fois. Les pages d’un même gabarit partagent leurs défauts. Corriger le gabarit corrige des centaines de pages.
• Attendre quatre semaines avant de conclure. La fenêtre glissante de 28 jours impose ce délai. Entre-temps, la mesure de laboratoire sert à vérifier que le correctif fait ce qu’on attend.

Ce que nous en faisons chez Scroll

Nous inscrivons ces trois seuils dans les cahiers des charges, et nous les vérifions à la recette sur un vrai téléphone plutôt que sur un poste de développement. C’est un point que nous détaillons dans nos articles sur la refonte de site et sur les améliorations à apporter à un site existant.

Si vos indicateurs sont au rouge et que vous ne savez pas par quel bout prendre le sujet, le diagnostic tient généralement en une demi-journée : identifier le gabarit fautif, décomposer l’indicateur en échec, et sortir une liste de corrections classée par gain. Parlons-en.