Quelle est la différence entre SSR et SSG ?

Le SSR (Server-Side Rendering) génère le HTML à chaque requête utilisateur sur le serveur, garantissant des données toujours fraîches mais avec un temps de réponse plus long. Le SSG (Static Site Generation) pré-génère toutes les pages au moment du build, offrant des temps de chargement ultra-rapides via CDN mais nécessitant un nouveau déploiement pour mettre à jour le contenu.

Quel rendering pattern choisir pour un site e-commerce ?

Pour un site e-commerce, l'ISR (Incremental Static Regeneration) est souvent le meilleur compromis. Il permet de servir des pages statiques rapides tout en régénérant automatiquement les fiches produits dont les prix ou stocks changent. Les pages panier et checkout restent en CSR ou SSR pour refléter les données en temps réel. Pour un catalogue très volumineux (plus de 10 000 produits), l'ISR évite aussi les temps de build excessifs du SSG pur.

SSR, SSG, ISR : comprendre les rendering patterns et leur impact performance

Pourquoi les rendering patterns sont devenus un enjeu stratégique

En 2024, Google a confirmé que les Core Web Vitals — et notamment le Largest Contentful Paint (LCP) et l’Interaction to Next Paint (INP) — restent des signaux de classement actifs. Autrement dit, la façon dont votre site génère et sert son HTML a un impact direct sur votre référencement, votre taux de conversion et l’expérience de vos utilisateurs.

Le choix du rendering pattern n’est plus un simple débat d’architecture technique réservé aux développeurs. C’est une décision business qui influence :

La vitesse de chargement perçue par l’utilisateur
L’indexation de vos pages par les moteurs de recherche
Les coûts d’infrastructure serveur
La scalabilité de votre plateforme

Dans cet article, nous décryptons les quatre principaux patterns de rendu — CSR, SSR, SSG et ISR — avec des chiffres concrets, des exemples de code et un tableau comparatif pour vous aider à faire le bon choix.

CSR : le Client-Side Rendering, point de départ historique

Comment ça fonctionne

Avec le Client-Side Rendering, le serveur envoie une page HTML quasi vide contenant un bundle JavaScript. C’est le navigateur de l’utilisateur qui exécute ce JavaScript pour construire l’intégralité du DOM et afficher le contenu.

C’est le modèle par défaut des SPA (Single Page Applications) développées avec React, Vue.js ou Angular sans configuration serveur particulière.

Exemple simplifié

<!-- Ce que le serveur envoie en CSR -->
<!DOCTYPE html>
<html>
<head>
  <title>Mon App</title>
</head>
<body>
  <div id="root"></div>
  <!-- Tout le contenu sera injecté par JavaScript -->
  <script src="/bundle.js" defer></script>
</body>
</html>

Avantages et limites

Avantages :

Expérience fluide après le chargement initial (navigation sans rechargement)
Simplicité de déploiement (un simple hébergement statique suffit)
Idéal pour les applications interactives type dashboard ou back-office

Limites :

LCP dégradé : le contenu n’apparaît qu’une fois le JavaScript téléchargé, parsé et exécuté
SEO problématique : même si Googlebot exécute le JS, l’indexation reste plus lente et moins fiable
TTFB correct, mais FCP et LCP médiocres : sur un réseau 3G, un bundle de 300 Ko peut retarder l’affichage de 3 à 5 secondes

Le CSR pur est aujourd’hui déconseillé pour les sites vitrines, blogs et e-commerce où le SEO et la performance de premier affichage sont critiques.

SSR : le Server-Side Rendering pour des données toujours fraîches

Comment ça fonctionne

Avec le Server-Side Rendering, chaque requête utilisateur déclenche la génération du HTML complet sur le serveur. Le navigateur reçoit une page prête à être affichée, puis le JavaScript prend le relais pour rendre la page interactive (phase d’hydratation).

