React Server Components
L'essentiel
Avant les Server Components, tout composant React finissait dans le bundle JavaScript téléchargé par le navigateur. Un composant qui affiche une liste de produits depuis une DB chargeait côté serveur, mais son code JavaScript restait quand même dans le bundle client — inutilement. Les Server Components coupent ce lien. Ils s'exécutent côté serveur, génèrent du HTML, et leur code ne rejoint jamais le navigateur. La métaphore : imaginez un chef cuisinier (serveur) qui prépare le plat en cuisine et envoie uniquement l'assiette finie en salle. Avant : le serveur envoyait aussi la recette complète, les ustensiles, et les ingrédients bruts — au cas où. Maintenant, juste l'assiette. Le navigateur reçoit moins de JavaScript à télécharger, parser, exécuter — et la page apparaît plus vite.
Détails Techniques
Modèle de composants React exécutés exclusivement dans l'environnement serveur (Node.js, Edge Runtime), introduit dans React 18 et rendu opérationnel en production via Next.js 13 App Router (décembre 2022). Caractéristiques techniques : (1) Zéro JavaScript envoyé au client — uniquement du HTML sérialisé + React Server Component Payload (RSC Payload, format binaire encodant l'arbre de composants). (2) Composants async natifs — await directement dans le corps du composant pour fetch DB (Drizzle, Prisma), appels APIs internes, lecture fichiers. (3) Accès aux ressources serveur exclusives : variables d'environnement secrètes, filesystem, connexions DB directes. (4) Incompatibilité hooks React (useState, useEffect, useCallback) — réservés aux Client Components. Client Components déclarés par directive 'use client' en tête de fichier : hydratés côté client, supportent l'interactivité et les hooks. Streaming : les Server Components wrappés dans <Suspense fallback={...}> streament leur contenu via HTTP chunked transfer encoding — le navigateur affiche le fallback immédiatement puis substitue le contenu réel. RSC Payload : format JSON-like sérialisé envoyé au client permettant à React de réconcilier l'arbre sans perte d'état Client Components.
#Définition React Server Components
Modèle de composants React exécutés exclusivement dans l'environnement serveur (Node.js, Edge Runtime), introduit dans React 18 et rendu opérationnel en production via Next.js 13 App Router (décembre 2022). Caractéristiques techniques : (1) Zéro JavaScript envoyé au client — uniquement du HTML sérialisé + React Server Component Payload (RSC Payload, format binaire encodant l'arbre de composants). Pour approfondir, consultez la page service Development Next.js Nehos.
Pour être précis, (2) Composants async natifs — await directement dans le corps du composant pour fetch DB (Drizzle, Prisma), appels APIs internes, lecture fichiers. (3) Accès aux ressources serveur exclusives : variables d'environnement secrètes, filesystem, connexions DB directes. (4) Incompatibilité hooks React (useState, useEffect, useCallback) — réservés aux Client Components. Client Components déclarés par directive 'use client' en tête de fichier : hydratés côté client, supportent l'interactivité et les hooks. Streaming : les Server Components wrappés dans <Suspense fallback={..}> streament leur contenu via HTTP chunked transfer encoding — le navigateur affiche le fallback immédiatement puis substitue le contenu réel. RSC Payload : format JSON-like sérialisé envoyé au client permettant à React de réconcilier l'arbre sans perte d'état Client Components.
Maîtriser React Server Components permet aux équipes techniques et métier de parler le même langage — et d'arbitrer plus vite.
#React Server Components expliqué simplement
Avant les Server Components, tout composant React finissait dans le bundle JavaScript téléchargé par le navigateur. Un composant qui affiche une liste de produits depuis une DB chargeait côté serveur, mais son code JavaScript restait quand même dans le bundle client — inutilement. Les Server Components coupent ce lien. Ils s'exécutent côté serveur, génèrent du HTML, et leur code ne rejoint jamais le navigateur. La métaphore : imaginez un chef cuisinier (serveur) qui prépare le plat en cuisine et envoie uniquement l'assiette finie en salle. Avant : le serveur envoyait aussi la recette complète, les ustensiles, et les ingrédients bruts — au cas où. Maintenant, juste l'assiette. Le navigateur reçoit moins de JavaScript à télécharger, parser, exécuter — et la page apparaît plus vite.
Imaginez que vous dirigez une PME ou une scale-up. La différence entre théorie et terrain ? Les chiffres. Et les chiffres, on les a.
#Cas d'usage concrets
Refonte plateforme SaaS B2B (dashboard analytique React SPA → Next.js App Router RSC) — Migration dashboard CRA vers Next.js 16 App Router. 80 % des composants migrés en Server Components (tableaux, graphiques statiques, listes filtrées). Bundle JS client réduit de 1,8 MB à 680 KB (-62 %). INP passé de 340 ms à 112 ms. Time-to-interactive -2,1 s en moyenne sur connexion 4G.
Site e-commerce DNVB (Shopify Liquid → Next.js 16 + Shopify Storefront API) — Pages produit en Server Components avec fetch direct Shopify GraphQL. Panier et wishlist en Client Components. LCP mobile : 3,9 s → 1,3 s. INP mobile : 510 ms → 98 ms. Librairies markdown et formatters de prix retirés du bundle client — 340 KB économisés.
Corporate ETI industrie (WordPress → Next.js 16 + Payload Local API) — Server Components avec appels payload.find() direct depuis le Server Component — sans couche API HTTP. Streaming Suspense sur les sections 'actualités' et 'témoignages clients'. TTFB réduit de 820 ms à 180 ms. LCP -44 %. Score Lighthouse desktop : 98/100.
#React Server Components chez Nehos Groupe
Nehos Groupe a fait de cette approche un standard projet. Sur les 3 derniers projets impliquant React Server Components, on a documenté les résultats avec des KPIs précis. Notre service Development Next.js Nehos couvre ce périmètre de A à Z.
Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. Les résultats mesurés sur nos clients : 44 % est un ordre de grandeur courant. On livre, on mesure, on itère. Pas de slides sans livrable. Voir aussi : refonte headless Next.js App Router.
#Termes associés
Ce concept ne vit pas isolé.
- Next.js
- App Router Next.js
- Partial Prerendering (PPR)
- ISR (Incremental Static Regeneration)
- TypeScript
- INP (Interaction to Next Paint)
- Headless Commerce
Chaque terme est défini dans notre glossaire avec la même approche : définition technique, vulgarisation, cas concrets et méthode Nehos.
Applications Concrètes
"Migration dashboard CRA vers Next.js 16 App Router. 80 % des composants migrés en Server Components (tableaux, graphiques statiques, listes filtrées). Bundle JS client réduit de 1,8 MB à 680 KB (-62 %). INP passé de 340 ms à 112 ms. Time-to-interactive -2,1 s en moyenne sur connexion 4G."
"Pages produit en Server Components avec fetch direct Shopify GraphQL. Panier et wishlist en Client Components. LCP mobile : 3,9 s → 1,3 s. INP mobile : 510 ms → 98 ms. Librairies markdown et formatters de prix retirés du bundle client — 340 KB économisés."
"Server Components avec appels payload.find() direct depuis le Server Component — sans couche API HTTP. Streaming Suspense sur les sections 'actualités' et 'témoignages clients'. TTFB réduit de 820 ms à 180 ms. LCP -44 %. Score Lighthouse desktop : 98/100."