Depuis la montée en puissance de React 18 et de l’App Router dans Next.js, le débat entre Server Side Rendering (SSR) et React Server Components (RSC) ne cesse de gagner du terrain. Là où le SSR a longtemps été la norme pour combiner SEO, rapidité d’affichage et flexibilité, les RSC proposent une approche plus fine, plus performante et plus modulaire du rendu côté serveur.
Pour les entreprises et les équipes tech, il ne s’agit pas d’un simple choix technique, mais d’un vrai levier d’optimisation des performances, de réduction des coûts et de scalabilité. Voici ce qu’il faut vraiment comprendre.
Le SSR : une base solide, mais parfois trop lourde
Historiquement, le Server Side Rendering permet de pré-rendre les pages HTML sur le serveur avant de les envoyer au navigateur. Cela améliore significativement :
- le temps de chargement initial (TTFB),
- la visibilité SEO (pages lisibles immédiatement par les robots),
- la performance perçue pour l’utilisateur.
C’est une solution robuste pour les sites e-commerce, médias, ou vitrines. Par exemple, chez un client retail, nous avons mis en place un SSR optimisé pour les pages produits afin de garantir un affichage complet en moins de 1,2 seconde, y compris sur mobile.
Mais le problème du SSR, c’est l’hydration : React doit, après le rendu initial, rebrancher tous les composants interactifs côté client. Cela nécessite :
- le téléchargement de tout le bundle JS associé à la page,
- une phase de "réactivation" des composants,
- une montée en charge côté navigateur.
Sur une app comme un dashboard RH ou un outil de BI, cette hydration devient vite un goulet d’étranglement. Les performances chutent dès que le nombre de composants monte (tableaux, filtres, formulaires, graphiques…).
Les React Server Components : penser "streaming", modularité, et perf
Les React Server Components, introduits avec React 18 et pleinement intégrés dans Next.js depuis la version 13+ (App Router), proposent une approche hybride :
- certains composants sont exécutés exclusivement sur le serveur,
- jamais envoyés au client,
- sans JS dans le bundle final,
- et streamés au navigateur progressivement.
Prenons un exemple réel :
Une plateforme de suivi de projets logistiques avec une page "Vue globale des commandes". Les filtres sont interactifs (client), mais la table et les totaux sont des données 100% serveur. Résultat avec RSC : seuls les filtres sont hydratés, la table est générée côté serveur, streamée en HTML, et visible quasi-instantanément, sans coût JS. → Gains : -65 % de JS, +40 % de rapidité de premier affichage.
Ce découplage fin entre logique serveur et logique client permet :
- une réduction drastique du JavaScript exécuté côté client,
- une accélération du Time to Interactive (TTI),
- un meilleur contrôle sur la logique métier, centralisée côté serveur.
Comparaison concrète : ce qui change vraiment
Avec SSR, tout est hydraté : vous affichez un tableau avec 20 lignes, des composants React, des liens, des icônes ? Tout part dans le bundle client, même si 90 % de ces éléments n’ont aucune logique JS. Avec RSC, seules les interactions (bouton "Modifier", menu déroulant) sont hydratées. Le reste est du HTML statique généré à la volée. Résultat : une interface tout aussi dynamique, mais bien plus légère.
Autre avantage : le streaming. Contrairement au SSR classique qui renvoie un bloc HTML une fois que toute la page est prête, les RSC peuvent envoyer le rendu au fur et à mesure. Cela permet de montrer les blocs importants plus tôt, et de charger le reste sans bloquer l’affichage.
Exemple réel chez un client SaaS :
Une app de gestion d’abonnements renvoie en RSC le résumé de l’abonnement et le solde client immédiatement. Le graphe de consommation, plus lourd, est chargé en second plan. → Amélioration du Core Web Vitals : Largest Contentful Paint (LCP) réduit de 1,3 s.
Quand utiliser l’un ou l’autre dans vos projets ?
Le SSR reste pertinent si :
- Vous utilisez encore le Pages Router de Next.js (ou Remix).
- Vous construisez des pages simples, statiques, orientées SEO.
- Vous avez peu d’interactions client, ou des composants fortement liés.
Exemple : un site vitrine, un blog, une page produit e-commerce classique.
Les RSC brillent si :
- Vous utilisez Next.js App Router.
- Vous avez des besoins de performances client-side strictes.
- Vous travaillez sur des dashboards, outils métier, plateformes SaaS, avec beaucoup de données.
Exemple : app RH avec gestion d’absences, outil BI interne, interface de back-office multi-utilisateurs.
Et dans la majorité des cas, la réponse n’est ni SSR, ni RSC uniquement, mais une combinaison intelligente des deux, avec une architecture bien pensée pour séparer :
- le contenu statique et optimisé (RSC),
- les interactions riches (Client Components).
Bonnes pratiques & pièges à éviter
Quelques conseils pour intégrer les RSC efficacement dans vos projets :
- Structurez vos composants autour du principe "server-first" : un composant n’a besoin d’être client que s’il utilise du state ou des effets (useState, useEffect, etc.).
- Utilisez "use client" uniquement si nécessaire, pour éviter de basculer tout un arbre de composants côté client par erreur.
- Gardez vos composants serveurs purs : pas de hooks client, pas d’accès au DOM.
- Centralisez les accès aux données dans les RSC : ils permettent d’éviter des appels réseau inutiles côté client (ex : pas besoin de fetch dans useEffect pour charger des données si vous les avez déjà côté serveur).
- Utilisez loading="lazy" ou Suspense pour gérer le streaming efficacement et améliorer la perception utilisateur.
Et chez skiils ?
Nos consultants React et Next.js accompagnent les entreprises sur ces sujets : migration SSR → RSC, optimisation des performances, structuration des architectures frontend, accompagnement App Router...
Vous êtes en train de refondre votre plateforme ? D’optimiser vos KPIs Core Web Vitals ? D’accélérer le Time To First Byte ?
Discutons-en ! Chez skiils, on code vite, bien, et intelligemment.
Questions fréquentes :
Est-ce que les React Server Components remplacent complètement le SSR ?
Non. Les RSC ne remplacent pas le SSR mais le complètent. Le SSR reste utile pour générer une page complète côté serveur (notamment pour le SEO), tandis que les RSC permettent un rendu plus granulaire, avec une meilleure optimisation du JavaScript client. Les deux approches peuvent (et doivent) cohabiter dans une architecture moderne.
Est-ce que les RSC sont adaptés à tous les projets ?
Pas encore. Aujourd’hui, les RSC sont étroitement liés à l’App Router de Next.js (introduit en v13), donc si vous êtes sur une ancienne version ou sur un autre framework, vous n’en bénéficierez pas sans migration. Ils sont particulièrement adaptés aux projets complexes : apps métiers, dashboards, plateformes SaaS, applications à volumétrie importante, etc.
Puis-je utiliser des hooks comme useEffect dans un Server Component ?
Non. Les Server Components s’exécutent uniquement côté serveur, ils ne peuvent pas interagir avec le DOM ou les APIs du navigateur. useEffect, useState, useRef, etc., sont donc incompatibles avec les RSC. Si vous en avez besoin, votre composant doit être explicitement marqué comme "use client".
Est-ce que les RSC sont bons pour le SEO ?
Oui. Comme les RSC rendent du HTML côté serveur, le contenu est directement visible par les moteurs de recherche, tout comme avec le SSR. Il n’y a donc aucune perte de visibilité SEO, à condition que les composants contenant du contenu important soient bien rendus côté serveur.
Comment savoir si un composant doit être Server ou Client ?
Voici une règle simple :
- Si le composant n’a pas besoin d’état, d’effets, ni d’interaction utilisateur, il peut être Server.
- Si le composant gère un clic, un formulaire, une animation, ou du state dynamique, il doit être Client.
Une bonne pratique : développez vos composants comme Server par défaut, et passez-les en Client uniquement si nécessaire.
Peut-on migrer progressivement vers les RSC ?
Oui, et c’est même recommandé. Si vous êtes déjà sur Next.js, vous pouvez :
- Activer l’App Router page par page.
- Identifier les composants statiques à passer en Server Components.
- Isoler progressivement la logique interactive dans des "use client" components.
Cela permet une migration douce, sans refonte brutale.
Quels outils ou librairies sont encore incompatibles avec les RSC ?
Certaines librairies frontend pensées exclusivement pour le client peuvent poser problème si utilisées dans des Server Components :
- des libs UI comme react-toastify ou framer-motion,
- des librairies DOM-heavy (ex : chart.js, mapbox-gl),
- ou tout ce qui utilise les hooks React classiques côté client.
Pas de panique : il suffit de les encapsuler dans des composants marqués "use client".