Next.js, Nuxt.js et SvelteKit proposent tous le SSR comme option de rendu.

Exemple avec Next.js (App Router)

// app/products/[id]/page.js
// Par défaut, les composants serveur dans Next.js 14+
// effectuent du SSR dynamique quand des données changent

export default async function ProductPage({ params }) {
  // Cette requête s'exécute sur le serveur à chaque visite
  const product = await fetch(
    `https://api.example.com/products/${params.id}`,
    { cache: 'no-store' } // Force le SSR dynamique
  ).then(res => res.json());

  return (
    <main>
      <h1>{product.name}</h1>
      <p>Prix : {product.price} €</p>
      <p>Stock : {product.stock} unités</p>
    </main>
  );
}

Avantages et limites

Avantages :

HTML complet dès la première réponse : excellent pour le SEO
Données toujours à jour : chaque requête interroge la source de vérité
FCP rapide : l’utilisateur voit le contenu avant même que le JS ne soit chargé

Limites :

TTFB plus élevé : le serveur doit exécuter du code et potentiellement interroger une base de données (150 à 800 ms typiquement)
Charge serveur : chaque visiteur consomme des ressources CPU, ce qui peut coûter cher à l’échelle
Non cacheable par défaut : sans stratégie de cache, chaque requête génère un nouveau rendu

Chez Lueur Externe, nos équipes certifiées AWS Solutions Architect dimensionnent les infrastructures SSR avec des stratégies de cache intelligent (Redis, CDN edge caching) pour maintenir un TTFB inférieur à 200 ms même sous forte charge.

SSG : le Static Site Generation, la performance maximale

Comment ça fonctionne

Le Static Site Generation pré-génère toutes les pages HTML au moment du build (compilation). Les fichiers statiques sont ensuite déployés sur un CDN. Quand un utilisateur demande une page, le CDN lui sert directement le fichier HTML — aucun calcul serveur n’est nécessaire.

Performances concrètes

Un site en SSG servi via un CDN comme CloudFront ou Cloudflare affiche typiquement :

TTFB : 20 à 80 ms (temps de réponse du edge server le plus proche)
FCP : < 500 ms sur une connexion 4G
LCP : < 1 seconde pour une page texte avec images optimisées

À titre de comparaison, un SSR sans cache tourne plutôt autour de 200 à 600 ms de TTFB.

Avantages et limites

Avantages :

Performance inégalée : aucun temps de calcul à la requête
Sécurité renforcée : pas de serveur dynamique exposé
Coût d’hébergement minimal : un simple bucket S3 + CDN suffit
SEO parfait : HTML complet, temps de réponse instantané

Limites :

Temps de build : un catalogue de 50 000 pages peut prendre 20 à 45 minutes à générer
Données figées : le contenu ne change qu’au prochain déploiement
Inadapté aux contenus personnalisés ou temps réel (panier, profil utilisateur)

Le SSG est idéal pour les blogs, sites vitrines, documentations et landing pages dont le contenu change rarement.

ISR : l’Incremental Static Regeneration, le meilleur des deux mondes

Comment ça fonctionne

L’Incremental Static Regeneration, popularisé par Next.js, combine la rapidité du SSG avec la fraîcheur du SSR. Le principe :

Les pages sont pré-générées statiquement au build
Quand un utilisateur visite une page après un délai défini (revalidation), la page statique est servie instantanément
En arrière-plan, le serveur régénère une nouvelle version de la page
Les visiteurs suivants reçoivent la version mise à jour

C’est une stratégie de type stale-while-revalidate appliquée au rendu HTML.

Exemple avec Next.js

// app/products/[id]/page.js
// ISR avec revalidation toutes les 60 secondes

export default async function ProductPage({ params }) {
  const product = await fetch(
    `https://api.example.com/products/${params.id}`,
    { next: { revalidate: 60 } } // Régénère la page toutes les 60s
  ).then(res => res.json());

  return (
    <main>
      <h1>{product.name}</h1>
      <p>Prix : {product.price} €</p>
      <p>Stock : {product.stock} unités</p>
    </main>
  );
}

