React Server Components en 2026 : pourquoi c’est devenu le standard
En 2026, les React Server Components (RSC) ne sont plus une expérimentation réservée aux équipes avancées. Ils sont le défaut de tout nouveau projet React sérieux, popularisés par Next.js et son App Router. Mais beaucoup de développeurs les adoptent sans vraiment comprendre ce qui se passe sous le capot — et c’est là que les performances se dégradent.
Ce que les RSC changent vraiment
L’idée fondamentale est simple : certains composants React s’exécutent uniquement sur le serveur et ne génèrent aucun JavaScript côté client. Ils accèdent directement aux bases de données, APIs et systèmes de fichiers sans exposer de logique sensible dans le navigateur. Résultat : le bundle JavaScript envoyé au client est drastiquement réduit.
Si vous utilisez une librairie lourde comme markdown-it dans un composant serveur, cette librairie reste sur le serveur. L’utilisateur ne télécharge jamais son code. Cela améliore directement le First Contentful Paint (FCP) et le Time to Interactive — deux métriques clés pour le SEO Google en 2026.
L’architecture en pratique
Dans Next.js avec l’App Router, tous les composants sont des Server Components par défaut. Vous devez explicitement ajouter la directive use client pour basculer côté client. La règle pratique : poussez use client le plus loin possible dans l’arbre de composants. Si seul un bouton doit être interactif sur une page, seul ce bouton devient un Client Component.
Les 3 erreurs les plus courantes
1. Bloquer le streaming avec des await au niveau racine. Si vous faites await fetchSlowData() tout en haut d’un Server Component, rien n’est envoyé au navigateur tant que cette donnée n’est pas disponible. Utilisez des boundary Suspense avec des squelettes pour streamer le shell immédiatement pendant que les données chargent.
2. Sur-utiliser « use client ». Beaucoup de développeurs rajoutent la directive dès qu’ils ont un doute. Résultat : tout l’arbre de composants finit côté client, annulant complètement les bénéfices des RSC. Moins de 20 % de vos composants devraient être des Client Components sur un projet typique.
3. Faire des requêtes séquentielles au lieu de parallèles. Utilisez des Server Components frères qui s’exécutent en parallèle, ou Promise.all pour les requêtes dans un même composant.
Partial Prerendering : la prochaine étape
Next.js pousse actuellement le Partial Prerendering (PPR) : un shell statique servi instantanément depuis le cache edge, et des portions dynamiques qui se chargent en streaming. Des pages qui s’affichent en moins de 100ms pour la structure de base, puis se peuplent progressivement. C’est l’expérience que les utilisateurs attendent en 2026.
WordPress ou Next.js : comment choisir ?
Pour un site vitrine ou un blog, WordPress bien optimisé reste imbattable en rapport effort/résultat. Pour une application web avec beaucoup d’interactivité, Next.js + RSC est le bon choix. J’oriente vers WordPress quand le contenu est au cœur du projet, et vers Next.js quand les besoins applicatifs l’emportent sur les besoins éditoriaux.