CSR vs SSR vs SSG vs streaming : les compromis de performance ?

Question

IT Interview Practice · Accepted Answer

La stratégie de rendu décide *où et quand* le HTML est construit, ce qui pilote les métriques de chargement. Il n'y a pas de meilleur choix universel — adaptez-le au degré de dynamisme et de personnalisation du contenu.

## Les stratégies

```text
CSR      Le serveur envoie un HTML quasi vide + JS ──▶ le navigateur récupère les données ──▶ rend   (premier paint lent)
SSR      Le serveur rend le HTML complet par requête ──▶ le navigateur l'affiche ──▶ hydrate   (frais, coût TTFB)
SSG      HTML construit UNE FOIS au déploiement ──▶ servi depuis le CDN ──▶ hydrate               (le plus rapide, statique)
Stream   Le serveur flushe le HTML par morceaux dès qu'ils sont prêts ──▶ shell d'abord, données ensuite    (TTFB rapide + frais)
```

- **CSR (côté client)** — livrez un shell vide + JS ; le navigateur récupère les données et rend. Peu coûteux à héberger, mais LCP et SEO médiocres car le contenu attend le JS.
- **SSR (côté serveur)** — rend le HTML complet par requête. Premier paint rapide, favorable au SEO et toujours frais, mais ajoute du TTFB (travail serveur par requête) et nécessite encore l'hydratation.
- **SSG (statique)** — rend au moment du build, servi depuis un CDN. Meilleur TTFB/LCP, mais le contenu n'est aussi frais que votre dernier build ; l'**ISR** ajoute des rebuilds périodiques/à la demande.
- **Streaming SSR** — flushe immédiatement le shell HTML et streame les parties plus lentes (React Suspense / `renderToPipeableStream`) pour que les utilisateurs voient du contenu pendant le chargement des données.

## Choisir

| Contenu | Meilleure adéquation |
|---------|----------|
| Marketing, docs, blog | SSG (+ ISR) |
| Personnalisé, par requête | SSR / streaming |
| App très interactive derrière une authentification | CSR ou SSR + islands |

## Le coût de l'hydratation (piège commun)

SSR/SSG peignent vite mais la page n'est pas interactive tant que le JS n'a pas **hydraté** — un intervalle où l'INP souffre. L'hydratation partielle/progressive et les React Server Components existent pour livrer moins de JS client et réduire cet écart.

## Pourquoi c'est important

On attend des seniors qu'ils raisonnent sur ce compromis surface par surface, sans choisir dogmatiquement une seule option. L'intuition clé : un paint rapide (SSR/SSG) ne signifie pas une interactivité rapide — l'hydratation est la taxe cachée, et le streaming + les server components sont la réponse moderne pour obtenir les deux.

Contenu	Meilleure adéquation
Marketing, docs, blog	SSG (+ ISR)
Personnalisé, par requête	SSR / streaming
App très interactive derrière une authentification	CSR ou SSR + islands

Les stratégies

Choisir

Le coût de l'hydratation (piège commun)

Pourquoi c'est important

Questions connexes