React Compiler vs mémoïsation manuelle

May 24, 2026 · 5 min read

Pendant des années, l’optimisation des performances de React se résumait à une chose : parsemer son code de useMemo, useCallback et React.memo en espérant ne pas se tromper dans les tableaux de dépendances. React Compiler change la donne. Mais dans quelle mesure ? Et la mémoïsation manuelle a-t-elle encore sa place dans les applications React modernes ?

Voici ce qu’il faut vraiment savoir.

Points clés à retenir

React Compiler est un outil au moment de la compilation qui applique automatiquement l’équivalent de React.memo, useMemo et useCallback à partir d’une analyse statique.
Il excelle dans le traitement des schémas courants comme les props de callback, les enfants passés en props et les valeurs de retour des hooks personnalisés.
La mémoïsation manuelle reste pertinente pour les hooks tiers qui renvoient des objets instables, les dépendances d’effets et les goulots d’étranglement identifiés au profilage.
Le nouvel état d’esprit : écrire des composants propres par défaut, et mémoïser de manière délibérée lorsqu’on a une raison mesurable de le faire.

Ce que fait React Compiler

React Compiler est un outil exécuté au moment de la compilation qui mémoïse automatiquement vos composants, leurs props et les valeurs de retour des hooks. Il analyse votre code à la compilation et applique des optimisations équivalentes à un enveloppement par React.memo, useMemo et useCallback, sans que vous ayez à écrire ce code.

Il est désormais stable et prêt pour la production, utilisé en production chez Meta et pris en charge par Babel, Vite, Metro et Rsbuild. Next.js 15.3.1+ prend en charge l’invocation de React Compiler via SWC pour de meilleures performances de build.

Le mot clé est au moment de la compilation. React Compiler n’est pas un cache d’exécution pour des valeurs arbitraires. Il se concentre spécifiquement sur l’optimisation des re-renders de composants, à partir d’une analyse statique de la structure de votre code.

Là où React Compiler gère la mémoïsation automatiquement

Le compilateur traite proprement les cas courants :

Changements d’état simples — un composant frère qui ne dépend pas de l’état modifié ne sera pas re-rendu.
Props avec callbacks — les fonctions fléchées inline passées en props sont correctement mémoïsées, même imbriquées.
Enfants passés en props — le pattern notoirement délicat useMemo(() => <Child />, []) devient inutile.
Hooks personnalisés — les valeurs de retour sont mémoïsées en fonction de leurs véritables dépendances.

Le troisième cas mérite qu’on s’y attarde. La plupart des développeurs s’y prennent mal en manuel. Le compilateur, lui, le gère correctement de manière automatique.

Là où la mémoïsation manuelle en React reste pertinente

Des tests en conditions réelles, menés sur plusieurs bases de code, racontent une histoire plus nuancée. Le compilateur traite bien les composants isolés et autonomes. Il peine lorsque des bibliothèques tierces renvoient des objets non mémoïsés.

L’exemple le plus parlant : le hook useMutation de React Query renvoie un nouvel objet à chaque render. Si votre callback onDelete dépend de deleteCountryMutation plutôt que de la fonction mutate déstructurée directement, le compilateur ne peut pas le stabiliser. La solution est simple une fois qu’on la connaît : déstructurer mutate directement. Mais le compilateur ne peut pas prendre cette décision à votre place.

// Compiler-friendly: stable reference
const { mutate: deleteCountry } = useMutation(...)

// Compiler-unfriendly: new object every render
const deleteCountryMutation = useMutation(...)
const onDelete = () => deleteCountryMutation.mutate(name)

Autres cas où le contrôle manuel reste préférable :

Dépendances d’effets — quand vous avez besoin d’une valeur mémoïsée précisément pour empêcher useEffect de se déclencher en boucle.
Listes dynamiques — les lignes rendues à l’intérieur d’un .map() gagnent à être extraites dans des composants nommés avec des props key stables. Le compilateur optimise mieux à l’intérieur des composants qu’à travers le rendu inline.
Optimisation de performance après profilage — si vous avez mesuré un goulot d’étranglement précis, un useMemo explicite vous offre un contrôle fin que les heuristiques du compilateur ne peuvent égaler.

