L’histoire des Core Web Vitals

• Les Core Web Vitals, qui mesurent les performances des sites web, sont nés à partir de 2014 d’un effort conjoint de plusieurs équipes de Google pour dépasser les limites du projet AMP et définir des indicateurs de performance standardisés et ouverts applicables à tous les sites web
• En mai 2020, trois indicateurs clés ont été officiellement annoncés (LCP pour la vitesse de chargement, FID pour la réactivité aux interactions et CLS pour la stabilité visuelle), conçus comme des indicateurs mesurables sur le terrain reflétant l’expérience réelle des utilisateurs
• En 2021, ils ont été introduits comme facteur de classement via la mise à jour Page Experience de Google Search, et l’exigence d’exclusivité AMP a été supprimée de Top Stories, favorisant un environnement concurrentiel ouvert sur le Web
• Grâce à l’optimisation du navigateur Chrome, aux améliorations de grands CMS comme WordPress et à la collaboration avec les frameworks JavaScript, plus de 10 000 années cumulées de temps d’attente utilisateur ont été économisées en 2023, puis 30 000 années en 2024
• En 2024, avec le remplacement de FID par INP et l’introduction de la Soft Navigation API pour les SPA, l’initiative continue d’évoluer et contribue à bâtir un écosystème web rapide, stable et centré sur l’utilisateur

---

Contexte et motivation : d’AMP à des métriques ouvertes pour le Web

• Pendant des années, Google a souligné que la vitesse et l’expérience utilisateur étaient des principes fondamentaux du Web, mais de nombreux sites continuaient malgré tout à offrir une expérience lente
• En 2010, Google Search a commencé à utiliser la vitesse des sites comme signal de classement, ce qui constituait une première tentative d’intégrer la performance au SEO
• Vers 2015, le projet AMP (Accelerated Mobile Pages) a été introduit pour proposer des pages optimisées au chargement rapide, mais cela a soulevé des problèmes d’ouverture et de flexibilité, car l’expérience reposait sur un environnement fermé servi depuis le cache de Google
• En 2018, la Speed Update a appliqué la vitesse des pages au classement de la recherche mobile, et Google Ads a aussi introduit un score de vitesse des pages de destination mobile, soulignant qu’une expérience rapide entraîne de meilleurs taux de conversion
• Pour sortir d’une approche centrée exclusivement sur AMP, les équipes Chrome et Search ont collaboré afin de définir des indicateurs de performance ouverts, applicables à toutes les pages sans framework particulier
  • En analysant des millions de pages, elles ont cherché à définir un standard public des pages web rapides et conviviales
  • L’objectif était de créer des indicateurs mesurables sur le terrain reflétant l’expérience réelle des utilisateurs
  • Elles voulaient aussi identifier des métriques corrélées à des résultats comme l’engagement des utilisateurs

Définition des Core Web Vitals : les trois piliers de l’expérience utilisateur

• En mai 2020, Google a officiellement annoncé l’initiative Web Vitals et introduit les Core Web Vitals, centrés sur « les aspects essentiels de l’expérience utilisateur applicables à toutes les pages web »

• Les Core Web Vitals initiaux se composaient de trois indicateurs clés

  • Largest Contentful Paint (LCP) : un indicateur de vitesse de chargement qui mesure le moment où le contenu principal est rendu, en allant au-delà de First Contentful Paint ou de onload pour se concentrer sur l’instant où l’utilisateur voit réellement un contenu significatif
  • First Input Delay (FID) : un indicateur de réactivité aux interactions qui mesure le délai entre la première interaction de l’utilisateur et la réponse du navigateur, afin de déterminer si la page réagit immédiatement ou si elle est retardée par des scripts lourds
  • Cumulative Layout Shift (CLS) : un indicateur de stabilité visuelle qui mesure l’ampleur des déplacements de mise en page pendant le chargement ; il additionne les changements de layout inattendus, et un CLS faible signifie une expérience stable et agréable

• Le choix des indicateurs s’est appuyé sur de vastes recherches et expérimentations

  • Amar Sagoo, Annie Sullivan, Vivek Sekhar et d’autres ont mis en évidence, via des recherches en interaction humain-machine, la corrélation entre mesures de performance objectives et perception des utilisateurs
  • Un temps de chargement de 2 à 3 secondes maximum, une réponse aux entrées en moins de 100 ms et des déplacements de layout minimisés étaient considérés comme idéaux
  • En analysant les données d’utilisateurs réels, ils ont défini des seuils cibles pragmatiques : LCP inférieur à 2,5 secondes, FID inférieur à 100 ms et CLS inférieur à 0,1 (au 75e percentile)
  • Les pages qui atteignent ces seuils présentent une probabilité de rebond inférieure de 24 %

