Core Web Vitals en 2026 : notre obsession de la vitesse

Depuis mars 2024, un sigle a discrètement changé la donne : INP a remplacé FID dans le trio des Core Web Vitals. Beaucoup l’ont appris à leurs dépens. Chez Netilpa, ce matin-là, nous n’avons rien eu à corriger — non par chance, mais parce que la réactivité qu’INP mesure, nous la surveillions déjà. C’est sans doute notre parti pris le plus tenace : un site que nous livrons doit être rapide avant d’être décoratif, parce que la vitesse n’est pas un raffinement d’ingénieur, c’est ce que ressent, seconde après seconde, la personne qui vous lit.

Trois lettres, trois moments de l’expérience

Le LCP (Largest Contentful Paint) mesure le temps qu’il faut pour afficher le plus gros élément visible : le plus souvent l’image de couverture ou le titre. C’est la question la plus simple qui soit — « quand est-ce que la page a l’air prête ? ». En dessous de 2,5 secondes, c’est bon ; au-delà de quatre, le visiteur a déjà pensé à partir.

L’INP (Interaction to Next Paint) mesure la réactivité : le délai entre le clic et le moment où l’écran répond enfin. Là où l’ancien FID ne jugeait que la première interaction, INP les observe toutes et retient les pires. Objectif : rester sous 200 millisecondes. Un menu qui met une demi-seconde à s’ouvrir, un formulaire qui gèle à la frappe — voilà ce qu’INP débusque, et ce que nous refusons de livrer.

Le CLS (Cumulative Layout Shift) mesure la stabilité : ces sauts de mise en page qui vous font cliquer sur la mauvaise chose parce qu’une bannière a poussé le contenu vers le bas. Seuil de confort : 0,1. Chacun a déjà pesté contre un bouton qui se dérobe au dernier instant ; le CLS met un chiffre sur cette exaspération, et nous en faisons une ligne rouge dès la maquette.

Le score Lighthouse n’est pas une fin

Voici la confusion la plus tenace, celle qui nous fait perdre le plus de temps en réunion. Le score Lighthouse que l’on obtient en cliquant dans son navigateur est un test de laboratoire : une page, une fois, dans des conditions simulées. Les Core Web Vitals que Google exploite, eux, viennent du terrain — du rapport CrUX, alimenté par les vrais Chrome de vos vrais visiteurs, sur vieux téléphone et réseau capricieux.

C’est là que nous démontons les idées reçues, souvent avec nos clients eux-mêmes. Non, une note verte ne « fait pas remonter » mécaniquement dans les résultats — l’expérience de page n’est qu’un signal parmi des centaines, et un contenu médiocre le restera, fût-il instantané. Google l’écrit lui-même, sans détour. Courir après le chiffre plutôt que la sensation, c’est le plus sûr moyen de décrocher un joli rapport et de perdre l’essentiel. Nous préférons, avec un client, suivre une courbe CrUX qui s’améliore sur trois mois plutôt qu’un 100 sur 100 arraché en laboratoire.

Optimiser pour le score, c’est soigner le thermomètre. Optimiser pour l’utilisateur, c’est soigner le patient.

La vitesse sert l’expérience, donc la conversion

Alors pourquoi s’en soucier, si le référencement n’y gagne qu’à la marge ? Parce que ces métriques ne mesurent pas une lubie : elles mesurent de la frustration. Et la frustration se paie en abandons. Une page produit qui met quatre secondes à montrer son prix, un bouton « Payer » qui tarde à réagir : chacun de ces défauts a un coût, chiffrable, en paniers laissés en plan.

Les grands acteurs du e-commerce le documentent depuis des années : quelques centaines de millisecondes gagnées valent des points de conversion. Nul besoin, pourtant, d’être un géant du web. Sur un simple site vitrine que nous concevons, un LCP qui passe de cinq à deux secondes transforme le taux de rebond ; un formulaire de contact enfin réactif, c’est un prospect qui va au bout au lieu de fermer l’onglet. Pour nos clients, la performance n’est jamais un sujet technique rangé à part : c’est un sujet de revenu, et nous le traitons comme tel dès le premier atelier.

Notre remède : un budget de performance et de la sobriété

D’où vient le mal ? Presque toujours du même endroit : le poids. Une image de couverture de trois mégaoctets servie en pleine résolution, cinq polices web qui bloquent l’affichage, une avalanche de scripts tiers — analytics, chat, A/B testing, régie publicitaire — dont chacun ajoute sa dette. Et l’hydratation JavaScript de trop, qui fige la page pendant qu’elle prétend l’animer.

Notre réponse tient en deux mots : budget de performance. Sur chaque projet, nous fixons une limite — tant de kilo-octets par page, tel seuil d’INP à ne jamais franchir — et nous nous y tenons comme à un budget financier. Toute nouvelle fonctionnalité doit entrer dans l’enveloppe, ou justifier bruyamment sa place. C’est contraignant, et c’est précisément ce qui le rend efficace : la sobriété n’est pas une privation, c’est une discipline que nous imposons d’abord à nous-mêmes.

Redimensionner les images, différer le non-essentiel, se méfier du script tiers « gratuit » qui coûte trois cents millisecondes, réserver de la hauteur aux bannières pour qu’elles ne bousculent rien, préférer le HTML qui s’affiche au JavaScript qui se charge : rien d’héroïque, que du bon sens tenu avec constance. C’est ce que nous appliquons, site après site, parce que la vitesse n’est pas une prouesse réservée aux mastodontes du web — c’est un respect élémentaire du temps de vos visiteurs. Si le vôtre vous semble lourd, parlons-en : c’est exactement le genre de chantier où nous nous sentons chez nous.