Next.js SSR vs SSG vs ISR : guide pour choisir sa stratégie de rendu

« Pourquoi l’accueil met trois secondes ? » Le patron fixe l’écran, le TTFB rouge dans Chrome DevTools s’étire comme un serpent. C’est là que j’ai compris : on avait peut-être choisi la mauvaise stratégie de rendu dès le départ.

Ce n’est pas un cas isolé. Sur les issues GitHub de Next.js, chaque jour quelqu’un demande : « SSR ou SSG ? » « Pourquoi mon ISR ne marche pas ? » Moi aussi j’étais perdu — la doc lue, le projet concret, et toujours l’indécision.

Vous avez peut-être vécu la même chose :

• SSR choisi, premier affichage insupportablement lent
• SSG choisi, chaque mise à jour relance un build complet
• ISR prometteur, configuration faite, et rien ne bouge

Il n’y a pas de stratégie « meilleure », seulement la plus adaptée. Aujourd’hui on clarifie quoi utiliser où, et comment éviter les pièges classiques.

D’abord : que sont ces trois stratégies ?

Avant de choisir, posons les bases — le plus simplement possible.

SSG (génération statique) : le bento préparé à l’avance

Imaginez une cantine : chaque matin, 100 bentos prêts sur le comptoir, le client part avec tout de suite. C’est le SSG.

Concrètement :

• Quand ça se génère : à next build, Next.js produit le HTML de toutes les pages
• À la visite : le CDN renvoie le HTML pré-généré, très vite
• Quand l’utiliser : contenu peu changeant — site vitrine, fiche produit, article de blog

Avantages :

• Vitesse élevée : selon AWS, le SSG charge 40 à 60 % plus vite que le SSR
• TTFB souvent sous 50 ms (mesures Vercel)
• Charge serveur quasi nulle, le trafic scale bien
• Coût faible : hébergement de fichiers statiques

Limites :

• Mise à jour de contenu = rebuild du site
• Beaucoup de pages = builds longs (des milliers de pages, 30 minutes possible)
• Pas de personnalisation : tout le monde voit la même chose

En résumé : la vitesse contre la préparation en amont.

SSR (rendu côté serveur) : cuisiner à la commande

Même cantine, mais plus de stock : le client commande, vous cuisinez sur place. C’est le SSR.

Concrètement :

• Quand ça se génère : à chaque requête, le serveur produit le HTML en temps réel
• À la visite : attente BDD, API, rendu, puis réponse
• Quand l’utiliser : données live ou contenu personnalisé

Avantages :

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

• Données toujours à jour
• Personnalisation (cookie, rôles, préférences)
• Accès aux infos de requête (headers, query)

Coûts :

• Plus lent : TTFB souvent 200-500 ms (Vercel)
• Charge serveur et coût d’infra plus élevés

Cas réel : un e-commerce en SSR, 2,3 s au premier affichage ; passage en ISR → 0,8 s.

ISR (régénération statique incrémentale) : bento + cuisine hybride

Vous préparez des bentos, mais vous les renouvelez toutes les heures. Les clients ont surtout du pré-fait, sans contenu trop vieux. C’est l’ISR.

Concrètement :

• Premier build : HTML statique comme en SSG
• Ensuite : régénération en arrière-plan selon revalidate
• À la visite : HTML en cache (rapide), refresh en fond si expiré

Équilibre :

• Vitesse proche du SSG
• Fraîcheur proche du SSR
• Pas besoin de rebuild global à chaque changement

Configuration simple (App Router) :

// app/posts/[id]/page.tsx
export const revalidate = 60; // revalidation après 60 secondes

export default async function Post({ params }) {
  const post = await getPost(params.id);
  return <div>{post.content}</div>;
}

Pièges :

• Ne marche pas en next dev — seulement next build + next start
• Toutes les plateformes ne le supportent pas nativement (Vercel oui, autres parfois via plugin)

L’ISR est ma stratégie par défaut : elle atténue les faiblesses du SSG et du SSR.

Arbre de décision : quel scénario, quelle stratégie

Les concepts sont posés. La question : quoi choisir pour votre projet ?