• Google a œuvré pour rendre ces indicateurs standardisés et ouverts

  • Des brouillons de spécifications web ont été publiés via le WICG et des groupes de standardisation des performances web
  • Ils ont été implémentés dans Chrome et d’autres navigateurs pour être mesurables via l’API PerformanceObserver
  • En mai 2020, Google a publié la bibliothèque JavaScript open source web-vitals, que les développeurs peuvent intégrer à leurs sites pour mesurer le LCP, le FID et le CLS d’utilisateurs réels
  • Addy Osmani a développé une extension Core Web Vitals affichant les métriques en temps réel
  • Cela reflète un effort large visant à rendre ces indicateurs accessibles et utiles à l’ensemble de l’écosystème

Page Experience : les Core Web Vitals dans le classement de Google Search

• L’équipe Google Search a rapidement adopté les Core Web Vitals dans le cadre de la mise à jour Page Experience

• Le 28 mai 2020, Google Search Central a annoncé que ces indicateurs seraient intégrés à l’algorithme de classement

  • Lorsque deux pages présentent une pertinence de contenu similaire, la page offrant la meilleure expérience utilisateur est classée plus haut
  • Le signal Page Experience combine les Core Web Vitals avec des signaux UX existants (compatibilité mobile, sécurité HTTPS, absence d’interstitiels intrusifs)
  • Un excellent contenu reste le facteur le plus important, et un site rapide ne dépassera pas un site plus pertinent uniquement grâce à sa vitesse
  • En cas d’égalité ou d’écart minime, de bons Web Vitals peuvent devenir le facteur décisif

• L’annonce la plus marquante a été la suppression de l’exigence AMP dans le carrousel Top Stories

  • Auparavant, sur mobile, Google News/Top Stories exigeait AMP, mais après la mise à jour Page Experience, les pages non AMP pouvaient elles aussi y figurer si elles respectaient les Core Web Vitals et les autres critères
  • « AMP n’est plus obligatoire pour les Top Stories sur mobile, qui sont ouvertes à toute page offrant une bonne expérience de page »
  • Cela montre la confiance de Google dans une amélioration du Web ouvert sans devoir canaliser celui-ci vers le framework AMP

• Google a donné à l’écosystème un préavis suffisant

  • Conscient que 2020 était une année difficile en raison de la pandémie de COVID-19, Google a annoncé que le changement de classement ne serait pas appliqué avant 2021, promettant au moins six mois de préavis
  • Une mise à jour de novembre 2020 a précisé que les changements de classement liés à Page Experience commenceraient en mai 2021
  • Finalement, la mise à jour Page Experience a commencé son déploiement à la mi-juin 2021 et a été entièrement appliquée d’ici fin août (recherche mobile)
  • Une mise à jour similaire pour la recherche sur ordinateur a eu lieu en février-mars 2022

• Une fois la mise à jour déployée, l’algorithme de classement de Google a commencé à utiliser les Core Web Vitals comme l’un de ses centaines de signaux

  • Les pages atteignant le seuil « bon » sur les trois métriques CWV sont considérées comme offrant une bonne expérience de page
  • Google a créé dans Google Search Console un rapport Page Experience, permettant aux propriétaires de sites de voir, à partir des données du Chrome UX Report, la proportion de pages qui franchissent les seuils
  • Cela a fourni aux webmasters et aux experts SEO un retour direct sur les performances de leurs sites du point de vue des signaux d’expérience de page

• Google a envisagé d’afficher dans les résultats de recherche un badge pour les pages offrant une bonne expérience de page, mais aucune icône permanente n’a été ajoutée

  • La récompense a principalement pris la forme d’un gain dans le classement plutôt que d’un label explicite
  • Pendant un temps, Google a affiché un indicateur temporaire « Page Experience » dans Search Console et lors de certaines expérimentations dans les résultats de recherche
  • L’idée essentielle est que Google incite publiquement à améliorer la performance et l’UX, et qu’obtenir de bons Core Web Vitals peut non seulement satisfaire les utilisateurs, mais aussi améliorer la visibilité d’une page dans les résultats de recherche

