Pendant une décennie, le front-end a tout misé sur le client : des bundles JavaScript toujours plus lourds, exécutés dans le navigateur de l’utilisateur. Les React Server Components (RSC) inversent la logique — une partie de l’arbre est rendue sur le serveur et n’embarque aucun JavaScript côté client.
Ce qui change concrètement
Le premier gain est le poids envoyé au navigateur : un composant serveur ne contribue pas au bundle. Sur des pages riches en contenu mais pauvres en interactivité — articles, fiches produit, tableaux de bord en lecture — la différence se mesure en centaines de kilooctets et en secondes de chargement.
Le second est le data-fetching : la donnée est récupérée au plus près du composant, sur le serveur, sans aller-retour supplémentaire ni cascade de requêtes. On colocalise le rendu et l’accès aux données, ce qui simplifie beaucoup de code d’orchestration.
Les pièges à connaître
La frontière client/serveur devient une décision d’architecture. Un composant qui a besoin d’état, d’effets ou d’événements doit être marqué explicitement comme composant client, et tout ce qu’il importe bascule avec lui. Mal maîtrisée, cette frontière annule les gains attendus.
Reste la question de la maturité de l’écosystème : librairies compatibles, mise en cache, streaming, débogage. RSC est prêt pour de nombreux cas, mais impose une discipline nouvelle. On détaille les patterns qui tiennent en production et ceux qui restent fragiles.