// Pré-génère les 100 produits les plus populaires au build
export async function generateStaticParams() {
  const topProducts = await fetch(
    'https://api.example.com/products/top-100'
  ).then(res => res.json());

  return topProducts.map(p => ({ id: p.id.toString() }));
}

On-demand revalidation : encore plus précis

Depuis Next.js 12.1, il est possible de déclencher la régénération d’une page à la demande via une API Route. Lorsqu’un produit est mis à jour dans le back-office (Prestashop, WordPress ou tout autre CMS), un webhook appelle cette route et la page est immédiatement régénérée :

// app/api/revalidate/route.js
import { revalidatePath } from 'next/cache';

export async function POST(request) {
  const { path, secret } = await request.json();

  if (secret !== process.env.REVALIDATION_SECRET) {
    return Response.json({ error: 'Invalid secret' }, { status: 401 });
  }

  revalidatePath(path);
  return Response.json({ revalidated: true, path });
}

Cette approche est particulièrement puissante pour les sites e-commerce sous Prestashop : les fiches produits sont servies en statique pour une performance optimale, mais se mettent à jour en quelques secondes dès qu’un prix ou un stock change dans le back-office.

Tableau comparatif des rendering patterns

Critère	CSR	SSR	SSG	ISR
TTFB	~50 ms	150-800 ms	20-80 ms	20-80 ms
FCP	1,5-4 s	0,5-1,5 s	0,2-0,5 s	0,2-0,5 s
LCP	2-6 s	0,8-2 s	0,5-1 s	0,5-1 s
SEO	⚠️ Médiocre	✅ Excellent	✅ Excellent	✅ Excellent
Fraîcheur données	✅ Temps réel	✅ Temps réel	❌ Build only	✅ Quasi temps réel
Coût serveur	Faible	Élevé	Très faible	Modéré
Complexité	Faible	Moyenne	Faible	Moyenne
Idéal pour	Dashboards, apps internes	Apps dynamiques, contenus personnalisés	Blogs, docs, landing pages	E-commerce, sites de contenu à fort volume

Chiffres indicatifs basés sur des pages de poids moyen (~200 Ko HTML + assets) servies en Europe sur une connexion 4G.

Comment choisir le bon rendering pattern pour votre projet

La question clé : à quelle fréquence votre contenu change-t-il ?

Voici un arbre de décision simplifié :

Le contenu ne change jamais ou rarement (moins d’une fois par jour) → SSG
Le contenu change régulièrement (plusieurs fois par jour) mais pas en temps réel → ISR
Le contenu est personnalisé par utilisateur ou change en temps réel → SSR
Le contenu n’a pas besoin d’être indexé et l’app est très interactive → CSR

L’approche hybride : la réalité des projets modernes

En pratique, les frameworks modernes comme Next.js 14, Nuxt 3 ou Astro permettent de mixer les patterns au sein d’un même projet. C’est l’approche que nous recommandons systématiquement chez Lueur Externe pour les projets de nos clients :

Pages d’accueil et catégories → ISR (revalidation toutes les 5 minutes)
Fiches produit → ISR avec on-demand revalidation via webhook Prestashop
Blog et pages institutionnelles → SSG pur
Panier, checkout, espace client → CSR ou SSR
Pages de résultats de recherche → SSR avec cache Redis (TTL 30 secondes)

Cette granularité permet d’atteindre un score Lighthouse Performance de 95+ sur les pages clés tout en maintenant la fraîcheur des données là où c’est nécessaire.

Impact mesurable sur le business

Les chiffres parlent d’eux-mêmes :