Outils et données : Chrome UX Report et mesure des performances

• Google a réalisé d’importants investissements dans les outils et les données pour les Web Vitals

• Chrome UX Report (CrUX) a été au cœur de cet effort

  • Jeu de données public de métriques d’expérience utilisateur réelle existant depuis 2017, il collecte des données de performance anonymisées sur des millions de sites auprès de millions d’utilisateurs de Chrome
  • Au lancement des Core Web Vitals, CrUX a immédiatement commencé à rapporter LCP, FID et CLS pour toutes les URL d’origine du jeu de données
  • N’importe qui peut interroger les données de performance en conditions réelles
  • Après avoir fourni un accès via BigQuery, Google a lancé CrUX API et CrUX Dashboard, permettant aux développeurs et spécialistes SEO de voir facilement comment leur site (ou celui de concurrents) se comporte sur les métriques CWV en conditions réelles
  • L’introduction de la CrUX History API a également fourni des données de séries temporelles sur ces métriques, permettant de suivre les progrès sur plusieurs mois

• Du côté des outils pour développeurs, l’intégration a été rapide

  • Fin 2020, la plupart des outils de performance de Google avaient été mis à jour pour mettre en avant les Core Web Vitals
  • Lighthouse (l’outil d’audit open source utilisé dans Chrome DevTools et PageSpeed Insights) a intégré des diagnostics et scores liés aux CWV
    • Avec des audits du type : « Largest Contentful Paint était de X secondes (objectif < 2,5 secondes) » et des suggestions d’amélioration
  • Chrome DevTools a ajouté un panneau Core Web Vitals et des marqueurs dans la timeline, permettant d’identifier l’élément LCP ou les changements de mise en page pendant le chargement d’une page
  • PageSpeed Insights (PSI) a été entièrement repensé pour se concentrer sur les CWV
    • Les données de terrain sur LCP, FID (puis INP) et CLS issues de CrUX y sont affichées de manière bien visible en haut
  • Google Search Console a fourni un rapport dédié Core Web Vitals qui regroupe les pages dans les catégories « Bon », « À améliorer » et « Mauvais » pour chaque métrique, permettant aux propriétaires de sites d’identifier précisément les zones problématiques
  • Travail sur les outils mené notamment par Elizabeth Sweeny, Paul Irish et Addy Osmani

• La communauté du développement web a également suivi avec des outils tiers

  • Les fournisseurs de services de Real User Monitoring (RUM) ont rapidement intégré les Core Web Vitals
  • mPulse d’Akamai, Browser agent de New Relic, Dynatrace, Datadog, SpeedCurve et d’autres ont immédiatement pris en charge LCP, FID et CLS comme métriques de premier plan
  • Cloudflare a également lancé le service Browser Insights, capable de collecter les Web Vitals en injectant un script
  • Grâce à l’existence de la bibliothèque JS web-vitals, tous les outils d’analyse pouvaient facilement collecter ces métriques
  • En 2021, les Core Web Vitals étaient devenus omniprésents dans les tableaux de bord des outils de monitoring de performance web
  • Cette large disponibilité a accru la sensibilisation et fourni aux développeurs les données nécessaires pour piloter les améliorations de performance

• Les données du Chrome User Experience Report ont aussi été essentielles pour suivre les progrès à l’échelle du web

  • En 2021 et 2022, la part du trafic avec de « bons » CWV a régulièrement augmenté
  • Cela a souvent été rapporté dans le Web Almanac annuel de HTTP Archive ou dans les propres mises à jour de blog de Google
  • Le fait de disposer de métriques mesurables et publiquement visibles a créé une sorte de cercle vertueux de concurrence
  • Les propriétaires de sites et les fournisseurs de plateformes ont commencé à mettre en avant leurs Core Web Vitals et à chercher à les améliorer

Impact et améliorations : rendre le web plus rapide et plus stable

Optimisation du navigateur Chrome

• Une fois les Core Web Vitals établis, ils ont déclenché un effort massif et multiforme à travers tout l’écosystème web pour améliorer ces métriques

