Chrome DevTools 145 : enfin des outils utiles pour profiler les “soft navigations”

Sur une app moderne (SPA, MPA “boostée”, micro-fronts), le vrai ressenti utilisateur se dégrade rarement sur le premier chargement. Il se dégrade entre deux écrans : clic → attente → UI qui freeze → input qui lag → INP qui explose. Et pendant longtemps, DevTools vous laissait un peu seul pour prouver que la navigation interne était le problème.

Avec Chrome DevTools 145, on a enfin un combo d’outils qui sert à quelque chose au quotidien : traces de soft navigations, profiling plus précis (jusqu’au niveau ligne), et une colonne “render-blocking” dans Network pour arrêter de deviner ce qui bloque le rendu. Voici un workflow simple, répétable, et orienté “avant/après”.

C’est quoi une “soft navigation” (et pourquoi ça vous plombe l’INP)

Une soft navigation, c’est une navigation “ressentie” par l’utilisateur (changement de vue, de contenu principal, d’URL parfois), sans rechargement complet de la page. Typiquement :

• clic sur un lien interne dans une SPA (React/Vue/Angular) ;

• changement de route côté client ;

• une MPA qui intercepte et rend côté client (PJAX/Turbo/…);

• des transitions “app-like” qui changent tout sauf le document.

Le piège : sur ces navigations, vous pouvez avoir un thread principal saturé (JS, layout, style recalculation), des ressources qui bloquent le rendu, et des handlers d’input qui lag. Résultat : l’INP (et le ressenti) prennent cher… sans que ce soit visible dans vos métriques “page load” classiques.

Le workflow DevTools 145 : diagnostiquer une navigation interne en 10 minutes

L’objectif n’est pas de “regarder un flame chart au hasard”. L’objectif est d’obtenir :

• un point de départ (scénario reproductible) ;

• une trace qui isole la soft navigation ;

• un coupable actionnable (fonction/ligne, ressource bloquante) ;

• un avant/après qui démontre le gain.

1) Verrouillez un scénario reproductible

Choisissez une navigation interne qui fait mal (souvent : liste → détail, search → résultats, dashboard → onglet). Et fixez une règle :

• même machine / même profil Chrome ;

• cache désactivé (ou au moins “Disable cache” le temps du test) ;

• un seul onglet ;

• si possible, throttling CPU x4 pour rendre les problèmes évidents.

Le but n’est pas de simuler un monde parfait, mais de rendre le signal impossible à ignorer.

2) Enregistrez dans Performance et déclenchez la soft navigation

Ouvrez Performance, lancez un enregistrement, puis :

• attendez 1–2 secondes (pour avoir du “calme” avant l’action) ;

• cliquez pour déclencher la navigation interne ;

• attendez que l’écran ait fini de “bouger” ;

• stoppez l’enregistrement.

DevTools 145 met mieux en avant des traces de soft navigations dans la timeline. En clair : vous n’êtes plus obligé de “deviner” où commence votre navigation dans un bruit de events.

3) Isolez la soft navigation dans la trace (le vrai point de départ)

Une fois la trace affichée, cherchez le segment associé à la soft navigation et focalisez-vous dessus. À partir de là, vous voulez répondre à trois questions :

• Qu’est-ce qui monopolise le Main Thread au moment du changement d’écran ?

• Y a-t-il des Long Tasks qui coïncident avec un freeze ou une interaction ?

• Qu’est-ce qui retarde le rendu (styles, fonts, JS, layout) ?

Astuce : si vous voyez “un gros bloc jaune” (scripting) pile au clic, c’est rarement un mystère. C’est votre app qui fait trop de boulot synchronement.

Le game changer : un profiling plus précis (jusqu’au niveau ligne)

Le problème classique du profiling JS : vous trouvez “une fonction” dans un bundle minifié, et ça finit en chasse au trésor (source map, grep, suppositions).

DevTools 145 améliore le profiling précis au niveau ligne (selon votre configuration et vos sourcemaps). En pratique, ça vous permet de passer :

• d’un “ça vient du bundle app.js”

• à “c’est cette boucle ou cette fonction à telle ligne qui coûte 80ms”.

Et là, le debugging devient enfin un boulot d’ingénieur, pas de devin.

Ce que vous cherchez dans le flame chart

• Long Tasks : tout ce qui bloque le thread principal et retarde la réponse aux inputs.

• Hot paths : une même fonction appelée trop souvent (render/reconcile, diff, validation, formatage, tri…).

