SSR vs. CSR vs. SSG : comment fonctionne le rendu web

SSR vs. CSR vs. SSG est une comparaison des stratégies de rendu selon où et quand le HTML est généré : au build, sur le serveur ou dans le navigateur. Ce seul axe — où et quand — détermine le SEO, la performance, la fraîcheur des données et le coût ; tout le reste en découle. Et la précision de développeur backend que les guides frontend enterrent : le rendu est une affaire de frontend ; les données sont une affaire de backend. Les trois stratégies appellent la même API ; elles ne diffèrent que par le moment de l’appel.

Points clés

Mêmes données, trois moments d’appel

// JavaScript — the SAME API call, consumed three ways.
// Rendering is a FRONTEND choice; the data is a BACKEND concern.
async function getPosts() {
  const q = new Parse.Query('Post').equalTo('published', true).limit(20);
  return q.find(); // one backend endpoint — the ONLY thing that changes is WHEN
}

// SSG — called at BUILD time; data baked into static HTML, served from a CDN.
// SSR — called PER REQUEST on the server; fresh HTML sent to the browser.
// CSR — called FROM THE BROWSER after load; the client builds the DOM.
// You don't change the backend to switch rendering — only when/where you fetch.

// Flutter / Dart — Back4app Flutter SDK
// Whatever the rendering strategy, the data comes from one backend API.
Future<List<ParseObject>> getPosts() async {
  final q = QueryBuilder<ParseObject>(ParseObject('Post'))
    ..whereEqualTo('published', true)
    ..setLimit(20);
  return (await q.query()).results?.cast<ParseObject>() ?? [];
}
// SSG fetches at build, SSR fetches per request, CSR fetches in the client —
// the endpoint is identical; only the timing and location differ.

// Swift — Back4app Swift SDK
// Whatever the rendering strategy, the data comes from one backend API.
func getPosts() async throws -> [Post] {
    try await Post.query("published" == true).limit(20).find()
}
// SSG fetches at build, SSR fetches per request, CSR fetches in the client —
// the endpoint is identical; only the timing and location differ.

// Kotlin — Back4app Android SDK
// Whatever the rendering strategy, the data comes from one backend API.
fun getPosts(): List<ParseObject> {
    val q = ParseQuery.getQuery<ParseObject>("Post")
    q.whereEqualTo("published", true)
    q.limit = 20
    return q.find()
}
// SSG fetches at build, SSR fetches per request, CSR fetches in the client —
// the endpoint is identical; only the timing and location differ.

Un seul getPosts(), un seul endpoint backend. Le SSG l’appelle au moment du build et fige le résultat dans du HTML statique ; le SSR l’appelle à chaque requête, sur le serveur, et envoie un HTML frais ; le CSR l’appelle depuis le navigateur après le chargement. Vous ne modifiez jamais le backend pour changer de rendu — seulement le moment et l’endroit où vous récupérez les données. C’est ce constat qui transforme une comparaison à trois voies déroutante en une seule décision.

SSR vs. CSR vs. SSG, côte à côte

Les métriques, en toute honnêteté

Les compromis qu’aucune comparaison n’énonce clairement. Le SSG remporte le time-to-first-byte haut la main et de façon constante — un CDN renvoie un fichier pré-généré. Le SSR augmente le TTFB (le serveur doit rendre avant de répondre) mais bat encore le CSR sur le premier affichage, et il livre des données fraîches. Le CSR a un TTFB rapide (le squelette est minuscule) mais un premier affichage et un time-to-interactive lents, puisque rien n’est visible tant que le bundle ne s’est pas exécuté. Et celui que tout le monde survole : le SSR et le SSG ne règlent pas le TTI. Tous deux envoient un HTML qui semble prêt, puis l’hydratation (hydration) — télécharger, analyser et exécuter le JavaScript pour attacher l’interactivité — s’exécute quand même. C’est l’écart « semble prêt mais ne répond pas au clic », et c’est pourquoi la facture du JS livré est le véritable impôt sur l’interactivité, ce qui motive les islands, l’hydratation partielle et les server components qui en livrent moins.