• L’équipe d’ingénierie de Google Chrome a examiné de près le navigateur afin d’optimiser la façon dont Chrome charge et rend les pages web

  • Compte tenu de l’immense base d’utilisateurs de Chrome, même de petites améliorations au niveau du navigateur profitent à l’ensemble du web
  • Cela inclut plusieurs optimisations majeures déployées dans Chrome entre 2020 et 2023

• Priorisation du contenu pour le LCP

  • Chrome a été modifié pour prioriser le chargement du contenu important
  • Le navigateur identifie les premières images du HTML (souvent l’image LCP) et leur attribue une priorité réseau plus élevée
  • Le fait de prioriser ainsi les 5 premières images a permis d’améliorer le LCP de 3,1 secondes à 2,5 secondes sur certaines pages
  • De nouveaux standards web comme l’attribut fetchpriority (mécanisme Priority Hints) ont été introduits pour permettre aux développeurs de marquer une image ou un iframe avec une priorité élevée pour le LCP

• Back/Forward Cache (BFCache)

  • Historiquement, Chrome ne mettait pas complètement les pages en BFCache en raison de la complexité technique, mais ces dernières années le BFCache a été activé pour de nombreuses pages
  • D’ici 2023, une hausse notable du taux de succès du BFCache avait été obtenue sur desktop comme sur Android
  • Les utilisateurs qui reviennent « en arrière » sur une page peuvent la voir instantanément (LCP nul, latence d’entrée nulle, puisque la page n’a pas été déchargée)
  • De grandes plateformes comme Amazon ont bénéficié du BFCache de Chrome et, après une amélioration de Chrome (version M112), ont signalé une hausse de 22,7 points de pourcentage de l’usage du cache back/forward

• Prerendering (NoState Prefetch/Prerender2)

  • Chrome a lancé un nouveau moteur de prerendering (Prerender2) permettant au navigateur de charger et rendre complètement une page en arrière-plan, puis de l’afficher instantanément quand l’utilisateur navigue vers elle
  • Il a d’abord été utilisé dans Google Search (prerendering des premiers résultats) et pour la prédiction des URL saisies, ce qui peut réduire drastiquement le LCP
  • Chrome a indiqué que le prerendering des recherches dans l’omnibox apportait une amélioration médiane du LCP de 500 à 700 ms (environ 15 à 25 %) pour ces navigations
  • Chrome le déploie prudemment (pour éviter les mauvaises prédictions ou les problèmes de confidentialité)

• Optimisations réseau et d’ordonnancement

  • L’équipe Chrome a identifié et corrigé plusieurs petites sources de latence dans la réactivité aux entrées
  • Une fonctionnalité de préconnexion au pointer down a été introduite (au début d’un tap/clic, avant le relâchement), gagnant quelques millisecondes sur l’établissement de connexion pour la navigation par lien
  • Cela a permis un LCP en moyenne environ 6 à 10 ms plus rapide sur les navigations cross-origin
  • La manière dont le thread principal du navigateur traite les tâches lorsque plusieurs onglets sont ouverts a aussi été améliorée pour réduire la contention
  • Grâce à des ajustements de scheduling et à l’usage de mécanismes comme EcoQOS de Windows 11 pour les onglets en arrière-plan, Chrome a amélioré l’INP d’environ 5 % et le LCP d’environ 2 % dans les scénarios fortement chargés

• Améliorations du moteur de rendu et du moteur JavaScript

  • La refonte architecturale RenderingNG de Chrome (achevée vers 2021) a rendu le rendu plus efficace
  • Des améliorations de priorité de chargement des images (pour éviter qu’une image LCP soit bloquée derrière d’autres tâches moins importantes) ainsi qu’un timing plus intelligent du garbage collection de V8 (pendant les périodes d’inactivité) ont assuré une expérience plus fluide
  • Les développeurs de Chrome ont découvert que la façon dont le navigateur multi-processus accédait aux cookies provoquait du jank
    • Chaque appel à document.cookie devait auparavant être récupéré de manière synchrone depuis un processus distinct
    • En introduisant une gestion de version des cookies en mémoire partagée, Chrome a optimisé l’accès aux cookies et supprimé de nombreux allers-retours redondants entre processus
    • Cela a réduit la latence d’entrée lorsque des sites spammaient la lecture des cookies à chaque interaction

