La performance React en pratique : une checklist qui sert vraiment

La plupart des conseils de performance React commencent par des solutions : mémoïse ceci, virtualise cela. En pratique, une application est le plus souvent lente pour une raison que personne n’a encore mesurée. Cette checklist commence donc là où le travail commence vraiment : trouver ce qui est lent, puis appliquer la correction qui correspond à la cause, dans cet ordre.

1. Mesurer avant de toucher à quoi que ce soit

Ouvrez le Profiler des React DevTools, enregistrez l’interaction qui semble lente, et regardez deux choses : quels composants ont rendu, et pourquoi. Vérifiez ensuite le panneau Performance du navigateur pour la même interaction, parce que parfois le coût n’est pas React du tout, mais du layout thrash, des images surdimensionnées ou un script tiers.

Deux règles à garder :

• Profilez en build de production. Le mode développement est nettement plus lent et ment sur où part le temps.
• Profilez avec des données réalistes. Dix lignes de démo cachent le problème que mille lignes réelles révéleront, et l’écart est le plus grand sur les écrans riches en données comme les dashboards d’enquête de gPulse.

2. Corriger les re-renders à la source

Le constat le plus courant : une interaction re-rend bien plus d’arbre que nécessaire. Avant de dégainer memo, restructurez :

• Descendez l’état. Un état placé haut dans l’arbre re-rend tout ce qui est en dessous. Un état de survol, la valeur d’un champ, un drapeau ouvert/fermé : déplacez chacun vers le plus petit composant concerné.
• Passez des children au lieu de rendre à l’intérieur. Un composant qui reçoit children ne les re-rend pas quand son propre état change. Ce seul pattern élimine des classes entières de renders inutiles, gratuitement.
• Puis mémoïsez ce qui reste. memo, useMemo et useCallback sont pour les chemins chauds que le profiler montre réellement : des sous-arbres coûteux qui reçoivent des props stables. Saupoudrés partout « au cas où », ils ajoutent du bruit et masquent l’intention.

3. Dériver les données une fois, pas à chaque render

Transformer les données d’API (filtrer, grouper, calculer des séries d’affichage) dans le chemin de rendu est une taxe silencieuse sur chaque interaction. Dérivez une fois par changement de données (useMemo calé sur la source), et gardez le formatage léger au niveau des feuilles. Dans les UIs riches en graphiques, cela vaut régulièrement plus que n’importe quelle optimisation de rendu.

4. Virtualiser les longues listes, mais seulement les longues

Une liste qui rend des milliers de nœuds DOM sera lente quelle que soit la mémoïsation. Le windowing (ne rendre que la tranche visible) règle le problème. Le seuil en pratique : sous quelques centaines de lignes simples, inutile. La complexité ajoutée par la virtualisation (restauration du scroll, accessibilité, hauteurs variables) n’est pas gratuite.

5. Vérifier ce que vous livrez, pas seulement ce que vous rendez

La performance à l’exécution et la performance de chargement sont deux problèmes différents ; les utilisateurs ressentent les deux.

• Lancez un analyseur de bundle et regardez les dix plus gros modules. Il y a presque toujours une surprise : une bibliothèque de graphiques importée en entier pour un seul graphique, une bibliothèque de dates là où Intl suffirait.
• Découpez le code par route et chargez les widgets lourds en dynamique.
• Laissez le framework aider : dans Next.js, les Server Components gardent des arbres de dépendances entiers hors du client, et next/image gère le volet médias. La performance de chargement recouvre largement le SEO ; j’en parle dans Le SEO avec le App Router de Next.js.

6. Re-mesurer, et noter le chiffre

Après chaque correction, profilez à nouveau la même interaction. Deux raisons : confirmer que la correction a fait ce que vous pensiez (pas toujours), et prendre l’habitude d’attacher des chiffres aux affirmations. « Le dashboard rend en 80 ms, contre 600 ms avant » résiste à l’examen ; « c’est plus fluide » non.

Le résumé inconfortable

Le travail de performance React tient rarement à des APIs exotiques. C’est mesurer, restructurer l’état, faire moins de travail par render, et livrer moins de code, dans cet ordre, en s’arrêtant quand les chiffres le permettent. Si votre application a besoin de ce traitement et que vous préférez ne pas le faire seul, l’optimisation des performances fait partie de ce que je propose, alors parlons-en.