Server-Side Rendering (SSR) : Définition, Pros, Quand Utiliser

Le SSR génère HTML sur le serveur par requête — premier paint rapide, SEO-friendly, dynamique. Utilisé par Next.js, Nuxt, Remix, SvelteKit.

Qu'est-ce que Server-Side Rendering (SSR) ?

Le Server-Side Rendering (SSR) est une stratégie de rendering web où le HTML est généré sur le serveur pour chaque requête et envoyé au navigateur prêt à être affiché. Le navigateur montre le contenu immédiatement ; JavaScript "hydrate" ensuite la page pour la rendre interactive. SSR contraste avec Client-Side Rendering (CSR).

SSR est le mode rendering par défaut pour les frameworks modernes comme Next.js, Nuxt, SvelteKit et Remix.

Comment SSR fonctionne

  1. Navigateur requête /products/42
  2. Serveur fetch données, exécute tree composants, génère HTML
  3. Serveur retourne HTML — navigateur affiche immédiatement
  4. Navigateur télécharge bundle JavaScript
  5. JS hydrate HTML — page devient interactive

SSR vs autres stratégies rendering

StratégieHTML généréTrade-off
SSRPar requête, sur serveurFrais + SEO ; besoin serveur
SSG (Static)Une fois au build timeDelivery la plus rapide ; stale
CSRDans navigateur via JSUX app-like ; premier paint lent
ISRBuild + on-demandPerformance static + fraîcheur dynamique
Edge SSRPar requête au CDN edgeLatence basse globale

Quand SSR est le bon choix

  • Personnalisation per-user.
  • Contenu changeant fréquemment.
  • SEO-critique avec données dynamiques.
  • Contenu geo-localisé.
  • A/B testing au niveau page.
  • Logique auth/session lourde.

Quand NE PAS utiliser SSR

  • Pages marketing statiques.
  • Dashboards logged-in sans besoin SEO.
  • Apps très interactives avec home page simple.

Pros et cons SSR

ProsCons
Premier paint rapide (LCP)TTFB plus lent que SSG
SEO-friendly out-of-boxBesoin serveur tournant
Contenu toujours fraisCoût hosting plus élevé
Personnalisation per-userComplexité cache

Hydration : le catch SSR

Après SSR, le client doit "hydrater". L'hydration est coûteuse.

SSR avec Next.js (App Router)

export default async function ProductPage({ params }) {
  const product = await fetchProduct(params.id);
  return <div><h1>{product.name}</h1></div>;
}

SSR avec Express + React

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

app.get('/', (req, res) => {
  const html = renderToString(<App />);
  res.send(`<div id="root">${html}</div>`);
});

Best practices SSR

  • Cacher sagement.
  • Utiliser streaming SSR.
  • Data fetching server-only.
  • Cacher queries DB server-side.
  • Set cache headers thoughtfully.
  • Watcher coût hydration.
  • Gérer erreurs au serveur.
  • Monitor TTFB + LCP.

Pièges SSR courants

  • Références window/document dans code server.
  • Mismatch server-client.
  • Queries DB lentes bloquant response.
  • Oublier de cacher.
  • Bundle bloat.
  • Memory leaks.
  • Auth dans middleware.

FAQ : Server-Side Rendering

SSR ou SSG : lequel est meilleur ?

Dépend de la fraîcheur du contenu.

SSR fixe-t-il le SEO automatiquement ?

Les crawlers obtiennent HTML, mais vous avez encore besoin de title/meta/structured data.

SSR est-il plus lent que CSR ?

Pour TTFB : SSR plus lent. Pour premier paint : SSR beaucoup plus rapide.

Qu'en est-il de TTFB avec SSR ?

Plus haut que SSG. Mitiger avec edge SSR.

Puis-je mixer SSR et CSR ?

Oui.

Qu'est-ce que React Server Components ?

Composants tournent seulement sur serveur.

SSR est-il cher à hoster ?

Plus que SSG. Serverless moderne le rend bon marché à trafic bas.

Load-testez les apps SSR avec LoadFocus

SSR shifte le travail au serveur — le load testing est essentiel. Inscrivez-vous sur loadfocus.com/signup.

Quelle est la vitesse de votre site web?

Augmentez sa vitesse et son référencement naturel de manière transparente avec notre Test de Vitesse gratuit.

Test gratuit de vitesse du site Web

Analyser la vitesse de chargement de votre site Web et améliorer ses performances avec notre outil gratuit de vérification de la vitesse de la page.

×