• Toutes ces optimisations de Chrome ont produit une différence mesurable

  • Fin 2023, Google indiquait que le chargement moyen des pages dans Chrome était 166 ms plus rapide qu’avant l’existence des Core Web Vitals
  • Un impact énorme à l’échelle de tout le Web : en additionnant le temps économisé, l’équipe Chrome a calculé qu’en 2023 seulement, les améliorations de vitesse avaient permis aux utilisateurs d’économiser plus de 10 000 ans de temps d’attente cumulé pour le chargement des pages, ainsi que plus de 1 200 années supplémentaires d’attente avant qu’une page réponde aux interactions
  • La part du trafic atteignant le niveau « bon » des CWV a elle aussi fortement augmenté
  • Lors de l’annonce initiale, environ un tiers des chargements de page étaient considérés comme bons selon les critères CWV, mais en 2023, environ 68 % des visites de pages sur desktop dans Chrome et 64 % sur mobile satisfaisaient aux trois seuils CWV

Améliorations à l’échelle de l’écosystème Web

• Les progrès ne viennent pas seulement de Google : l’ensemble de la communauté des développeurs Web, des frameworks et des éditeurs de plateformes s’est mobilisé pour résoudre les problèmes de performance identifiés par les Core Web Vitals

• Optimisation des images et chargement différé

  • En reconnaissant que les images sont souvent le contenu le plus volumineux et une cause fréquente du LCP, les frameworks Web et les CMS ont mis en place des valeurs par défaut plus intelligentes
  • Le loading="lazy" natif en HTML pour les images hors écran a été standardisé (avec l’aide de Chrome et de contributeurs aux standards du Web comme Yoav Weiss et Addy Osmani), puis adopté par WordPress et d’autres plateformes, réduisant fortement le chargement inutile d’images
  • Après avoir activé par défaut le chargement différé des images en 2020, WordPress l’a ensuite ajusté pour éviter que l’image de bannière principale ne soit chargée en différé, afin de ne pas retarder le LCP
  • Le nouvel attribut <img fetchpriority="high"> a été rapidement exploité par les frameworks pour signaler l’image principale à charger plus vite

• WordPress Performance Team

  • WordPress représentant environ 40 % de tous les sites Web, ses performances ont un impact immense
  • Au départ, les sites WordPress étaient en retard sur les scores CWV, et un rapport de 2021 montrait que leur taux de réussite était inférieur à celui de certains autres écosystèmes, ce qui a servi d’électrochoc
  • La communauté a réagi en constituant une Core Performance Team dédiée (avec des contributeurs de Google et d’autres entreprises) pour améliorer systématiquement la vitesse du cœur de WordPress
  • Les efforts ont porté leurs fruits dans les versions récentes
    • WordPress 6.3 (2023) incluait de nombreuses optimisations du rendu des thèmes et du chargement des assets, avec des thèmes fournis en standard qui se chargeaient, selon la métrique LCP, 27 % plus vite que WordPress 6.2 pour les block themes, et 18 % plus vite pour les thèmes classiques
    • En pratique, des millions de sites sont devenus plus rapides simplement en mettant WordPress à jour
  • L’équipe WordPress a optimisé le traitement des images, ajouté du cache pour certaines opérations coûteuses et placé les performances au même niveau de priorité que les nouvelles fonctionnalités
  • Résultat, la proportion de sites WordPress avec de bons scores CWV a fortement augmenté (certaines données montrent que la part des sites WP satisfaisant à tous les CWV a plus que quadruplé entre 2020 et 2022)

• Wix et les créateurs de sites Web

  • D’autres plateformes de création de sites hébergés comme Wix, Squarespace et Duda ont elles aussi fait des Core Web Vitals un moteur d’amélioration des performances
  • Wix a mené une refonte majeure de son infrastructure (cache, serveurs plus rapides, meilleur code côté client) et multiplié la part des sites Wix obtenant de bons scores CWV
  • Dans une étude de cas, Wix a indiqué avoir fait passer la proportion de sites avec de « bons » CWV de 4 % à plus de 33 % en environ un an
  • Cela a démontré qu’un changement culturel centré sur la performance au niveau de la plateforme peut bénéficier à un très grand nombre d’utilisateurs
  • D’autres créateurs de sites comme Duda mettent eux aussi souvent en avant le fait que la majorité des sites de leurs clients atteignent de bons CWV, car leurs plateformes intègrent les bonnes pratiques par défaut (images responsives, diffusion via CDN, templates efficaces, etc.)
  • Cette pression concurrentielle pousse les plateformes à améliorer les choses en interne, même lorsque les propriétaires de sites ne sont pas eux-mêmes experts en performance