Vodafone a constaté une augmentation de 8 % des ventes en améliorant son LCP de 31 % (source : web.dev)
NDTV a réduit son LCP de 55 % en passant à Next.js avec ISR et a vu son trafic organique augmenter de 12 %
Selon Deloitte, chaque amélioration de 100 ms du temps de chargement augmente le taux de conversion de 0,7 % en e-commerce

Le rendering pattern est donc un levier de performance à ne pas négliger dans votre stratégie digitale.

Les pièges à éviter

1. Tout mettre en SSR “par sécurité”

C’est une erreur fréquente. Le SSR systématique surcharge vos serveurs et augmente vos coûts d’infrastructure AWS ou Vercel sans bénéfice réel pour les pages qui ne changent pas souvent. Identifiez les pages qui nécessitent réellement des données en temps réel.

2. Ignorer l’hydratation JavaScript

Même avec du SSR ou SSG, le poids du JavaScript d’hydratation impacte l’INP et le TTI (Time to Interactive). Des frameworks comme Astro (avec son approche “islands”) ou les React Server Components de Next.js 14 permettent de réduire drastiquement le JS envoyé au client : souvent de 60 à 80 % de JavaScript en moins.

3. Oublier le cache CDN

Une page SSR sans stratégie de cache CDN perd l’essentiel de son potentiel. Configurez des headers Cache-Control et stale-while-revalidate adaptés :

Cache-Control: public, s-maxage=60, stale-while-revalidate=300

Cette directive sert le contenu depuis le cache CDN pendant 60 secondes, puis continue à servir le cache pendant 300 secondes supplémentaires tout en régénérant en arrière-plan. C’est essentiellement de l’ISR au niveau infrastructure.

4. Ne pas mesurer avant et après

Tout changement de rendering pattern doit être accompagné de mesures concrètes. Utilisez :

Google PageSpeed Insights pour les Core Web Vitals de terrain (données CrUX)
Lighthouse CI intégré à votre pipeline de déploiement
Web Vitals JS pour le monitoring en production (RUM — Real User Monitoring)

L’avenir : streaming SSR et partial prerendering

Les rendering patterns continuent d’évoluer. Deux tendances majeures se dessinent pour 2024-2025 :

Streaming SSR : au lieu d’attendre que toute la page soit générée, le serveur envoie le HTML par morceaux au fur et à mesure. L’utilisateur voit le header et le contenu principal pendant que le reste se charge. Next.js 14 l’implémente nativement avec les React Suspense Boundaries.
Partial Prerendering (PPR) : une page combine une coquille statique (pré-générée au build) avec des “trous” dynamiques remplis en streaming au moment de la requête. C’est le futur du rendu hybride, actuellement en version expérimentale dans Next.js 15.

Ces approches promettent de rendre la frontière entre SSG et SSR presque invisible, offrant à la fois la performance du statique et la flexibilité du dynamique.

Conclusion : la performance commence par le bon choix d’architecture

Le choix d’un rendering pattern n’est pas anodin. Il conditionne la vitesse de votre site, son référencement naturel, vos coûts d’hébergement et l’expérience de vos utilisateurs. Voici les trois règles à retenir :

Utilisez le SSG ou l’ISR par défaut pour toutes les pages dont le contenu n’est pas personnalisé
Réservez le SSR aux pages qui nécessitent des données en temps réel ou une personnalisation utilisateur
Mesurez systématiquement l’impact de vos choix sur les Core Web Vitals

Chez Lueur Externe, nous accompagnons depuis plus de 20 ans les entreprises des Alpes-Maritimes et au-delà dans l’optimisation de leur performance web. Notre expertise combinée Prestashop, WordPress, AWS et SEO nous permet de concevoir des architectures de rendu sur mesure, adaptées aux enjeux de chaque projet.

Vous souhaitez auditer la performance de votre site ou migrer vers une architecture de rendu plus performante ? Contactez nos experts pour un diagnostic personnalisé et des recommandations concrètes adaptées à votre stack technique et vos objectifs business.