Les Core Web Vitals existent depuis 2020 et, en quelques années, ils sont devenus la référence commune pour parler de performance web : développeurs, responsables marketing, agences et clients utilisent les trois mêmes noms, LCP, INP et CLS, et les mêmes seuils. C’est précisément pour cette raison que, chaque fois que Google annonce un changement, le secteur se demande : qu’est-ce qui va changer, quand, et que faut-il faire ?
Prédire l’avenir dans le détail est impossible, mais l’histoire de ces années et la manière dont le programme est organisé permettent de comprendre comment les métriques évoluent, quelles directions sont déjà visibles et comment se préparer sans courir après chaque nouveauté. Dans cet article, nous retraçons les changements qui ont eu lieu, nous expliquons le cycle de vie d’une métrique, nous examinons les domaines en cours d’expérimentation et nous proposons une façon de travailler qui reste valable quoi qu’il arrive.
D’où nous venons
Avant les Core Web Vitals, les métriques de performance étaient nombreuses et disparates : temps de chargement complet, time to first byte, indices de vitesse visuelle, scores agrégés. Chaque outil mesurait à sa manière, et les comparaisons étaient difficiles. En 2020, Google a proposé un ensemble réduit de métriques, choisies selon quelques critères précis : centrées sur l’expérience utilisateur, mesurables sur des utilisateurs réels, représentatives d’aspects distincts de l’expérience. Les trois premières étaient le Largest Contentful Paint pour le chargement, le First Input Delay pour la réactivité et le Cumulative Layout Shift pour la stabilité visuelle.
Depuis, les changements ont été peu nombreux mais significatifs. En 2021, l’expérience de page est devenue l’un des signaux de classement pour les recherches sur mobile, et l’année suivante aussi pour les recherches sur ordinateur, comme nous l’avons vu dans l’article sur les Core Web Vitals et le SEO. Toujours en 2021, le calcul du CLS a été modifié : au lieu d’additionner tous les décalages de la vie de la page, il retient la pire fenêtre de session, un changement qui a rendu la métrique plus équitable pour les pages longues et les sessions étendues. En 2023, Google a annoncé l’INP comme successeur du FID, et en mars 2024 le remplacement est entré en vigueur.
La leçon du FID
Le passage du FID à l’INP est le cas le plus instructif pour comprendre comment les métriques évoluent. Le FID ne mesurait que le délai avant que le navigateur commence à traiter la première interaction de l’utilisateur, et non le temps total pour afficher la réponse, et il ignorait toutes les interactions suivantes. Il était facile à réussir : la grande majorité des sites obtenaient de bonnes valeurs, même lorsque les utilisateurs percevaient clairement des interfaces lentes. La métrique, en d’autres termes, ne décrivait pas bien l’expérience qu’elle devait représenter.
L’INP prend en compte toutes les interactions de la visite et mesure le temps jusqu’à l’affichage de la réponse. C’est une métrique beaucoup plus exigeante, et au moment du remplacement, de nombreux sites jugés bons avec le FID sont passés à « à améliorer » sans rien changer. La leçon est claire : celui qui avait optimisé pour le chiffre, en exploitant les limites du FID, s’est retrouvé exposé ; celui qui avait travaillé sur la réactivité réelle, en réduisant le JavaScript et les tâches longues, a traversé le changement sans problème.
Le cycle de vie d’une métrique
Pour rendre les changements prévisibles, Google a décrit un cycle de vie pour les métriques du programme Web Vitals. Une métrique naît expérimentale : elle est proposée, implémentée dans le navigateur, discutée avec la communauté et corrigée d’après les données collectées. Si elle se révèle utile et fiable, elle devient en attente : elle est annoncée comme future Core Web Vital, avec un préavis qui permet aux sites de se préparer. Enfin, elle devient stable et entre dans les évaluations. Une métrique stable peut être retirée lorsqu’une meilleure arrive, comme cela s’est produit pour le FID.
Google a aussi indiqué que les métriques stables ne changent pas plus d’une fois par an, et toujours avec un préavis. À côté des Core Web Vitals, il existe aussi des métriques de diagnostic, comme le TTFB, le First Contentful Paint et le Total Blocking Time : elles ne font pas partie de l’évaluation, mais elles aident à comprendre les causes des problèmes. Toutes les nouveautés ne sont donc pas destinées à devenir des Core Web Vitals : beaucoup restent des outils de diagnostic, utiles à ceux qui travaillent sur la performance mais sans conséquence sur l’évaluation.
Les détails changent aussi
Outre les changements annoncés, les implémentations des métriques dans le navigateur sont mises à jour périodiquement pour corriger des cas particuliers : quels éléments peuvent être candidats au LCP, comment traiter les images d’arrière-plan à faible contenu informatif ou les éléments initialement transparents, comment compter les décalages causés par certaines animations. Ces mises à jour sont documentées dans un journal public des modifications des métriques, et ont généralement de petits effets. Elles peuvent toutefois expliquer des variations soudaines des données de terrain sans lien avec des modifications du site, et il est utile de savoir où les vérifier.
Les directions déjà visibles
Les navigations douces
Le domaine de travail le plus avancé concerne les applications monopages. Aujourd’hui, comme nous l’avons vu dans l’article sur les Single Page Applications, les navigations internes de ces applications ne produisent pas de nouvelles mesures de chargement, et le CLS et l’INP s’accumulent sur toute la session. Chrome expérimente depuis un certain temps un mécanisme pour reconnaître ces navigations et les mesurer comme des pages distinctes. S’il devenait stable, il changerait sensiblement les valeurs de nombreux sites construits avec des frameworks JavaScript : certaines pages s’amélioreraient, parce que les problèmes de la session ne seraient plus attribués à la page d’entrée, d’autres se dégraderaient, parce que des navigations lentes aujourd’hui invisibles seraient enfin mesurées.
L’attribution des causes
Une deuxième direction ne concerne pas de nouvelles métriques mais la capacité à comprendre les métriques existantes. La Long Animation Frames API, disponible dans Chrome, montre quels scripts contribuent aux images lentes et donc aux interactions lentes ; les versions avec attribution des bibliothèques de mesure décomposent le LCP et l’INP en phases. C’est une tendance qui rend les métriques plus exploitables, en déplaçant l’attention du « combien » vers le « pourquoi », et elle se poursuivra probablement.
La fluidité
Un aspect de l’expérience que les Core Web Vitals actuelles ne couvrent pas directement est la fluidité : des animations et un défilement qui avancent par saccades, des images perdues pendant une transition. Le sujet a été exploré plusieurs fois avec des métriques expérimentales, sans aboutir pour l’instant à une proposition stable. Il est plausible que quelque chose émerge dans cette direction à l’avenir, aussi parce que des API comme celle des long animation frames fournissent déjà une partie des données nécessaires.
Au-delà de Chrome
Les API sur lesquelles reposent les métriques sont nées dans Chromium, et pendant des années seuls les navigateurs fondés sur ce moteur les ont prises en charge. Ces dernières années, d’autres moteurs ont commencé à en implémenter certaines, et le travail de standardisation dans les groupes du W3C se poursuit. Une prise en charge plus large permettrait de mesurer la performance des utilisateurs de tous les navigateurs avec les mêmes outils, un avantage surtout pour les sites qui ont beaucoup de visiteurs sur des appareils Apple, aujourd’hui en partie invisibles dans les données du Chrome UX Report.
Les seuils pourraient-ils changer ?
Une question fréquente concerne les seuils : 2,5 secondes pour le LCP, 200 millisecondes pour l’INP, 0,1 pour le CLS. Ils ont été choisis d’après des recherches sur la perception des utilisateurs et sur la possibilité, pour une part significative des sites, de les atteindre, et n’ont pas changé depuis 2020. À mesure que les réseaux et les appareils s’améliorent et que les sites sont optimisés, la part des pages dans l’état bon augmente, et on ne peut pas exclure que les seuils deviennent plus exigeants à l’avenir. Même dans ce cas, toutefois, le changement suivrait le même cycle d’annonce et de préavis que les métriques, et celui qui a des valeurs bien à l’intérieur des seuils actuels, et pas seulement juste sous la limite, aurait peu à craindre.
Ce que cela signifie pour un site WordPress
Pour qui gère un site WordPress, l’évolution du cœur va dans la même direction que les métriques : chargement sélectif des styles des blocs, priorité automatique pour l’image principale, prise en charge du chargement spéculatif des pages, modules JavaScript chargés uniquement quand c’est nécessaire. Suivre les mises à jour de WordPress, privilégier les thèmes et les plugins qui adoptent ces fonctionnalités et réduire les dépendances à du code daté est, en pratique, une manière de se préparer aussi aux métriques futures.
Comment se préparer
La leçon du FID suggère la stratégie la plus solide : optimiser pour l’expérience que les métriques essaient de décrire, et non pour les métriques elles-mêmes. Un site avec un serveur rapide, des pages légères, peu de JavaScript exécuté au bon moment, une mise en page stable et des interactions qui répondent immédiatement traversera n’importe quel changement de métrique sans surprise, car chaque nouvelle métrique essaiera de décrire mieux ces mêmes qualités. À l’inverse, les optimisations qui visent à exploiter les limites d’une métrique, comme nous l’avons vu en parlant du cloaking de performance, sont les premières à devenir inutiles quand la métrique change.
Sur le plan pratique, quelques habitudes aident à ne pas être pris au dépourvu.
- Mesurer les métriques expérimentales. Un système de Real User Monitoring peut collecter, en plus des métriques stables, celles en cours d’expérimentation : quand l’une d’elles est annoncée, vous connaissez déjà vos propres valeurs et vous avez des mois d’avance.
- Suivre les sources officielles. Les annonces sur le programme Web Vitals, le journal des modifications des métriques et les notes de version mensuelles du Chrome UX Report suffisent pour savoir à l’avance ce qui va changer.
- Surveiller les métriques de diagnostic. Le TTFB, le Total Blocking Time et les décompositions du LCP et de l’INP pointent des problèmes qui deviendront probablement pertinents pour les métriques futures aussi.
- Maintenir des budgets. Un budget de performance sur la quantité de JavaScript, le poids de la page et le nombre de scripts tiers protège les qualités de fond du site, indépendamment des métriques utilisées pour les évaluer.
Ce qui ne changera probablement pas
Plus intéressant que ce qui va changer, peut-être, est ce qui va rester. Les trois questions auxquelles répondent les Core Web Vitals, à quelle vitesse le contenu principal apparaît, à quelle vitesse la page répond, à quel point ce que l’on voit est stable, décrivent des aspects fondamentaux de l’expérience de quiconque utilise un site, et il est peu probable qu’elles perdent de l’importance. Les métriques pourront devenir plus précises, couvrir plus de cas, s’étendre à plus de navigateurs ; les qualités qu’elles mesurent resteront les mêmes. Comme le principe de fond du programme : mesurer l’expérience des utilisateurs réels, et non le comportement du site en laboratoire.
Le lien avec le business a lui aussi peu de chances de changer. Un site rapide, stable et réactif retient plus de visiteurs, convertit plus et coûte moins cher à exploiter, quelle que soit la façon dont Google décide de l’évaluer, comme nous l’avons vu dans l’article sur le retour économique de la performance. Les métriques sont le thermomètre ; la santé du site est ce qui compte.
En résumé
En quelques années, les Core Web Vitals ont peu changé mais de façon significative : le CLS est passé aux fenêtres de session, l’INP a remplacé le FID, les seuils du LCP et du CLS sont restés stables. Les changements suivent un cycle de vie public, de l’expérimentation à la stabilité, avec des préavis de plusieurs mois, et les métriques stables ne changent pas plus d’une fois par an. Les directions déjà visibles concernent les navigations douces, l’attribution des causes, la fluidité et la prise en charge dans d’autres navigateurs.
La meilleure façon de se préparer est celle qui est déjà nécessaire aujourd’hui : travailler sur l’expérience réelle et non sur le chiffre, mesurer les utilisateurs réels même avec des métriques expérimentales, suivre les sources officielles et protéger les qualités de fond du site avec des budgets et des contrôles. Celui qui le fait n’a pas à craindre l’avenir des Core Web Vitals : chaque nouvelle métrique, au fond, ne fera qu’essayer de mieux décrire ce que ce site fait déjà bien.