• Frameworks JavaScript (Chrome Aurora)

  • L’équipe Chrome Aurora a été lancée mi-2020 comme une task force spécialisée au sein de Chrome pour collaborer avec les frameworks JavaScript populaires
  • Les membres d’Aurora (Addy Osmani, Kara Erickson, Houssein Djirdeh, etc.) ont travaillé étroitement avec les auteurs de frameworks comme React/Next.js, Angular, Nuxt et Gatsby afin d’identifier les goulots d’étranglement communs et proposer des solutions
  • Cette collaboration a permis d’apporter des fonctionnalités comme :
    • le composant next/script de Next.js (pour charger les scripts tiers plus efficacement hors du thread principal)
    • la directive intégrée NgOptimizedImage d’Angular (qui charge automatiquement les images en différé et règle correctement leur taille et leur priorité)
    • le module d’optimisation Google Fonts de Nuxt
  • L’impact a été significatif : en 2022, le score médian Core Web Vitals des sites construits avec ces frameworks s’est nettement amélioré
    • le taux de réussite CWV des sites Next.js est passé de 20,4 % à 27,3 %
    • Angular est passé de 7,6 % à 13,2 %
    • Nuxt s’est amélioré de 15,8 % à 20,2 %
  • Les exemples de réussite individuels sont également nombreux
    • Le site e-commerce Land's End a obtenu une amélioration de 40 % du LCP sur mobile (en test labo) après avoir adopté l’optimisation d’images d’Angular
    • CareerKarma a réduit le LCP de 24 % en utilisant le chargement de scripts amélioré de Next.js

• Indicateurs business réels

  • Au final, de meilleurs Core Web Vitals ne servent pas seulement à satisfaire Google : ils corrèlent avec la satisfaction réelle des utilisateurs et les résultats business
  • De nombreuses entreprises ont partagé des études de cas reliant les améliorations des CWV à l’engagement utilisateur
    • Le site d’actualités Economic Times a amélioré l’INP en optimisant le traitement des scripts, obtenant 42 % de pages vues en plus et 49 % de baisse du taux de rebond
    • Le site de réservation de voyages RedBus a amélioré son INP et constaté une hausse de 7 % du taux de conversion
    • La marketplace en ligne indienne Meesho a fait passer son LCP de 6,9 secondes à 2,5 secondes, obtenant environ 17 % de baisse du taux de rebond et 3 % de hausse du taux de conversion
  • Ces exemples renforcent l’idée que la performance n’est pas seulement une métrique technique : elle se traduit par des utilisateurs qui restent plus longtemps, lisent davantage et achètent plus
  • Ces réussites ont encore davantage motivé les développeurs et les équipes produit à faire des Web Vitals une priorité

Résultats des améliorations à l’échelle de l’écosystème

• Les efforts combinés des équipes navigateurs, des auteurs de frameworks, des développeurs CMS et d’innombrables développeurs Web individuels ont considérablement amélioré l’état du Web
• En établissant des métriques claires et actionnables, les Core Web Vitals ont créé un objectif commun que tous pouvaient suivre
• Fait important, cela a été accompli en s’appuyant sur des standards ouverts et des données ouvertes, sans enfermer l’écosystème dans une technologie propriétaire
• En 2023, environ 40 % des sites Web (et une proportion bien plus élevée des sites commerciaux bien maintenus) franchissaient désormais tous les seuils des Core Web Vitals, alors qu’au début de 2020, seuls quelques-uns y parvenaient
• Même les sites qui ne réussissent pas complètement sont généralement plus rapides et plus fluides qu’auparavant
• Une culture de la performance s’est diffusée : les développeurs surveillent de plus en plus les métriques CWV (selon des enquêtes, environ 51 % des développeurs suivent et optimisent activement les Web Vitals)
• Google a indiqué que, malgré cette forte poussée en faveur des gains de vitesse, la satisfaction des développeurs vis-à-vis de la plateforme Web est restée élevée
  • Cela montre que les consignes étaient atteignables, sans pousser les développeurs au découragement
  • Cet équilibre était essentiel : si les objectifs CWV avaient été impossibles à atteindre ou si les outils avaient été insuffisants, les développeurs auraient pu réagir négativement ; au lieu de cela, la communauté s’est rassemblée pour améliorer le Web

