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
- Navigateur requête
/products/42 - Serveur fetch données, exécute tree composants, génère HTML
- Serveur retourne HTML — navigateur affiche immédiatement
- Navigateur télécharge bundle JavaScript
- JS hydrate HTML — page devient interactive
SSR vs autres stratégies rendering
| Stratégie | HTML généré | Trade-off |
|---|---|---|
| SSR | Par requête, sur serveur | Frais + SEO ; besoin serveur |
| SSG (Static) | Une fois au build time | Delivery la plus rapide ; stale |
| CSR | Dans navigateur via JS | UX app-like ; premier paint lent |
| ISR | Build + on-demand | Performance static + fraîcheur dynamique |
| Edge SSR | Par requête au CDN edge | Latence 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
| Pros | Cons |
|---|---|
| Premier paint rapide (LCP) | TTFB plus lent que SSG |
| SEO-friendly out-of-box | Besoin serveur tournant |
| Contenu toujours frais | Coût hosting plus élevé |
| Personnalisation per-user | Complexité 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.
Outils LoadFocus connexes
Mettez ce concept en pratique avec LoadFocus — la plateforme même qui propulse tout ce que vous venez de lire.