Next.js 16 et React Server Components : Le Modèle Mental Indispensable

1. Exécution Serveur sans impact sur le Bundle Client

Les React Server Components (RSC) changent ce que signifie « composant » dans une application Next.js 16. Un composant serveur s’exécute exclusivement côté serveur, une fois par requête, et n’envoie jamais son propre code au navigateur. Le résultat n’est d’ailleurs pas du HTML au sens classique : c’est un arbre React sérialisé (le payload RSC) que le runtime client réconcilie dans le DOM. Concrètement, chaque import utilisé par un composant serveur — une bibliothèque de formatage de dates, un parseur markdown, un client de base de données — reste sur le serveur. Il ne touche jamais le bundle client, n’est jamais parsé par V8 dans le navigateur, et ne pèse pas dans votre budget JavaScript.

En pratique, cela change la façon dont vous évaluez le poids de vos dépendances. Avant RSC, ajouter une bibliothèque lourde — un colorateur syntaxique, un générateur de PDF — à un composant de page était une décision de taille de bundle à peser soigneusement, souvent via des imports dynamiques pour différer le coût. Avec les composants serveur, ce calcul disparaît presque entièrement pour tout ce qui ne nécessite pas d’interactivité : vous importez directement, l’exécution a lieu côté serveur au moment du rendu, et le client ne reçoit que le HTML et les props résultants. Un blog qui convertit du Markdown en HTML peut ainsi importer un pipeline complet d’analyse markdown sans aucun coût côté client.

L’App Router de Next.js 16 fait de chaque fichier sous `app/` un composant serveur par défaut, sauf s’il utilise la directive `use client` en tête de fichier. Cette posture « serveur par défaut » est délibérée : elle vous oblige à justifier l’exécution côté client plutôt que l’exécution côté serveur, à l’inverse de ce qui prévalait avec le répertoire pages ou la plupart des frameworks SPA. L’effet pratique sur des applications réelles est substantiel — les équipes qui migrent des dashboards ou des back-offices voient souvent leur poids JavaScript client divisé par deux ou plus, simplement parce que la logique de récupération et de formatage de données qui partait auparavant vers le navigateur ne quitte plus le serveur.

2. Streaming SSR avec React Suspense

Le rendu côté serveur traditionnel est tout ou rien : le serveur ne peut envoyer le moindre octet de HTML tant que toutes les dépendances de données de la page ne sont pas résolues. Si une requête prend 2 secondes, la page entière attend 2 secondes, même si le reste du contenu était prêt en 50ms. Le streaming SSR, construit sur React Suspense, brise cette dépendance. Le serveur envoie immédiatement le squelette de la page et tout contenu déjà prêt, puis diffuse des fragments HTML supplémentaires — enveloppés dans des balises `<script>` inline qui les repositionnent — au fur et à mesure que les données lentes arrivent, sans nouvelle requête côté client ni aller-retour supplémentaire.