Évolution des métriques : INP, Soft Navigation, etc.

• Google a reconnu dès le départ que les Core Web Vitals évolueraient avec le temps
• Le jeu de trois métriques de 2020 n’avait pas vocation à être statique ni exhaustif
• D’autres aspects de l’expérience utilisateur, comme le défilement fluide ou les longues tâches plus tard dans la page, n’étaient pas traités au départ
• L’équipe Chrome Web Platform a continué à étudier de nouvelles métriques et des améliorations des métriques existantes

Interaction to Next Paint (INP)

• Le manque le plus clair des CWV d’origine concernait l’interactivité au-delà du premier clic
• Le FID ne mesure que le délai du premier input, ce qui est important pour la première impression, mais une page peut devenir non réactive plus tard au fil d’autres interactions utilisateur
• Pour y remédier, des Googlers comme Annie Sullivan et Michal Mocny ont proposé l’INP
  • en examinant toutes les interactions utilisateur de la page (ou du moins un grand nombre d’entre elles) et en remontant une forme de pire cas (ou le 98e percentile) du délai
  • en posant la question : « Quand un utilisateur interagit avec la page, à n’importe quel moment, combien de temps faut-il avant que la frame suivante soit peinte en réponse ? », ce qui permet de capturer la latence du traitement des événements et du rendu
• L’INP a été déployé en 2022 comme métrique de terrain expérimentale et collecté dans CrUX
• Début 2023, Google a constaté que l’INP prédisait mieux les problèmes globaux de réactivité que le FID
• Il a donc annoncé qu’en mars 2024, l’INP remplacerait le FID comme Core Web Vital
  • ce changement a été communiqué suffisamment à l’avance aux développeurs
  • des outils comme Lighthouse et PageSpeed Insights ont commencé à afficher l’INP (avec la mention « bientôt disponible comme CWV »)
  • Web.dev a fourni des recommandations pour améliorer l’INP, qui reviennent souvent aux mêmes pratiques de performance générales : découper les longues tâches, utiliser des Web Workers pour les calculs lourds, etc.
• Le passage du FID à l’INP souligne la philosophie de l’équipe CWV : faire évoluer les métriques pour mieux couvrir ce qui compte vraiment
  • en l’occurrence, garantir une réactivité constante tout au long de la visite utilisateur, et pas seulement au chargement de la page

Fluidité et animation

• Un autre aspect étudié par l’équipe Chrome est la fluidité visuelle, comme la fréquence d’images des animations et le jank du défilement
• Il ne s’agit pas encore d’une métrique CWV officielle, mais un travail est en cours sur ce sujet
• L’équipe Chrome fournit des métriques de smoothness aux outils RUM (parfois signalées comme « Jankiness » dans CrUX) afin de quantifier des phénomènes comme les animations saccadées
• Des heuristiques ont été introduites dans le navigateur pour réduire le jank
  • par exemple, en ajustant la manière dont les événements tactiles sont synchronisés avec les frames d’affichage, Chrome a doublé la fluidité de son propre défilement sur Android (comme détaillé dans le billet Fast and Curious d’août 2023)
• À l’avenir, on pourrait voir apparaître un Web Vital officiel de type « smoothness », ou une extension de l’INP pour couvrir certains délais liés à l’animation
• L’essentiel est que Google reconnaît ces aspects et mène activement des expérimentations

Soft Navigation (SPA)

• L’une des limites de la définition initiale des CWV était qu’elle se concentrait sur les chargements complets de page (les « hard navigations »)
• Or les Single-Page Applications (SPA) modernes se chargent souvent une seule fois puis mettent à jour dynamiquement le contenu et les routes sans rechargement complet
• Ces soft navigations (quand un clic sur un lien modifie le contenu via JavaScript sans déclencher une navigation complète du navigateur) n’étaient pas capturées par les mesures LCP ou CLS dans l’implémentation d’origine
  • du point de vue du navigateur, il s’agit toujours de la même page, donc une grosse mise à jour du DOM ne déclenche pas un nouveau LCP
