La performance de React en 2026 : l’architecture avant useMemo

Pendant longtemps, les conseils pour améliorer les performances de React suivaient un rituel bien précis : en cas de réaffichage, on enveloppait le code avec memo ; en cas de calcul, on utilisait useMemo ; pour transmettre une fonction, on l’enveloppait avec useCallback. Si un composant semblait trop volumineux, on le divisait. On répétait ce processus. Cette méthode a fonctionné suffisamment souvent pour devenir une sorte de mémoire musculaire.

Le centre de gravité de React a changé. Les API ne sont pas devenues soudainement inutiles. Ce qui a changé, c’est que l’optimisation passe d’une tâche gérée manuellement par chaque composant à quelque chose que les frameworks et les compilateurs peuvent appliquer automatiquement. Les équipes qui développent des applications React et Next.js en 2026 devraient adapter leur façon de penser en conséquence.

L’ancienne mentalité d’optimisation de React

const filteredUsers = useMemo(
  () => users.filter((user) => user.isActive),
  [users]
);

const handleSelect = useCallback(
  (id: string) => {
    selectUser(id);
  },
  [selectUser]
);return (
  <UserList
    users={filteredUsers}
    onSelect={handleSelect}
  />
);

L’intention était claire : lors du prochain rendu, éviter à nouveau de filtrer les utilisateurs, ne pas recréer la fonction de rappel et épargner les enfants mémorisés. Le coût caché réside dans la charge cognitive. Les développeurs doivent désormais gérer :

dependencies
references
closures
memoization
stale values
component boundaries

L’un des moyens les moins coûteux d’introduire des bugs est d’« optimiser » du code qui n’a jamais été gourmand en ressources.

Voici le compilateur React

Le compilateur propose un modèle différent. Au lieu de demander constamment à React de mémoriser une valeur, on écrit simplement du code de composant et on laisse le compilateur décider où la mémorisation est utile :

function ActiveUsersList({ users }) {
  const filteredUsers = users.filter(
    (user) => user.isActive
  );

  return (
    <ul>
      {filteredUsers.map((user) => (
        <li key={user.id}>
          {user.name}
        </li>
      ))}
    </ul>
  );
}

Filtres lisibles, pas de mémorisation manuelle, pas besoin de tableaux de dépendances à tenir à jour. Le compilateur analyse le composant et insère les optimisations appropriées. Il s’agit d’un changement philosophique, pas seulement esthétique.

Mais ne supprimez pas tous les useMemo

Une réaction excessive courante consiste à supprimer tous les useMemo, useCallback et memo dès le premier jour. C’est une approche trop radicale. Les points d’appel existants peuvent implémenter un stockage intentionnel ; la couverture du compilateur dépend de la version de React, des paramètres de configuration et de la structure du code. Une meilleure approche par défaut : ne pas optimiser manuellement en premier — mesurer d’abord. Laissez le compilateur gérer les cas sûrs. Effectuez un profilage avant d’ajouter des hooks personnalisés. Conservez la mémoisation explicite là où elle est intentionnelle et éprouvée. L’objectif est de réduire la complexité inutile, et non simplement de diminuer le nombre de hooks pour leur propre compte.

Les performances gagnent en importance

Prévenir la réexécution des éléments enfants n’est qu’un aspect parmi d’autres des coûts liés à React moderne. Un chemin de requête typique dans Next.js ressemble à ceci :

Browser
   ↓
React
   ↓
Next.js
   ↓
Server Components
   ↓
Data fetching
   ↓
Database
   ↓
External APIs

Une page qui charge en trois secondes n’a peut-être rien à voir avec la réconciliation React. Ce sont plutôt les requêtes lentes, les APIs gourmandes en ressources, les fichiers volumineux, les requêtes séquentielles, les images lourdes, les composants clients inutiles, un mécanisme de mise en cache insuffisant ou des tâches serveur coûteuses qui dominent. Un autre useMemo ne résoudra pas ces problèmes.

Les composants serveur changent la donne

Les composants serveur — en particulier via Next.js — déplacent le traitement hors du navigateur. La structure traditionnelle :

Traditional approach

Server
  ↓
Large JavaScript bundle
  ↓
Browser
  ↓
Render everything

Un flux plus orienté vers le serveur :

Server
 ├── Fetch data
 ├── Render server components
 └── Send necessary result
          ↓
       Browser
          ↓
   Interactive components

Avoir moins de JavaScript à télécharger et à exécuter est un avantage bien plus important que d’utiliser useCallback dans tous les composants.

La nouvelle question : « Est-ce que ceci doit être côté client ? »

Cette question est aujourd’hui l’une des plus importantes dans l’architecture React. Un tableau de bord entier n’a pas nécessairement besoin d’être un composant client. Une organisation possible serait :