Étape 1 : trois questions

Question 1 : faut-il de la personnalisation ?

Si le contenu dépend de l’identité, des droits ou des préférences → SSR.

Exemples :

• Tableau de bord utilisateur
• Profil personnel
• Panier
• Pages derrière authentification

Pourquoi ? On ne peut pas pré-générer du contenu unique par utilisateur.

Question 2 : à quelle fréquence le contenu change-t-il ?

• Toutes les secondes ou minutes → SSR (cours boursiers, scores live, chat)
• Toutes les minutes ou heures → ISR (revalidate: 300 par ex. — actualités, listes produits, stock)
• Rarement ou sur action manuelle → SSG (vitrine, doc, pages légales)

Question 3 : quel volume de trafic ?

• Très fort (millions de PV/jour) → SSG ou ISR (CDN, coût maîtrisé)
• Modéré → les trois sont possibles ; si l’ISR suffit, pourquoi s’en priver ?

Étape 2 : tableau de scénarios

SSG — mot-clé : statique, public, peu de mises à jour

• Site vitrine d’entreprise
• Pages produit, tarifs
• Landing marketing
• Article de blog figé après publication
• Documentation technique, FAQ, centre d’aide

SSR — mot-clé : dynamique, personnalisé, temps réel

• Fil d’actualité type réseau social
• Dashboard personnel
• Panier, commandes
• Tableaux de bord live
• Résultats de recherche paramétrés
• Pages selon cookie/session

ISR — mot-clé : mises à jour périodiques, délai acceptable, fort trafic

• Accueil et listes de blog
• Sites d’actualités
• Fiche produit e-commerce (prix, stock)
• Fil de forum (likes/commentaires avec léger délai)
• Plateformes UGC
• Météo, taux de change

Étape 3 : le mix, c’est la norme

Erreur fréquente : une seule stratégie pour tout le site.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

En pratique, on combine :

• Accueil et listes → ISR
• Fiche produit → SSG ou ISR selon volatilité prix/stock
• Espace utilisateur → SSR
• À propos, contact → SSG

Exemple e-commerce de notre équipe :

• Accueil (ISR, 10 min)
• Liste produits (ISR, 5 min)
• Fiche (ISR, 3 min — stock variable)
• Panier (SSR, temps réel)
• Compte (SSR, personnalisé)
• À propos, confidentialité (SSG, quasi statique)

Performance et fraîcheur ensemble.

Règle en une phrase

Statique → SSG, temps réel → SSR, périodique → ISR

En cas de doute, testez l’ISR d’abord — c’est le choix le plus équilibré.

Trois pièges fréquents et comment les éviter

Piège 1 : revalidate ISR qui ne bouge pas

Symptôme : revalidate: 60 configuré, le contenu reste ancien.

Ma première galère : deux jours bloqué — l’ISR ne marchait pas en next dev.

Causes :

1. Environnement de développement

   L’ISR ne tourne pas sous next dev, seulement en prod.

   # Ne pas tester l'ISR avec next dev
   npm run build
   npm run start
   # puis tester en navigation

2. Plateforme d’hébergement

   Vercel : support natif. Netlify : souvent @netlify/plugin-nextjs. Vérifiez la doc « Next.js ISR support ».

3. CDN devant Next.js

   Cloudflare ou autre proxy peut figer la réponse. Faire respecter Cache-Control ou raccourcir le TTL CDN sur les pages ISR.

Conseil : tester en prod ; console.log(new Date()) pour voir l’heure de génération.

Piège 2 : premier affichage SSR trop lent

Symptôme : 2-3 secondes de blanc avant le contenu.

Cas : accueil SSR avec profil et recommandations — TTFB 1,2 s, total ~3 s.

Causes : API lentes, requêtes BDD lourdes, appels séquentiels, serveur éloigné.

Quatre leviers :

1. Streaming SSR + Suspense (React 18+)

   // app/dashboard/page.tsx
   import { Suspense } from 'react';
   
   export default function Dashboard() {
     return (
       <div>
         <h1>Tableau de bord</h1>
         <UserInfo />
         <Suspense fallback={<div>Chargement des statistiques...</div>}>
           <SlowStats />
         </Suspense>
       </div>
     );
   }