• Cela signifiait que, pour les SPA, les développeurs devaient s’appuyer sur des mesures personnalisées pour évaluer les « transitions de page » à l’intérieur de l’application, et que les données de terrain CrUX restaient elles aussi aveugles à ces navigations ultérieures (seuls les CWV du chargement initial de la page étaient enregistrés)
• Pour corriger cela, Chrome a proposé la Soft Navigation API
  • tout le mérite de ce travail revient à Yoav Weiss
  • mi-2023, Chrome a commencé à expérimenter la détection heuristique des navigations SPA
  • d’ici mi-2025, un origin trial pour la Soft Navigations API a été lancé
• Comme l’ont expliqué les ingénieurs Chrome Barry Pollard et Michal Mocny, une soft navigation correspond au fait que « JavaScript intercepte la navigation (par exemple via la History API ou un routeur de framework) et met à jour l’URL via history.pushState tout en mettant à jour le contenu de la page existante, sans rechargement complet »
• Grâce à la nouvelle API, le navigateur (et les développeurs) peut marquer ces événements et, en substance, les traiter comme de nouvelles pages vues
• Point crucial : cela permet de mesurer les Core Web Vitals dans les SPA comme si ces changements de route soft étaient des chargements de page
• Avec cette API, des métriques comme le LCP peuvent être réinitialisées lors d’une soft navigation et capturer le plus grand contenu de la nouvelle vue (en utilisant le concept d’entrée "interaction-to-next-paint" dans la Performance Timeline)
• De même, le CLS peut être segmenté par navigation, et l’INP peut être associé à la vue courante
• C’est une avancée majeure pour apporter les CWV au monde des applications à routage côté client, aujourd’hui très répandues
• Fin 2025, la Soft Nav API est toujours en phase d’essai et les développeurs peuvent s’y inscrire et envoyer leurs retours
• Avec le temps, on peut s’attendre à ce que Chrome prenne totalement en charge les métriques de soft nav et que les données de terrain (CrUX) les intègrent elles aussi
• Cette évolution reconnaît que le parcours utilisateur est composé de plusieurs étapes et ne se résume pas au seul chargement de la page d’atterrissage ; la plateforme web doit mesurer et optimiser l’ensemble du parcours

Évolutions à venir

• Google a indiqué qu’il continuerait à améliorer les métriques chaque année
• On pourrait voir apparaître des ajustements comme de nouveaux seuils
  • par exemple, si le web devient globalement plus rapide, l’objectif d’un « bon » LCP pourrait à l’avenir devenir plus strict que 2,5 secondes
  • ou des métriques entièrement nouvelles si un manque clair apparaît
• Tous les ajouts passent par un processus public (définition dans les standards de performance web, discussions avec les autres éditeurs de navigateurs, etc.), comme cela a été le cas pour l’INP
• Google prévoit aussi d’intégrer davantage de signaux d’expérience de page au fil du temps
  • par exemple, des expérimentations sur la confidentialité et la sécurité, comme l’affichage via Chrome d’un badge « fast page » si un site applique de bonnes pratiques
• Mais dans le contexte du classement Search, Google a récemment simplifié son message
  • en 2023, il a indiqué qu’il n’y aurait plus de booster de classement explicite de type « page experience » au-delà des signaux individuels
  • en substance, les considérations liées à l’expérience de page sont intégrées plus subtilement dans l’algorithme de classement principal
  • mais du point de vue des propriétaires de sites, rien ne change
  • des pages rapides, réactives et stables restent fondamentalement importantes à la fois pour la satisfaction utilisateur et pour un bon SEO

En résumé

• L’histoire des Core Web Vitals est celle d’une plateforme web qui relève les défis
  • elle commence par l’idée que la qualité de l’expérience utilisateur doit pouvoir être mesurée et récompensée, puis se transforme en un vaste mouvement touchant les métriques, les navigateurs, le classement dans les moteurs de recherche, les outils, les frameworks et les plateformes d’hébergement
  • en seulement quelques années, elle a entraîné des améliorations significatives de la performance web dans son ensemble
  • le parcours continue : avec des innovations à venir comme la mesure des soft navigations pour les SPA et l’amélioration continue des métriques, l’engagement du secteur en faveur d’une expérience web rapide et agréable reste fort
• Les Core Web Vitals se sont révélés être non pas un simple ensemble de métriques, mais un catalyseur d’un web plus sain, plus rapide et plus centré sur l’utilisateur
  • un héritage construit grâce à la coopération de nombreuses personnes, et dont bénéficieront tous ceux qui utilisent le web