Rendu côté serveur (SSR) : définition, avantages, usages

Qu'est-ce que le rendu côté serveur (SSR) ?

Dans le rendu côté serveur (SSR, Server-Side Rendering), le serveur construit le HTML d'une page à l'arrivée de la requête et l'envoie au navigateur prêt à être affiché. Le navigateur peut afficher le contenu immédiatement ; JavaScript se charge ensuite et rend la page interactive. Avec le rendu côté client (CSR), le serveur envoie au contraire une coquille presque vide et le navigateur construit la page avec JavaScript.

Des frameworks comme Next.js, Nuxt, SvelteKit et Remix prennent en charge le SSR, et la plupart permettent de choisir le mode de rendu route par route. Le SSR convient aux pages dont le contenu dépend de la requête : résultats de recherche, vues de l'utilisateur connecté, stocks en direct, pages qui doivent être indexables.

Comment fonctionne le SSR

1. Le navigateur demande /products/42.
2. Le serveur récupère les données, exécute l'arbre de composants et génère le HTML.
3. Le serveur envoie le HTML et le navigateur l'affiche aussitôt.
4. Le navigateur télécharge le bundle JavaScript.
5. Le script hydrate la page : il rattache les gestionnaires d'événements au HTML existant et la page devient interactive.

Entre les étapes 3 et 5, la page est visible mais peut ne pas encore répondre aux clics.

SSR et autres stratégies de rendu

Le SSR peut aussi s'exécuter à la périphérie du réseau (edge), près de l'utilisateur, ce qui réduit la latence réseau mais limite le code exécutable à cet endroit.

Un exemple minimal

Sans framework, le SSR est une fonction qui renvoie une chaîne de HTML. Cette route Express rend un composant React côté serveur :

import { renderToString } from 'react-dom/server';
import App from './App';

app.get('/', (req, res) => {
  const html = renderToString(<App />);
  res.send(`<!DOCTYPE html>
<html>
  <body>
    <div id="root">${html}</div>
    <script src="/client.js"></script>
  </body>
</html>`);
});

Le navigateur charge ensuite client.js, qui appelle hydrateRoot pour se rattacher au balisage. Les frameworks automatisent ce câblage, ainsi que le routage, le chargement des données et le découpage du code.

Quand le SSR convient

• Pages personnalisées. Le HTML dépend de la personne qui le demande.
• Données qui changent souvent. Prix, stocks, actualités.
• Pages indexables à données dynamiques. Fiches produit et recherches que les robots doivent lire en HTML.
• Contenu propre à une région. Devise, langue ou mentions légales selon la requête.

Quand une autre approche est préférable

• Pages marketing et documentation. Le SSG servi depuis un CDN est plus rapide et moins cher.
• Tableaux de bord connectés sans besoin de SEO. Le CSR est plus simple à héberger.
• Sites mixtes. Pages d'atterrissage statiques, SSR pour le catalogue, CSR pour l'application.

Le coût de l'hydratation

L'hydratation est le prix du SSR. Le navigateur télécharge et réexécute les mêmes composants pour rattacher le comportement. Selon le guide de web.dev sur le rendu web, elle peut dégrader le Total Blocking Time et l'Interaction to Next Paint même si elle améliore le First Contentful Paint : la page semble prête avant de répondre. Le SSR en streaming (envoi du HTML par morceaux), les React Server Components et les architectures en îlots comme celle d'Astro cherchent à réduire la quantité de JavaScript à exécuter.

Erreurs courantes avec le SSR

• Utiliser des API du navigateur côté serveur. window is not defined est le plantage classique.
• Sorties différentes entre serveur et client. Un horodatage ou un identifiant aléatoire provoque un avertissement ou un échec de l'hydratation.
• Récupération de données lente pendant le rendu. Le navigateur ne reçoit rien tant que la requête la plus lente n'est pas terminée.
• Pas de cache. Chaque requête recalcule la page. Mettez en cache ce qui n'est pas personnel et marquez les pages personnelles Cache-Control: private.
• Fuites de mémoire. Un serveur de rendu tourne des jours et une petite fuite par requête finit par peser.
• Travail lourd dans le middleware d'authentification. Il retarde chaque réponse.

SSR et tests de performance

Le SSR déplace le travail de rendu de l'appareil de chaque visiteur vers votre serveur : c'est donc votre capacité qui fixe la vitesse de la page. Le Time to First Byte est le chiffre à surveiller : web.dev juge bon un TTFB de 0,8 seconde ou moins et mauvais au-delà de 1,8 seconde, et note qu'une page rendue côté serveur peut avoir un TTFB plus élevé mais de meilleurs First Contentful Paint et Largest Contentful Paint qu'une page rendue côté client.

Une seule requête n'apprend pas grand-chose. Lancez un test de charge sur vos routes SSR principales avec un trafic réaliste et observez l'évolution du TTFB et du taux d'erreurs quand les utilisateurs simultanés augmentent. Ensuite, suivez les Core Web Vitals dans le temps avec la surveillance de la vitesse des pages. Pour le cas des applications monopages, voir comment tester la charge d'une application monopage, et pour éviter les régressions, les budgets de performance pour applications web.

Questions fréquentes : rendu côté serveur

Le SSR est-il meilleur que le SSG ?

Aucun n'est meilleur dans l'absolu. Le SSG convient au contenu qui change peu, car le HTML est construit une fois et servi depuis un CDN. Le SSR convient au contenu qui change selon la requête ou l'utilisateur. Beaucoup de sites utilisent les deux.

Le SSR règle-t-il le SEO automatiquement ?

Il garantit que les robots reçoivent un HTML complet, mais il faut toujours de bons titres, des balises meta, des données structurées, un maillage interne et des Core Web Vitals corrects.

Le SSR est-il plus lent que le CSR ?

Cela dépend de la métrique. Le serveur a besoin de temps pour construire la page, donc le TTFB est généralement plus élevé. Le premier affichage arrive en général plus tôt, car le HTML arrive prêt à être affiché. L'interactivité dépend de la quantité de JavaScript à hydrater.

Puis-je combiner SSR et CSR dans une même application ?

Oui. Next.js, Nuxt et SvelteKit permettent de choisir le mode de rendu par route : les pages publiques utilisent le SSR et un tableau de bord connecté peut rester côté client.

Comment réduire le TTFB d'un site en SSR ?

Mettez en cache les pages et données non personnelles, accélérez ou parallélisez les requêtes derrière le rendu, envoyez la réponse en streaming et envisagez un rendu à la périphérie. Mesurez de nouveau sous charge après chaque changement.

Le SSR, est-ce la même chose que les React Server Components ?

Non. Le SSR produit du HTML côté serveur au premier chargement, et le code complet des composants est quand même envoyé au navigateur pour l'hydratation. Les Server Components s'exécutent uniquement côté serveur et n'envoient aucun code de composant pour leur partie de l'arbre. On les combine souvent.