2. Requêtes parallèles

   // ❌ Séquentiel : lent
   const user = await getUser();
   const posts = await getPosts(user.id);
   
   // ✅ Parallèle : plus rapide
   const [user, posts] = await Promise.all([
     getUser(),
     getPosts()
   ]);

3. Passer à l’ISR

   Un délai d’une minute est-il acceptable ? Souvent oui — notre accueil : ISR revalidate: 60, 3 s → 0,7 s.

4. Edge Runtime

   // app/api/data/route.ts
   export const runtime = 'edge';

Piège 3 : build SSG interminable

Symptôme : milliers de pages, next build 20-30 minutes ou timeout.

Pourquoi : chaque URL génère du HTML au build ; beaucoup de pages ne sont jamais visitées.

Solutions :

1. Fallback

   // app/posts/[id]/page.tsx
   export async function generateStaticParams() {
     const posts = await getTopPosts(100);
     return posts.map(post => ({ id: post.id }));
   }
   
   export const dynamicParams = true;

2. ISR pour le long tail

   Build : accueil + pages chaudes ; le reste à la demande avec cache.

3. Builds incrémentaux

   Vercel : rebuild des pages modifiées seulement.

Résultat : blog 2000 articles — SSG pur 15 min → top 50 au build + dynamicParams + ISR revalidate: 3600 → build 2 min, UX identique.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Next.js 15 : RSC et PPR

React Server Components (RSC)

Avec l’App Router (13+), vous utilisez déjà des Server Components.

Différence avec le SSR « classique » :

• SSR traditionnel : page entière côté serveur
• RSC : par défaut serveur ; le client ne charge que l’interactif

Bénéfices :

• Bundle JS client réduit (30-50 % selon Next.js)
• Accès direct BDD / fichiers sans couche API dédiée

// app/posts/page.tsx
async function getPosts() {
  const posts = await db.posts.findMany();
  return posts;
}

export default async function PostsPage() {
  const posts = await getPosts();
  return (
    <div>
      {posts.map(post => (
        <PostCard key={post.id} post={post} />
      ))}
    </div>
  );
}

Pratique : Server Component par défaut ; 'use client' pour boutons, formulaires, animations.

Partial Prerendering (PPR)

Fonctionnalité expérimentale (Next.js 15) : même page, parties statiques et dynamiques.

Exemple fiche produit : description/images statiques au build ; stock/prix à la requête.

// next.config.js
module.exports = {
  experimental: {
    ppr: true,
  },
};

// app/products/[id]/page.tsx
export const experimental_ppr = true;

export default function ProductPage({ params }) {
  return (
    <div>
      <ProductDescription id={params.id} />
      <Suspense fallback={<div>Chargement...</div>}>
        <DynamicStock id={params.id} />
      </Suspense>
    </div>
  );
}

Attention : encore expérimental — pas pour toute la prod. À surveiller (Next.js 16 ?).

RSC avec SSR / SSG / ISR

• RSC + SSG : Server Components statiques par défaut
• RSC + ISR : + revalidate
• RSC + SSR : routes dynamiques ou dynamic = 'force-dynamic'
• PPR : fusion avancée statique/dynamique

Les RSC sont l’architecture ; SSG/SSR/ISR sont les stratégies — elles se complètent.

Conclusion

Pas de réponse unique : trafic, budget et fraîcheur varient. Trois questions suffisent :

1. Personnalisation ? → SSR
2. Fréquence de mise à jour ? → temps réel SSR, périodique ISR, rare SSG
3. Trafic ? → fort : SSG ou ISR

L’accueil du début ? SSR → ISR (revalidate: 60), 3 s → 0,8 s.

Recommandations :

• En doute, essayez l’ISR
• Mesurez TTFB, FCP avec Chrome DevTools Performance
• Mélangez les stratégies par route

Les besoins évoluent — Next.js permet d’ajuster sans tout casser.

Si vous avez des retours terrain, partagez-les en commentaire !