Chrome 151’s Soft Navigations API permet enfin aux applications monopages (SPA) de rapporter les Core Web Vitals pour chaque navigation interne, mais le jeu de données CrUX de Google ne comptabilise toujours que le premier chargement initial (hard load), laissant les développeurs face à deux visions divergentes de la performance.

Pourquoi les métriques des SPA ont pris du retard

Les Core Web Vitals — Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) et Cumulative Layout Shift (CLS) — ont été définis autour des navigations classiques (hard navigations). Une navigation classique récupère un tout nouveau document et abandonne l'état de la page précédente.

Les SPA construites avec React, Vue, Next.js ou des frameworks similaires déclenchent rarement des navigations classiques. Cliquer sur un lien met à jour l'URL via l'API History, récupère des données en arrière-plan et remplace le contenu sans rechargement complet. L'API Performance actuelle ne capture que le chargement initial de la page, de sorte que le LCP et l'INP ne perçoivent jamais la latence ressentie par les utilisateurs lorsqu'ils passent d'une route à une autre.

Cet angle mort fausse les tableaux de bord qui extraient des données de la Performance Timeline ou du Chrome User Experience Report (CrUX) de Google. Ils affichent souvent un LCP excellent pour la page « shell » (coquille) tout en ignorant les chargements plus lents au cœur de l'application, donnant ainsi un faux sentiment de santé de la performance.

L'API Soft Navigations de Chrome

Chrome 151 a introduit la Soft Navigations API, un ensemble d'heuristiques qui traite certaines interactions de SPA comme de véritables navigations. L'API surveille trois signaux :

  • Une interaction initiée par l'utilisateur (clic, tap, événement clavier)
  • Un changement d'URL via l'API History
  • Des événements de rendu (paint) consécutifs qui affichent du nouveau contenu

Lorsque ces trois éléments s'alignent, Chrome enregistre une navigation douce (soft navigation) dans la Performance Timeline, et les Core Web Vitals sont calculés pour cette transition, tout comme pour une navigation classique. La bibliothèque open-source web-vitals a ajouté la prise en charge le 21 juillet, permettant aux développeurs de commencer à extraire ces chiffres avec l'API qu'ils utilisent déjà.

En pratique, vous voyez désormais une valeur LCP pour chaque changement de route, un INP qui reflète la latence réelle de la dernière interaction utilisateur, et un CLS qui capture les décalages de mise en page (layout shifts) après une navigation douce.

La division des données : Chrome vs CrUX

Le CrUX (Chrome User Experience Report) de Google alimente PageSpeed Insights, la Search Console et, indirectement, les signaux de classement. Le CrUX n'agrège toujours que les données de navigation classique.

Par conséquent, vous vous retrouvez avec deux flux de données cohérents mais différents :

  • Les outils internes qui lisent la Performance Timeline affichent désormais le LCP, l'INP et le CLS au niveau de la route, offrant une vue réaliste de l'expérience utilisateur dans une SPA.
  • Les jeux de données publics de Google continuent d'afficher les métriques uniquement pour le premier chargement de page, ce qui correspond aux rapports de la Search Console et aux références des algorithmes de classement de Google.

Les deux sont corrects ; ils mesurent simplement des moments différents. Se fier uniquement à la Search Console peut masquer des régressions de performance survenant après le chargement initial, tandis que les tableaux de bord internes seuls ne refléteront pas la référence (baseline) utilisée par Google pour le SEO.

Ce que les développeurs doivent surveiller

  • Support des navigateurs – La Soft Navigations API n'existe aujourd'hui que dans les navigateurs basés sur Chromium. Safari et Firefox n'ont pas d'équivalent, vous devez donc conserver une logique de repli (fallback) pour une partie de votre audience.
  • Limites heuristiques – L'API détermine une navigation douce en se basant sur un ensemble d'indices. Si votre application met à jour le contenu sans changer l'URL (par exemple, des fenêtres modales ou un défilement infini), l'API peut manquer ces transitions, créant des lacunes dans les données.
  • Tester avant de faire confiance – Comme la détection est heuristique, exécutez une série d'interactions en conditions réelles sur votre application et comparez les métriques rapportées avec un chronométrage manuel (par exemple, en utilisant performance.mark). Ce n'est qu'après avoir confirmé l'exactitude que vous devrez baser vos décisions d'optimisation sur ces nouveaux chiffres.

L'essentiel

Chrome 151 offre aux développeurs de SPA la capacité tant attendue de mesurer le LCP, l'INP et le CLS pour chaque changement de route interne, mais les données de classement de Google ne reflètent toujours que le premier chargement classique. En attendant que le CrUX rattrape son retard, les équipes doivent jongler avec deux ensembles de données parallèles : l'un qui raconte la véritable expérience utilisateur, et l'autre qui pilote le classement dans les moteurs de recherche. Équilibrer les deux — et se préparer à un support navigateur plus large — sera essentiel pour maintenir des SPA axées sur la performance dans un écosystème web compétitif.