• Layout thrashing : alternance lecture/écriture DOM (getBoundingClientRect → style change → reflow → repeat).

Network : la colonne “render-blocking” arrête le débat

Deuxième source de lenteur sur navigation interne : vous déclenchez un changement de vue, et soudain l’app doit charger :

• une feuille CSS (ou un chunk CSS) ;

• une police ;

• un chunk JS de route ;

• des assets critiques.

Et si une ressource est render-blocking, vous pouvez avoir la sensation que “rien ne se passe”, même si le réseau n’est pas si lent.

DevTools 145 ajoute une colonne dédiée dans Network pour identifier plus clairement ce qui bloque le rendu. Concrètement, ça rend beaucoup plus facile :

• de repérer un CSS chargé trop tard ;

• de voir une police qui retarde l’affichage (FOIT/flash) ;

• de relier une navigation interne à un chunk “critical” mal préchargé.

Quoi corriger en priorité (et comment le prouver)

Une fois que vous avez : (1) une soft navigation isolée, (2) un coût main thread, (3) une ressource render-blocking… vous êtes dans la zone “action”. Voilà les fix les plus rentables.

1) Réduire les Long Tasks (le vrai tueur d’INP)

Objectif : éviter les gros blocs JS synchrones au moment du clic/navigation.

• Découpez le travail (chunking) : traiter 5 000 items en 10 batches plutôt qu’un seul bloc.

• Déplacez le non-critique après le rendu (idle / post-render).

• Offloadez si pertinent (Web Worker) pour parsing/tri/formatage lourd.

Si vous devez instrumenter pour confirmer, gardez ça simple :

// Instrumentation minimale pour corréler une navigation interne à un coût JS
performance.mark('nav:start');

// ... déclenchement de route / rendu ...

performance.mark('nav:ui-ready');
performance.measure('soft-nav', 'nav:start', 'nav:ui-ready');
console.log(performance.getEntriesByName('soft-nav').pop());

Ça ne remplace pas DevTools, mais ça vous donne un chiffre “avant/après” exploitable en PR.

2) CSS et rendu : stop au “late critical CSS”

Sur soft navigation, un chunk CSS chargé trop tard peut donner une impression de page vide ou instable. Pistes concrètes :

• précharger le CSS critique de la route (ou le regrouper intelligemment) ;

• éviter de charger 4 frameworks CSS partiels par écran ;

• réduire les recalculs de style (classes togglées en masse, sélecteurs trop coûteux).

3) Fonts : améliorez le ressenti, pas seulement le score Lighthouse

Les polices peuvent impacter le rendu (et la stabilité visuelle). Sur navigation interne, vous voulez éviter les surprises :

• font-display: swap (ou une stratégie adaptée) pour éviter un écran vide ;

• précharger uniquement les variantes réellement utilisées ;

• limiter les familles et graisses “au cas où”.

4) Code-splitting : chargez plus tôt ce que vous savez que l’utilisateur va demander

Si la navigation interne dépend d’un chunk JS de route, vous avez trois options :

• préfetch au hover / à l’intention (à manier avec soin) ;

• préload quand le parcours est prévisible (ex: après login → dashboard) ;

• réduire le poids du chunk (dépendances, locales, librairies “utilitaires” énormes).

Un process “avant/après” qui tient en une checklist

• Enregistrer une trace Performance sur un scénario fixe.

• Isoler la soft navigation dans la timeline.

• Identifier le coût principal : Long Task JS, layout/style, ou ressource bloquante.

• Utiliser le profiling ligne par ligne pour pointer du doigt une zone de code.

• Vérifier Network et la colonne render-blocking pour les ressources critiques.

• Corriger 1 seule chose, refaire la trace, comparer.

Ce dernier point est important : si vous modifiez 12 paramètres, vous ne saurez jamais ce qui a réellement amélioré le ressenti.

Ce que DevTools 145 change vraiment

La nouveauté n’est pas “une feature de plus”. C’est la capacité à transformer une navigation interne lente en bug perf actionnable :

• la trace vous dit : “ici, soft navigation” ;

• le profiling vous dit : “ici, cette ligne coûte cher” ;

• le réseau vous dit : “ici, ça bloque le rendu”.

Et ça, c’est exactement ce qu’il faut pour arrêter les débats stériles (“ça lag chez moi”) et passer à une optimisation mesurable.

Sources

• Chrome for Developers — What’s new in DevTools (Chrome 145)