Chrome DevTools : l'analyse des soft navigations des SPA est complète, avec un niveau de CPU forçable
On peut désormais analyser dans DevTools la vitesse des « changements de page » d’une SPA, et reproduire par le code des tests de performance pour différents niveaux de matériel.
Chrome DevTools a ajouté deux fonctions de performance pour les développeurs de SPA (des applications web qui changent l’écran sans recharger toute la page). La première est l’analyse des soft navigations dans les Insights du panneau Performance. La seconde est une commande du Chrome DevTools Protocol (CDP, l’interface pour piloter DevTools par le code) qui fixe un niveau de performance du CPU. Les deux figurent dans l’article de mise à jour de DevTools de Chrome for Developers (pour Chrome 153 et 154, publié le 22 septembre).
Ce qu’est une soft navigation
Normalement, un clic sur un lien fait charger une nouvelle page depuis le serveur. Une SPA fonctionne autrement : JavaScript ne change que l’URL dans la barre d’adresse et remplace une partie de l’écran. Pour l’utilisateur, cela ressemble à un changement de page, mais le navigateur ne sait pas qu’« une nouvelle page a été ouverte ».
Pour cette raison, la mesure de chargement (LCP) n’était prise qu’une fois, au premier chargement, et les changements d’écran suivants échappaient à la mesure. L’API Soft Navigations vise à traiter ces changements comme des navigations et à mesurer leurs performances séparément.
- Dans Chrome 152, la prise en charge des soft navigations est arrivée dans les Live Metrics et les vues de trace de DevTools.
- Une analyse vient maintenant d’être ajoutée aux Insights du panneau Performance, ce que Chrome décrit comme « une prise en charge complète, de la mesure à l’analyse ».
Fixer un niveau de performance du CPU par le code
- La nouvelle commande CDP est
Emulation.setCPUPerformanceOverride. Elle fixe un niveau de performance du CPU calibré, ce qui, selon Chrome, permet des « tests de performance reproductibles d’un niveau de matériel à l’autre ». - L’ancienne approche (
Emulation.setCPUThrottlingRate) ralentissait le CPU d’un facteur fixe, comme « 4 fois plus lent ». La nouvelle approche mesurerait d’abord les performances réelles de votre propre PC, créerait des repères comme « mobile d’entrée de gamme » et « mobile de milieu de gamme », puis s’alignerait sur ces niveaux.
Les détails (quels niveaux existent, comment fonctionne la calibration) ne sont pas expliqués longuement dans l’article de Chrome. Les préréglages de calibration sont décrits d’après la documentation de DevTools sur le throttling.
Affirmations que nous n’avons pas pu confirmer
- « Une surveillance intégrée avec la Soft Navigation Timing API est fournie » : la prise en charge de l’analyse dans DevTools et la publication complète de l’API sont deux choses distinctes. Dans un article du 20 avril, Chrome a ouvert un dernier origin trial (une période de test où des sites choisis peuvent essayer une fonction en avance) couvrant Chrome 147 à 149 et a seulement dit prévoir de lancer l’API plus tard cette année. Nous n’avons pas pu confirmer si elle a été entièrement lancée depuis. Certains articles extérieurs disent qu’elle est livrée, mais cela n’a pas pu être confirmé à partir des documents de Chrome.
- « Cible des frameworks comme React et Next.js » : nous n’avons trouvé aucune mention de frameworks dans l’article de Chrome. Le périmètre semble être les changements d’écran de type SPA en général, pas des frameworks précis.
- « Un ensemble de commandes » : la seule nouvelle commande CDP confirmée dans l’article de Chrome est
Emulation.setCPUPerformanceOverride. - Date : l’article de Chrome a été publié le 22 septembre (le titre de la page indique « October 2026 »).
Ce qui pourrait changer pour les développeurs
Ce qui suit est notre estimation et nos conseils à partir de l’article officiel.
- Ce que l’on peut essayer tout de suite. Dans Chrome 153 ou version ultérieure, les Insights du panneau Performance peuvent montrer les goulots d’étranglement par changement d’écran d’une SPA. C’est utile pour trouver « ce qui est lent quand on passe d’une route à l’autre » au lieu de ne regarder que le premier chargement.
- Collecter des données d’utilisateurs réels est encore prématuré. L’API Soft Navigations n’est pas entièrement publiée ; il faut vérifier séparément la prise en charge par les navigateurs avant de l’utiliser pour collecter les performances de transition de vrais visiteurs.
- Mêmes conditions dans les tests automatisés. En CI (des vérifications lancées automatiquement à chaque envoi de code) ou dans des tests de bout en bout (avec des outils qui pilotent un navigateur automatiquement, comme Puppeteer et Playwright), fixer un niveau de CPU permet de comparer plus facilement, sur la même base, si un changement a ralenti l’application.
- Comparer sur la même machine. Les niveaux sont construits en calibrant les performances de chaque PC. La base peut différer d’un collègue à l’autre et d’une machine de CI à l’autre : il est plus sûr de comparer dans le même environnement.
À suivre
La date de publication complète de l’API Soft Navigations et sa prise en charge par d’autres navigateurs, la documentation officielle et les paramètres de Emulation.setCPUPerformanceOverride, et la façon dont des frameworks comme Next.js s’appuient sur les soft navigations.
Sources
Source: developer.chrome.com