Ce que recouvrent réellement les Core Web Vitals en 2026
Il y a une ligne, dans à peu près tous les devis web qui circulent, qui ne veut rien dire. Elle se lit « site optimisé pour la vitesse ». Parfois « performances web optimisées ». Elle passe inaperçue parce qu'elle rassure, et elle ne coûte rien à écrire.
Le reste du document, lui, est parfaitement lisible pour un dirigeant : un nombre de pages, un design, un module de paiement, une formation à l'outil. Des choses qu'on sait relire, comparer, contester. La performance technique, elle, échappe à cette lecture. Personne ne demande à un prestataire de chiffrer un LCP. Et trois mois après la mise en ligne, quand les données terrain remontent enfin dans la Search Console, le site échoue au champ Core Web Vitals alors qu'il a été livré « conforme au cahier des charges ».
La conformité était réelle. Le cahier des charges, lui, ne disait rien.
Cet article propose de sortir de là. Non pas en réclamant qu'un prestataire « promette un site rapide », ce qui n'a jamais engagé personne, mais en passant à quelque chose de mesurable : des seuils chiffrés, sur des gabarits désignés, mesurés avec un outil nommé, à une date convenue. Avec ce qu'il faut savoir des métriques, les questions à poser pendant la consultation, la formulation contractuelle qui tient, et le protocole de recette.
LCP, INP, CLS : les trois signaux qui comptent
Trois métriques, pas plus. C'est déjà assez pour s'y perdre, alors autant les prendre une par une.
Le LCP (Largest Contentful Paint) mesure le temps d'affichage du plus gros élément visible à l'écran. Seuil de validation : 2,5 secondes. Entre 2,5 et 4 secondes, la zone est dite « à améliorer », au-delà de 4 secondes c'est mauvais. Dans la quasi-totalité des cas observés, le coupable est le même trio : une image de bandeau trop lourde, un titre H1 bloqué par le chargement d'une police, ou un temps de réponse serveur dégradé en amont.
L'INP (Interaction to Next Paint) mesure la réactivité. Combien de temps s'écoule entre le clic de l'internaute et le moment où l'écran répond ? Seuil : 200 millisecondes. Au-delà de 500 ms, l'échec est net. Cette métrique a remplacé le FID en mars 2024 et le changement n'a rien d'anecdotique : le FID ne regardait que la première interaction, l'INP les regarde toutes. Beaucoup de sites qui passaient tranquillement l'ancienne métrique se sont retrouvés dans le rouge du jour au lendemain, sans avoir changé une ligne de code.
Le CLS (Cumulative Layout Shift) quantifie les décalages visuels pendant le chargement. Seuil : 0,1. C'est la métrique la plus intuitive, celle que tout le monde a vécue : on s'apprête à cliquer sur un lien, une bannière s'insère au-dessus, et le doigt atterrit sur une publicité. Bandeaux de consentement, images sans dimensions déclarées, polices qui basculent en cours de route.
Un point mérite d'être souligné, parce qu'il change tout dans une discussion contractuelle : la validation se fait au 75e centile des visites, pas sur une moyenne. Autrement dit, il faut que trois quarts des visiteurs réels soient sous le seuil. Un site « rapide en moyenne » peut parfaitement échouer, parce que la moyenne écrase les mauvaises expériences alors que le centile les expose.
| Métrique | Seuil de validation | Cause principale observée | Responsable typique |
|---|---|---|---|
| LCP | ≤ 2,5 s | Image de bandeau non optimisée, TTFB dégradé, police bloquante | Prestataire (intégration + hébergement) |
| INP | ≤ 200 ms | Scripts tiers, JavaScript non découpé, gestionnaires d'événements lourds | Partagé (scripts imposés par le client) |
| CLS | ≤ 0,1 | Bandeau de consentement, images sans dimensions, publicités insérées | Prestataire (structure) + client (contenus ajoutés) |
Les métriques de diagnostic à ne pas confondre avec les seuils
Autour de ces trois signaux gravite une petite famille d'indicateurs qu'on croise dans tous les rapports d'audit : le TTFB (temps de réponse serveur), le FCP (premier affichage), le TBT (temps de blocage total). Ils sont utiles. Ils sont même indispensables au prestataire pour comprendre d'où vient un problème et le corriger.
Mais ce ne sont pas des critères de recette.
La nuance est technique et elle a des conséquences très concrètes. Le TBT est une métrique de laboratoire : elle n'existe que dans une simulation. L'INP, lui, est une métrique de terrain, calculée sur les visites réelles. Un devis qui s'engage sur un TBT inférieur à 200 ms s'engage donc sur un résultat de simulation, pas sur l'expérience des internautes. Techniquement irréprochable, contractuellement creux. Ce n'est pas forcément de la mauvaise foi, d'ailleurs. C'est souvent une confusion sincère entre les outils qu'on utilise pour travailler et les indicateurs sur lesquels Google juge.
Données terrain contre données de laboratoire
Voilà le point qui mérite d'être compris avant toute négociation, parce qu'il détermine la date à laquelle on peut vérifier quoi que ce soit.
Lighthouse simule un appareil et une connexion. Le test est reproductible, immédiat, disponible sur n'importe quelle URL, y compris une préproduction. Son défaut est dans sa qualité : c'est une fiction. Un appareil moyen théorique, un réseau théorique, aucun cache navigateur, aucun comportement humain.
CrUX (Chrome User Experience Report) agrège les visites réelles des utilisateurs Chrome sur une fenêtre glissante de 28 jours. C'est cette source que Google utilise pour le signal d'expérience de page. Deux contraintes en découlent : un décalage d'environ un mois, et un seuil de trafic minimal en dessous duquel le site n'apparaît tout simplement pas dans le rapport.
L'implication pour un contrat est majeure, et pourtant elle est rarement anticipée : un site neuf n'a pas de données CrUX. À la livraison, on ne peut vérifier que du laboratoire. La vérification terrain, celle qui compte vraiment aux yeux de Google, ne devient possible qu'à J+60 ou J+90. Si la garantie contractuelle s'arrête à trente jours, elle expire précisément avant que la mesure utile ne soit disponible. Le calendrier joue contre le client, mécaniquement.
Dernier piège, et non des moindres : le fameux score sur 100 affiché par PageSpeed Insights. Ce n'est pas une métrique. C'est une pondération de plusieurs mesures de laboratoire, avec des coefficients qui ont déjà changé plusieurs fois selon les versions du moteur. Un prestataire peut travailler ce score, l'amener à 95, et n'avoir strictement rien amélioré pour les visiteurs réels. Contractualiser sur ce score revient à contractualiser sur un résultat d'examen blanc.
Pourquoi la performance disparaît des devis
Les quatre formulations qui n'engagent à rien
Elles reviennent tellement souvent qu'on peut les lister de mémoire.
« Site optimisé pour la vitesse ». Aucun seuil, aucun outil, aucune date. C'est une intention.
« Score PageSpeed supérieur à 90 ». Mieux, en apparence, parce qu'il y a un chiffre. Sauf que : sur quelle page ? Le score de l'accueil n'a rien à voir avec celui d'une fiche produit chargée en scripts. Sur quel appareil ? Mobile ou ordinateur, l'écart est souvent de trente points. À quelle date, avec quelle version du moteur Lighthouse ? Chaque mise à jour redistribue les cartes. Quatre questions sans réponse pour un seul chiffre.
« Conforme aux bonnes pratiques Google ». Il n'existe pas de référentiel unique et opposable derrière cette phrase. On y met ce qu'on veut.
« Optimisation SEO technique incluse ». La ligne fourre-tout par excellence, celle qui absorbe l'audit, les corrections et le suivi sans chiffrer aucun des trois. Et surtout, celle qui empêche de savoir ce qui a été fait, puisque rien n'est isolé.
Le coût réel du non-dit
Le premier coût est direct : le budget de correction post-livraison, presque toujours supporté par le client. Le prestataire a livré ce qui était écrit, il ne va pas refaire gratuitement ce qui n'était pas demandé, et il a raison sur le plan strictement juridique.
Le deuxième coût est temporel, on l'a vu : le décalage CrUX place le constat après la fin de la garantie.
Le troisième est plus insidieux. La performance dégradée ne pénalise pas seulement le signal d'expérience de page, dont l'impact SEO direct reste modéré. Elle abîme le budget de crawl, elle abîme le taux de conversion, elle abîme le taux de rebond. Trois effets qui se cumulent, chacun difficile à isoler, et qui font qu'un site lent perd de l'argent bien avant de perdre des positions.
Enfin, il y a l'impasse de la renégociation. Sans seuil écrit, comment démontrer une non-conformité ? On se retrouve à discuter d'un ressenti, « le site est lent », face à un prestataire qui répond « il est conforme au devis ». Les deux ont raison. Personne ne peut trancher.
Le cas particulier de la refonte
C'est la situation où l'absence de mesure fait le plus de dégâts, et paradoxalement celle où il serait le plus facile de bien faire.
Une refonte se juge en comparaison. Le nouveau site est-il plus rapide que l'ancien ? Question simple, réponse impossible dans neuf cas sur dix, parce que personne n'a relevé les valeurs de l'ancien site avant de l'éteindre. Le point de comparaison a disparu avec le serveur.
La recommandation tient en une ligne, à appliquer à la signature et pas plus tard : figer un relevé de l'existant, CrUX et Lighthouse, gabarit par gabarit. Une capture d'écran horodatée du rapport Search Console suffit à sauver la discussion six mois plus tard. Ça prend une heure. Ça peut valoir plusieurs milliers d'euros de renégociation.
Faire chiffrer la performance : les questions à poser en consultation
Cadrer le périmètre de mesure
Quatre questions à poser, et il faut les quatre. Une seule qui manque et l'engagement redevient flou.
Sur quels gabarits ? Un seuil global n'a aucun sens. L'accueil, une page catégorie, une fiche produit, un article, un formulaire, une étape de tunnel : ce sont des objets techniques radicalement différents. Une fiche produit charge des variantes, des avis, un module de recommandation ; l'accueil charge une image et trois blocs. Il faut nommer les gabarits soumis à engagement, cinq ou six suffisent.
Sur quel appareil ? Mobile par défaut. C'est l'index de Google depuis des années, et c'est aussi le contexte où tout se dégrade. Un engagement sur ordinateur uniquement est un engagement décoratif.
Avec quel outil ? Nommer explicitement : PageSpeed Insights, l'API CrUX, ou une solution de monitoring RUM identifiée. Préciser aussi la version du moteur, pour éviter le débat lors d'une mise à jour.
À quelle date ? Deux dates, pas une. Recette de laboratoire à la livraison, recette terrain à J+90.
Séparer les lignes budgétaires
La performance recouvre quatre natures de travail qui n'ont pas du tout le même statut économique. Les mélanger, c'est offrir au prestataire la possibilité de facturer deux fois la même chose, ou de ne rien faire du tout.
L'audit initial (le relevé de référence) est une prestation en soi, courte, chiffrable, à part.
Les optimisations d'implémentation — compression des images, découpage du JavaScript, chargement des polices, déclaration des dimensions — relèvent du métier. Elles sont comprises dans le développement. Voir apparaître une ligne « optimisation des images : 1 200 € » sur un devis de création de site, c'est voir facturer le travail bien fait comme une option.
Les optimisations d'infrastructure — CDN, cache serveur, compression, HTTP/2 ou HTTP/3, montée de gamme de l'hébergement — sont légitimement facturables. Elles dépendent souvent d'un tiers et engagent des coûts récurrents.
Le monitoring continu — RUM, alerting sur régression, relevé périodique — est une prestation d'exploitation, distincte de la création.
Les questions qui révèlent le niveau technique réel
Celles-là ne servent pas à obtenir un chiffre. Elles servent à savoir à qui on parle. Un prestataire qui maîtrise répond en une phrase et sans consulter personne.
- Comment gérez-vous le chargement des polices ? On attend d'entendre parler de
font-display, de préchargement, d'hébergement en propre plutôt que d'un appel externe. - Quelle stratégie pour les images ? Formats modernes, dimensions déclarées dans le HTML, chargement différé pour ce qui est hors écran, et surtout priorité explicite sur l'image du LCP. Attention : appliquer le lazy loading à l'image de bandeau est une erreur classique qui dégrade le LCP au lieu de l'améliorer.
- Comment évitez-vous les décalages liés au bandeau de consentement ? C'est la première cause de CLS sur les sites français, et la réponse en dit long.
- Quel est votre poids JavaScript cible, et comment le découpez-vous ?
- Appliquez-vous un budget de performance pendant le développement, ou mesurez-vous seulement à la fin ?
- Que se passe-t-il si un script tiers que nous imposons dégrade l'INP ?
Cette dernière question est un excellent révélateur. Un prestataire honnête répond qu'il alertera, documentera l'impact chiffré, et demandera un arbitrage. Un prestataire qui répond « aucun problème, on gère » n'a probablement jamais eu à arbitrer entre un outil de chat commercial et un seuil d'INP.
Le tableau de chiffrage à faire remplir
C'est l'outil le plus simple et le plus efficace de toute la démarche. Un tableau, envoyé à chaque prestataire consulté, à remplir avant décision.
| Gabarit | Métrique | Valeur de référence | Valeur cible | Outil de mesure | Date de constat | Responsable |
|---|---|---|---|---|---|---|
| Accueil | LCP mobile | 4,1 s | ≤ 2,5 s | API CrUX, 75e centile | J+90 | Prestataire |
| Fiche produit | INP mobile | 340 ms | ≤ 200 ms | API CrUX, 75e centile | J+90 | Partagé |
| Catégorie | CLS mobile | 0,21 | ≤ 0,1 | API CrUX, 75e centile | J+90 | Prestataire |
| Tunnel, étape 1 | INP mobile | — | ≤ 200 ms | RUM interne | J+30 puis mensuel | Prestataire |
Un prestataire compétent le remplit sans difficulté particulière, quitte à discuter certaines cibles ou à poser des réserves. C'est même bon signe qu'il en discute. Un prestataire qui refuse de le remplir, ou qui renvoie un document vide accompagné d'un « on s'engage à faire au mieux », vient de répondre à la question qu'on n'avait pas osé poser.
Contractualiser : de la promesse commerciale à la clause opposable
Anatomie d'une clause qui tient
Une clause de performance opposable contient sept éléments. Il en manque un, elle devient discutable ; il en manque deux, elle ne vaut plus rien.
La métrique nommée. Le seuil chiffré. Le gabarit désigné. L'appareil. L'outil de mesure. La date de constat. La méthode de rattrapage.
« Le prestataire s'engage à ce que le LCP mobile soit inférieur ou égal à 2,5 secondes au 75e centile sur les gabarits accueil et fiche produit, mesuré via l'API CrUX, constaté quatre-vingt-dix jours après la mise en ligne. En cas de dépassement constaté, le prestataire dispose de trente jours pour ramener la valeur sous le seuil, sans facturation complémentaire. »
Trois lignes. Rien d'exotique, rien qui nécessite un cabinet d'avocats. Et pourtant elles transforment complètement le rapport de force, parce qu'elles rendent la non-conformité démontrable par une capture d'écran.
Les réserves légitimes du prestataire
Un prestataire sérieux va poser des conditions, et il faut les accueillir plutôt que s'en méfier. Une clause sans réserve est une clause qu'il ne compte pas honorer.
Les scripts tiers imposés par le client sortent naturellement du périmètre : gestionnaire de balises, module de chat, outil d'A/B testing, régie publicitaire, tracking marketing. Personne ne peut garantir un INP en laissant un tiers injecter du JavaScript arbitraire.
L'hébergement, s'il est fourni par le client, doit également faire l'objet d'une réserve, avec idéalement un TTFB plancher documenté au-delà duquel l'engagement tombe.
Les contenus ajoutés après livraison, enfin. Une image de 4 Mo téléversée depuis le back-office fait exploser le LCP d'une page, et ce n'est pas imputable au développement.
Écrire ces réserves protège les deux parties. Elles évitent le litige stérile où chacun accuse l'autre, et elles concentrent la discussion sur ce qui est réellement de la responsabilité du prestataire.
La clause de rattrapage
Que se passe-t-il si le seuil n'est pas atteint ? Une clause sans réponse à cette question est une clause décorative.
Le mécanisme le plus efficace en pratique : correction à la charge du prestataire dans un délai défini, adossée à la retenue de garantie. Tant que le seuil n'est pas constaté, le solde n'est pas libéré. Simple, lisible, et suffisamment incitatif.
La pénalité financière pure, elle, s'avère souvent contre-productive. Elle pousse le prestataire à contester la mesure plutôt qu'à corriger le site, elle envenime une relation qu'on aura besoin de préserver pour la maintenance, et son recouvrement est laborieux. Le client veut un site rapide, pas un dédommagement pour un site lent. Autant construire la clause dans ce sens.
Le transfert de compétence
Point systématiquement négligé, et pourtant c'est lui qui détermine si la performance tient dans le temps ou s'effondre au premier trimestre.
Il faut prévoir une formation, même courte, sur la compression des images depuis le back-office. La cause numéro un de dégradation post-livraison est un contenu ajouté par le client en toute bonne foi. Il faut aussi exiger une documentation des choix techniques : stratégie de cache, budget JavaScript, dépendances externes, ce qui a été fait et pourquoi. Sans ce document, l'équipe suivante repartira de zéro et défera sans le savoir la moitié du travail.
Vérifier : le protocole de recette en trois temps
- T0, à la livraison : recette de laboratoire, seule possible sur un site sans historique.
- T+30 à T+90 : recette terrain, sur données CrUX ou RUM.
- Au-delà : suivi continu et détection de régression.
T0, la recette de laboratoire
PageSpeed Insights sur chaque gabarit engagé, en mobile et en ordinateur, avec trois mesures consécutives. Ce dernier point n'est pas de la coquetterie : la variabilité du laboratoire est réelle, deux tests successifs sur la même URL peuvent afficher plusieurs dixièmes d'écart sur le LCP. Une mesure isolée ne prouve rien, ni dans un sens ni dans l'autre.
À cela s'ajoutent des vérifications structurelles, qui ne dépendent d'aucun outil et qu'on peut faire soi-même en inspectant le code : les images portent-elles leurs dimensions ? Les polices sont-elles préchargées ? Reste-t-il des ressources bloquantes dans l'en-tête ? Le poids JavaScript est-il conforme au budget annoncé ?
Ce qu'on ne peut pas valider à ce stade, et il faut l'assumer clairement dans le procès-verbal de recette : l'INP réel et le CLS réel. Les deux dépendent de comportements humains qu'aucune simulation ne reproduit.
T+30 à T+90, la recette terrain
Deux sources, complémentaires.
Le rapport d'expérience utilisateur de la Search Console d'abord, qui regroupe les URL par type et donne un statut par métrique. Lecture rapide, vision d'ensemble, pratique pour repérer un gabarit entier en échec.
L'API CrUX ensuite, pour un relevé propre URL par URL. C'est elle qu'on utilise pour constater formellement le respect ou non d'une clause, parce qu'elle donne la valeur au centile demandé, sans interprétation.
Reste le cas des sites à faible audience, et il est fréquent. En dessous d'un certain volume de visites, CrUX n'expose aucune donnée. La clause devient alors invérifiable telle qu'elle est écrite. La solution consiste à prévoir dès le contrat une méthode de substitution : un RUM léger, installé par le prestataire, dont les relevés font foi. Écrit à la signature, ça règle le problème ; découvert à J+90, ça crée un conflit sans issue.
Le suivi continu et la détection de régression
Une chose qu'on comprend mal au début : la performance n'est pas un état atteint une fois pour toutes. C'est un équilibre instable, qui se dégrade par défaut.
Chaque script marketing ajouté, chaque mise à jour d'extension, chaque campagne avec ses pixels de suivi, chaque nouvelle fonctionnalité grignote un peu de marge. Un site livré à 2,1 secondes de LCP peut se retrouver à 3,4 secondes dix-huit mois plus tard sans qu'aucune décision consciente n'ait été prise. Personne n'a rien cassé. Tout le monde a ajouté un petit quelque chose.
D'où l'intérêt d'alertes sur seuil, et d'un rituel de relevé trimestriel intégré à la prestation de suivi SEO. Quinze minutes par trimestre, quatre relevés archivés, et une dérive devient visible pendant qu'elle est encore corrigeable à moindres frais.
Interpréter un écart sans se tromper de coupable
Trois situations, trois lectures différentes.
Un écart entre laboratoire et terrain est normal. Il ne signale aucune malfaçon. Les deux mesures ne mesurent pas la même chose ; le terrain intègre des connexions médiocres, des appareils anciens, des caches vides. Accuser le prestataire sur cette base est le meilleur moyen de perdre en crédibilité dans la discussion suivante.
Une dégradation soudaine, en revanche, a presque toujours une cause identifiable et récente : un script ajouté, une extension mise à jour, une modification de configuration serveur. Le réflexe utile est de dater précisément la rupture et de chercher ce qui a changé ce jour-là. Pas de remonter au code livré des mois plus tôt.
Une dégradation lente raconte une autre histoire. Croissance du catalogue, contenus ajoutés sans compression, dette technique accumulée. Elle ne se corrige pas par un correctif ponctuel mais par une remise à niveau, qu'il faut budgéter comme telle.
Deux cas de figure fréquents
Le site vitrine à faible trafic
Situation la plus courante chez les PME, et celle où l'on entend le plus souvent qu'il est inutile de contractualiser la performance. C'est un mauvais raisonnement.
L'absence de données CrUX complique la vérification, elle ne la supprime pas. La recette repose alors sur le laboratoire, plus rigoureux qu'à l'ordinaire puisqu'il n'y aura pas de filet terrain, complété par un RUM léger si le budget le permet. L'exigence contractuelle doit être adaptée, avec un outil de constat différent, pas supprimée. Un site vitrine lent perd des appels entrants exactement comme un e-commerce perd des paniers.
Le e-commerce à fort trafic
Ici, la hiérarchie des priorités change. L'accueil, sur lequel tout le monde se concentre, est rarement l'enjeu principal : c'est le tunnel de conversion qui porte le chiffre d'affaires, et c'est donc lui qui doit être en tête des gabarits engagés.
L'INP devient la métrique critique. Filtres de navigation, sélection de variantes, ajout au panier, mise à jour des quantités : chaque interaction est une occasion de dépasser les 200 millisecondes, et un tunnel qui répond mollement fait chuter la conversion bien plus vite qu'un accueil qui met trois secondes à s'afficher.
Enfin, la première cause d'échec est presque toujours la même : les scripts tiers. Widget d'avis clients, moteur de recommandation, solution de paiement, outil de personnalisation. Chacun est justifié individuellement. Empilés, ils rendent l'engagement de performance intenable, ce qui rappelle l'importance d'avoir écrit noir sur blanc, en amont, ce qui se passe quand le client impose un script.
Ce qu'il faut retenir
La logique tient en cinq gestes, et aucun ne demande de compétence technique particulière : nommer la métrique, désigner le gabarit, fixer la date, choisir l'outil de mesure, prévoir le rattrapage. Cinq lignes ajoutées à un cahier des charges, qui changent la nature de ce qui est acheté.
Il faut aussi renoncer à une idée confortable : le sérieux d'un prestataire ne se lit pas dans sa promesse de rapidité. Tout le monde promet un site rapide, y compris ceux qui livreront un site lent, et sans mauvaise intention la plupart du temps. Ce qui distingue vraiment, c'est l'acceptation d'être mesuré. Un prestataire qui propose lui-même des seuils, qui pose ses réserves, qui discute les gabarits engagés, a déjà démontré plus de compétence qu'un autre avec ses trois pages d'arguments commerciaux.
Reste une difficulté de fond, qu'il serait malhonnête de passer sous silence. Le client n'a, dans l'immense majorité des cas, pas les moyens techniques d'écrire ce référentiel ni d'arbitrer la recette. C'est précisément là qu'un tiers technique prend son sens : formaliser le tableau de chiffrage, rédiger la clause, conduire le relevé de référence avant refonte, et trancher au moment de la recette. Non pas pour se retourner contre le prestataire, mais pour rétablir la symétrie d'expertise et permettre à la discussion de porter sur des chiffres plutôt que sur des impressions. C'est presque toujours à l'avantage des deux parties, y compris de celle qui développe.