Comment vos habitudes de codage React devraient évoluer

Le changement de modèle mental est simple : arrêtez de mémoïser par réflexe défensif, mémoïsez de manière délibérée.

Avant le compilateur, la pratique par défaut consistait à tout envelopper, au cas où. Cela ajoutait du bruit, une charge de maintenance, et introduisait parfois des bugs subtils (comme le piège du useCallback combiné à une fonction fléchée inline que la documentation officielle met désormais en avant).

Avec React Compiler activé, la nouvelle approche par défaut consiste à écrire des composants propres et simples, et à laisser le compilateur gérer l’optimisation. Sortez useMemo ou useCallback de votre boîte à outils lorsque vous avez une raison précise et mesurable, et non par réflexe.

Deux habitudes pratiques à adopter dès maintenant :

Extraire les éléments de liste dans des composants nommés — <CountryRow /> au lieu d’un JSX inline dans un .map().
Déstructurer les valeurs stables des hooks tiers — utilisez mutate directement, et non l’objet de mutation complet.

L’essentiel à retenir en pratique

React Compiler représente une véritable avancée pour l’optimisation des performances React. Il élimine la majeure partie de la mémoïsation défensive qui encombrait les bases de code, et il gère le pattern délicat des enfants-en-props mieux que la plupart des développeurs ne le font manuellement.

Mais il ne remplace pas la compréhension du fonctionnement des re-renders React. Les développeurs qui tireront le plus de profit du compilateur seront ceux qui maîtrisent encore les compromis entre useMemo et React Compiler, et qui savent quand recourir à l’un ou à l’autre.

Conclusion

React Compiler marque un véritable tournant dans notre façon de penser la performance en React. Le réflexe d’envelopper chaque valeur et chaque fonction dans un helper de mémoïsation n’est plus la bonne approche par défaut. Écrivez du code plus simple, laissez le compilateur faire son travail, et profilez avant d’optimiser manuellement. Gardez la mémoïsation manuelle dans votre boîte à outils pour les cas que le compilateur ne perçoit pas, notamment autour des hooks tiers et des goulots d’étranglement mesurés. C’est l’approche qui tient la route en 2026 et au-delà.

FAQ

Oui. Le compilateur prend en charge la majeure partie de la mémoïsation défensive, mais vous devez toujours comprendre ces hooks pour les cas qu'il ne peut pas optimiser, comme les objets instables renvoyés par des bibliothèques tierces, les dépendances d'effets et les goulots d'étranglement de performance mesurés. Comprendre le fonctionnement des re-renders vous aide aussi à écrire du code que le compilateur pourra optimiser plus efficacement.

Non. React Compiler est conçu pour coexister avec les appels existants à useMemo, useCallback et React.memo. Vous pouvez l'adopter de manière progressive sans supprimer votre mémoïsation actuelle. Avec le temps, vous pourrez nettoyer la mémoïsation manuelle redondante, mais il n'y a aucune urgence à la retirer avant d'activer le compilateur dans votre projet.

L'objet de mutation renvoyé par useMutation possède une nouvelle référence à chaque render. Le compilateur ne peut pas déterminer que ses méthodes internes sont stables, donc tout callback dépendant de l'objet entier est recréé. Déstructurer directement la fonction stable mutate depuis useMutation résout le problème et permet au compilateur de mémoïser correctement les callbacks dépendants.

Il prend en charge Babel, Vite, Metro et Rsbuild, et Next.js 15.3.1 et versions ultérieures l'activent via SWC. La plupart des configurations React modernes peuvent l'adopter avec une configuration minimale. Consultez la documentation officielle de React Compiler pour obtenir la liste à jour des chaînes d'outils prises en charge et les étapes de configuration spécifiques à chaque framework avant de l'intégrer en production.

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.