Next.js App Router : le rendu serveur réinventé

Avec l'App Router, Next.js ne propose pas une simple évolution mais un nouveau modèle mental. Les composants s'exécutent par défaut sur le serveur, le rendu est diffusé progressivement, et la frontière entre serveur et client devient une décision d'architecture explicite. Pour en tirer parti, il faut comprendre ce qui se passe réellement à chaque requête.

Server Components : moins de JavaScript côté client

Dans l'App Router, un composant est un Server Component par défaut. Il s'exécute sur le serveur, peut accéder directement à la base de données ou au système de fichiers, et n'envoie au navigateur que le HTML résultant — sans alourdir le bundle JavaScript.

On ne bascule en Client Component (avec la directive use client) que lorsqu'on a besoin d'interactivité : état local, gestionnaires d'événements, accès aux API du navigateur. Cette distinction pousse à garder le code interactif petit et ciblé.

Composer serveur et client

Un Server Component peut rendre un Client Component, et lui passer des données déjà chargées. Ce motif — charger côté serveur, n'hydrater que ce qui doit l'être — réduit drastiquement la quantité de code expédiée au navigateur.

Le streaming et Suspense

Plutôt que d'attendre que toute la page soit prête, Next.js peut diffuser le HTML par morceaux. Les parties rapides s'affichent immédiatement, tandis que les sections plus lentes apparaissent dès qu'elles sont disponibles, encadrées par des limites Suspense affichant un état de chargement.

Le streaming transforme une attente unique et bloquante en une expérience progressive : l'utilisateur voit du contenu utile bien plus tôt.

Le rendu : statique, dynamique, à la demande

Chaque route choisit son mode de rendu. Une page peut être :

• Statique : générée au build, servie instantanément depuis un cache.
• Dynamique : rendue à chaque requête, indispensable dès qu'on lit des cookies ou des données qui changent.
• Revalidée : régénérée périodiquement, pour combiner fraîcheur et performance.

Comprendre ce qui rend une route dynamique — l'accès aux en-têtes, aux cookies, ou une demande explicite — évite les surprises au déploiement.

La mise en cache, à manier avec discernement

Next.js met en cache à plusieurs niveaux : les requêtes de données, le rendu des routes, le routeur côté client. C'est puissant, mais cela demande de la rigueur. Lorsqu'une donnée doit toujours être fraîche, il faut l'indiquer explicitement, sous peine d'afficher du contenu périmé.

Server Actions : muter sans API dédiée

Les Server Actions permettent d'exécuter du code serveur en réponse à une soumission de formulaire, sans écrire d'endpoint séparé. La logique de mutation vit au plus près du composant, tout en s'exécutant en sécurité côté serveur. C'est un changement notable dans la manière de structurer les interactions.

Conclusion

L'App Router demande de réapprendre quelques réflexes, mais la récompense est réelle : des applications plus légères, un rendu progressif et une frontière serveur/client maîtrisée. La bonne approche consiste à raisonner « serveur par défaut, client quand c'est nécessaire » — et à toujours savoir, pour chaque route, ce qui est mis en cache et ce qui ne l'est pas.