Le spectre en 2026 : ISR, streaming, RSC

Le trio est une simplification pédagogique ; la production est un spectre. L’ISR (incremental static regeneration) sert des pages statiques mais les régénère à intervalle régulier ou à la demande — la vitesse du SSG avec une fraîcheur périodique, au prix d’un contenu parfois périmé. Le streaming SSR envoie le HTML par morceaux au fil de sa génération, si bien que le squelette s’affiche en quelques dizaines de millisecondes pendant que le contenu lent arrive derrière. Les server components s’exécutent uniquement sur le serveur, livrent zéro JavaScript pour les parties non interactives et peuvent lire les données directement — la réponse la plus récente au coût de l’hydratation. Aucun ne modifie le contrat avec le backend ; ils offrent un contrôle plus fin sur le moment où le HTML se forme et la quantité de JS qui suit, c’est-à-dire le même axe autour duquel tourne tout cet article.

Par route, pas par app

Le changement de perspective qui dissout la plupart des débats « lequel choisir ? » : vous ne choisissez pas une stratégie pour tout le site. Une même app les combine couramment — une page d’accueil marketing générée statiquement, un catalogue produit régénéré par ISR, un dashboard personnalisé rendu côté serveur et des widgets interactifs rendus côté client — chaque route choisissant selon ses propres besoins. La question n’est jamais « SSR, CSR ou SSG pour mon app ? » mais « lequel pour cette page ? », et la réponse découle des données de la page : identiques pour tous et stables → statique ; personnalisées ou fraîches → serveur ; derrière une connexion et très interactives → client.

Quelle stratégie pour chaque page ? Matrice de décision

Cas d’usage courants

• Sites de contenu — SSG et CDN pour des pages instantanées et lisibles par les robots (le pattern JAMstack).
• E-commerce — pages catalogue en ISR, panier et paiement en SSR, filtres interactifs en CSR — trois stratégies, une seule boutique.
• Dashboards SaaS — CSR derrière une connexion, là où le SEO ne compte pas mais l’interactivité, si.
• Presse et édition — SSR ou ISR pour la fraîcheur avec le SEO.
• PWA — un squelette rendu, plus l’interactivité côté client et le cache hors ligne.

Limites et trade-offs

• Le risque SEO du CSR est réel mais exagéré. Les robots exécutent le JavaScript avec un budget ; le CSR convient hors du chemin indexable et reste un pari dessus — de la nuance, pas de l’absolu.
• Le SSR coûte du calcul serveur. Rendre chaque requête a un prix en TTFB et en infrastructure qu’un fichier statique servi par un CDN n’a pas.
• Le décalage de fraîcheur du SSG. Les données du build restent périmées jusqu’au build suivant ; les sites volumineux ou changeants ont besoin d’ISR ou de longs builds.
• L’hydratation est l’impôt caché. Le HTML rendu côté serveur livre quand même du JS pour devenir interactif ; premier affichage rapide ne veut pas forcément dire premier clic rapide.
• Le mélange ajoute de la charge cognitive. Le rendu par route est puissant, mais il oblige à raisonner sur plusieurs moments de récupération des données dans une même app — la flexibilité a un coût en complexité.

Le rendu sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. C’est la constante sous le choix de rendu : les API REST et GraphQL alimentent le SSG au moment du build, le SSR à chaque requête sur le serveur et le CSR depuis le navigateur — le même endpoint que montrent les onglets de code, consommé à trois moments différents — si bien que changer la stratégie d’une route ne touche jamais le backend. Le recadrage qui ouvre cet article devient un confort concret : puisque le rendu est une décision frontend et que les données vivent derrière une API stable, avec son authentification et ses permissions, une équipe peut pré-générer le blog, rendre le dashboard côté serveur et rendre le shell de l’app côté client sur le même backend Back4app — en choisissant page par page, sans rien changer en dessous.