Dashboard
├── Server
│   ├── Customer summary
│   ├── Revenue
│   ├── Recent jobs
│   └── Invoice totals
│
└── Client
    ├── Date picker
    ├── Filters
    └── Interactive chart

il conserve l’interactivité là où elle doit exister et laisse les données de résumé sur le serveur. La performance devient alors une décision liée à la responsabilité, et non seulement une question de choix technique.

Cessez d’optimiser ce que vous n’avez pas mesuré

L’intuition pousse encore les gens à :

users.map(...)

aller directement à la conclusion que « ceci nécessite une mémorisation ». La consultation de la carte peut prendre moins d’un milliseconde, tandis que cinq appels API successifs épuisent le budget de temps alloué. Mesurez d’abord à l’aide du React DevTools Profiler, des panneaux de performance du navigateur, de Lighthouse, des outils de Next.js, de Web Vitals, ainsi que des métriques du serveur ou de la base de données. Identifiez le goulot d’étranglement, puis corrigez-le.

La nouvelle liste de contrôle pour la performance

Préférez cet ordre plutôt que de commencer par :

useMemo
useCallback
React.memo

1. Réduire le JavaScript

Ce composant a-t-il vraiment besoin de s’exécuter dans le navigateur ?

2. Améliorer la récupération des données

Faites attention à :

waterfalls
duplicate requests
unnecessary requests
slow APIs

3. Mettre en cache de manière intelligente

Cessez de récupérer à nouveau des données qui changent à peine.

4. Optimisez les requêtes de base de données

React ne peut pas compenser un plan de requête médiocre.

5. Réduisez la taille du bundle

Toute dépendance superflue devient un fardeau supplémentaire.

6. Optimisez les images et les ressources

Les médias volumineux dominent encore souvent les temps de chargement.

7. Mesurez le rendu

Seul après que les véritables coûts de rendu soient apparus la mémorisation au niveau des composants devrait être envisagée.

Que devient useMemo et useCallback ?

Ils restent des outils, pas des paramètres par défaut. Ancien réflexe : « Je ferais mieux de mémoriser ceci. » Meilleur réflexe : « Ai-je des preuves que cela nécessite une mémorisation ? » Un coût réel justifie :

const value = useMemo(
  () => expensiveCalculation(data),
  [data]
);

La concaténation de chaînes ne le justifie que rarement :

const fullName = useMemo(
  () => `${firstName} ${lastName}`,
  [firstName, lastName]
);

Le TypeScript compte aussi

Le temps d’exécution n’est pas le seul critère de performance. La vitesse de refactage constitue elle aussi une mesure de l’efficacité du développeur. Les types forts rendent les gros projets React plus sûrs à modifier :

type Customer = {
  id: string;
  name: string;
  email: string;
  active: boolean;
};

Lorsqu’un composant ou les spécifications d’une API changent, le vérificateur de types indique immédiatement les problèmes potentiels — ce qui est particulièrement utile lorsque des assistants IA génèrent de grandes différences à intégrer dans le système.

L’IA transforme également le développement React

Déjà en 2026, il est courant de demander à un assistant d’identifier les rendus inutiles du côté client, de localiser les segments de page lents ou de refactorer sans altérer le comportement du logiciel. Ces suggestions ne constituent pas des mesures réelles. Sans analyse de performance, on peut optimiser à tort un problème qui n’existait même pas.

Le véritable avenir de la performance React

L’avenir n’est pas « ne jamais utiliser useMemo ». C’est un écosystème où les équipes consacrent moins d’énergie à de minuscules optimisations de rendu et plus à l’architecture. L’échelle des priorités est la suivante :

1. Architecture
       ↓
2. Server vs Client
       ↓
3. Data fetching
       ↓
4. Caching
       ↓
5. Bundle size
       ↓
6. Rendering
       ↓
7. Micro-optimizations

Remarquez où se trouve useMemo : tout en bas, là où il doit être.

La règle à suivre en 2026

Écrivez d’abord des composants React simples. Laissez le compilateur faire ce qu’il peut. Mesurez les performances réelles. Puis optimisez le véritable goulot d’étranglement. Évitez les composants qui ressemblent à :

useMemo(...)
useCallback(...)
memo(...)
useEffect(...)
useMemo(...)
useCallback(...)

uniquement parce que « React a besoin d’optimisations ». Le React moderne récompense une bonne architecture plutôt qu’un code ingénieux. La meilleure victoire n’est souvent pas de réduire de deux millisecondes le temps de rendu — c’est de se rendre compte que le composant n’avait jamais vraiment besoin d’être exécuté dans le navigateur.