SSR
Définition
Server-Side Rendering. Le HTML est généré côté serveur à chaque requête, puis envoyé prêt à l'emploi au navigateur. Améliore le SEO et le temps de premier affichage.
Comment ça marche
En SSR (Server-Side Rendering), chaque requête déclenche un rendu HTML côté serveur. Le serveur exécute le code de la page, interroge la base ou les API, assemble le HTML final et le renvoie au navigateur. Le visiteur reçoit donc une page déjà remplie avec son contenu, qui devient interactive ensuite grâce à l'hydratation JavaScript. C'est l'inverse d'une SPA, qui livre une coquille vide et assemble tout côté client. Sur Next.js, n'importe quel composant serveur ou fonction async dans une page se comporte en SSR par défaut.
À quoi ça sert
Le SSR brille sur les pages dont le contenu change à chaque requête ou selon l'utilisateur connecté : tableau de bord personnalisé, page produit avec stock à jour à la seconde, résultats de recherche, pages publiques avec données fraîches. Le SEO est préservé puisque les robots reçoivent le HTML final. Le LCP démarre rapidement parce que le navigateur n'attend pas le JavaScript pour afficher quelque chose. Et l'utilisateur n'a pas besoin de voir un spinner avant d'accéder au contenu, ce qui change l'expérience perçue.
Quand ne pas l'utiliser
Le SSR a un coût : chaque page est calculée à la volée, ce qui consomme du CPU serveur et augmente le TTFB sur les pages lourdes. Pour des contenus qui changent rarement (articles de blog, glossaire, pages marketing), on préfère le SSG ou l'ISR qui servent du HTML statique pré-calculé depuis un CDN. On évite aussi le SSR sur les pages avec des appels lents qu'on ne peut pas paralléliser : la page entière attend la requête la plus longue avant d'être renvoyée, ce qui ruine la performance perçue.
Les coûts à prévoir
Sur Vercel, chaque rendu SSR consomme une fonction serverless facturée à la durée d'exécution. Pour quelques milliers de visites par jour, c'est négligeable. Pour un site à fort trafic avec contenus très personnalisés, la facture peut grimper. On gagne à mutualiser : cache HTTP sur les pages qui peuvent l'être, edge runtime pour les calculs simples, ISR avec revalidate court pour les contenus presque dynamiques. La règle pratique : ne basculer en SSR que les pages qui en ont vraiment besoin, et garder tout le reste en SSG ou ISR.
Streaming et Suspense
Next.js avec l'App Router permet de streamer la réponse HTML : le serveur envoie la coquille de la page immédiatement, puis pousse les sections au fur et à mesure que leurs données arrivent. On l'orchestre avec React Suspense et des fichiers loading.tsx par segment. L'utilisateur voit la page se construire progressivement plutôt qu'attendre la requête la plus lente. C'est particulièrement utile sur les dashboards où plusieurs widgets indépendants chargent leurs propres données, sans qu'aucun ne bloque les autres.
Les pièges à éviter
Trois écueils reviennent. Le premier : multiplier les appels API séquentiels dans un même composant SSR, ce qui empile les latences. On parallélise avec Promise.all dès qu'on le peut. Le deuxième : oublier que le code SSR tourne sur le serveur, donc on ne touche ni à window ni à localStorage sous peine d'erreur runtime. Le troisième : ne pas mettre en cache les appels coûteux. Next.js propose unstable_cache et la directive cache: 'force-cache' sur fetch, qui économisent des millisecondes et des euros à chaque requête.