Méthode INP
Je commence par l’interaction et la sous-partie INP. Ensuite, j’identifie si le coût vient du traitement JavaScript, du rendu React, du layout/paint ou d’un script tiers. Une fois la famille trouvée, je descends vers les sources via sourcemaps, noms de composants, URL de bundles ou instrumentation.
Dans Chrome DevTools Performance, enregistre une interaction, clique l’élément dans la piste Interactions, puis lis le détail Input delay, Processing duration et Presentation delay.
Où le trouver
Dans Performance, clique l'interaction dans la piste Interactions. Le panneau de détail affiche la durée entre l'action utilisateur et le début du traitement.
Pourquoi ça compte
Si cette partie est haute, le main thread était déjà occupé avant même que ton handler démarre. Il faut chercher une tâche précédente, un script tiers ou un rendu déjà en cours.
Où le trouver
Toujours dans le détail de l'interaction, cette sous-partie couvre le temps passé à traiter l'événement : handler, React, calculs, mises à jour d'état.
Pourquoi ça compte
Si cette partie est haute, le problème vient souvent du code déclenché par l'interaction : calcul synchrone, re-render trop large, logique métier ou effet de bord.
Où le trouver
Dans le détail de l'interaction, cette sous-partie commence après le traitement JS et se termine quand le navigateur affiche le rendu suivant.
Pourquoi ça compte
Si cette partie est haute, le calcul est peut-être fini, mais le navigateur met du temps à produire le rendu : style, layout, paint, DOM trop lourd ou image coûteuse.
Si la trace ne donne pas immédiatement une fonction métier évidente, il faut d’abord classer la famille du coût. C’est ce classement qui guide la correction.
Signal dans DevTools
Bottom-up montre une fonction applicative avec un Self time élevé, par exemple dans page.tsx, lib ou un composant métier.
Action probable
Réduire l'algorithme, pré-calculer, filtrer moins de données, déplacer vers le serveur ou découper le travail.
Signal dans DevTools
La trace montre surtout React, beaucoup de petits composants, peu de fonction métier dominante, et une mise à jour qui touche trop d'interface.
Action probable
Réduire la zone qui re-render, isoler l'état, mémoriser les composants coûteux, limiter la liste rendue ou virtualiser.
Signal dans DevTools
Main montre Recalculate style, Layout, Pre-paint ou Paint avec des durées visibles autour de l'interaction.
Action probable
Réduire le DOM, stabiliser les dimensions, éviter les lectures/écritures layout répétées et simplifier les styles coûteux.
Signal dans DevTools
Bottom-up ou Call tree montre un domaine externe, un tag manager, analytics, AB testing ou un bundle qui n'appartient pas au code produit.
Action probable
Mesurer l'impact, charger plus tard, limiter les déclencheurs, isoler le script ou négocier sa nécessité métier.
Un rendu React trop large arrive quand une interaction modifie un état placé trop haut ou trop global, puis force une grande partie de l’arbre de composants à se recalculer alors que peu d’éléments visibles changent réellement.
Exemple catalogue : un filtre change une catégorie, mais toute la page re-render, toutes les cards recalculent leurs prix, badges, images, disponibilités et états, puis le navigateur doit réconcilier beaucoup trop de DOM avant de peindre la réponse.
Articles, conférences et vidéos à garder sous la main pour approfondir l’analyse des interactions et des traces Performance.
Une lecture pratique du panneau Performance pour réduire le bruit visuel, isoler les signaux utiles et analyser une trace sans se perdre.
Astuce pour une meilleure INP, await interaction VS yield
Lexique et explication de la métrique Interaction to Next Paint.