Next.js propose trois stratégies de rendu principales. Comprendre leurs différences est essentiel pour construire des applications performantes.

Les trois modes de rendu

SSG (Static Site Generation)

La page est générée au moment du build. Le HTML est créé une fois, puis servi tel quel à chaque visiteur.

// pages/blog/[slug].tsx
export async function getStaticPaths() {
  const posts = getAllPosts();
  return {
    paths: posts.map(post => ({ params: { slug: post.slug } })),
    fallback: false
  };
}

export async function getStaticProps({ params }) {
  const post = getPostBySlug(params.slug);
  return { props: { post } };
}

Avantages :

• Performance maximale (HTML pré-généré)
• Hébergement gratuit sur CDN
• Excellent pour le SEO

Inconvénients :

• Données figées jusqu'au prochain build
• Temps de build qui augmente avec le nombre de pages

Cas d'usage : blogs, documentation, pages marketing, portfolios.

SSR (Server-Side Rendering)

La page est générée à chaque requête. Le serveur exécute le code et retourne le HTML frais.

// pages/dashboard.tsx
export async function getServerSideProps({ req }) {
  const session = await getSession(req);
  const userData = await fetchUserData(session.userId);
  return { props: { userData } };
}

Avantages :

• Données toujours à jour
• Accès au contexte de requête (cookies, headers)
• Contenu personnalisé par utilisateur

Inconvénients :

• Temps de réponse plus lent (génération à chaque requête)
• Nécessite un serveur Node.js
• Coût d'hébergement plus élevé

Cas d'usage : dashboards, pages avec authentification, contenu personnalisé.

ISR (Incremental Static Regeneration)

Le meilleur des deux mondes : pages statiques qui se régénèrent automatiquement après un délai.

// pages/products/[id].tsx
export async function getStaticProps({ params }) {
  const product = await fetchProduct(params.id);
  return {
    props: { product },
    revalidate: 60 // Régénère après 60 secondes
  };
}

Avantages :

• Performance du SSG
• Données mises à jour régulièrement
• Pas de rebuild complet nécessaire

Inconvénients :

• Données potentiellement obsolètes pendant le délai de revalidation
• Plus complexe à débugger

Cas d'usage : e-commerce, sites d'actualités, catalogues produits.

Comment choisir ?

| Critère | SSG | SSR | ISR | |---------|-----|-----|-----| | Données statiques | ✅ | ❌ | ⚠️ | | Données temps réel | ❌ | ✅ | ⚠️ | | Performance | ⭐⭐⭐ | ⭐ | ⭐⭐⭐ | | SEO | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | | Personnalisation | ❌ | ✅ | ❌ |

Mon arbre de décision

1. Les données changent-elles souvent ?

   • Non → SSG
   • Oui, toutes les heures → ISR
   • Oui, à chaque requête → SSR

2. Le contenu est-il personnalisé par utilisateur ?

   • Oui → SSR (ou client-side fetching)
   • Non → SSG ou ISR

3. Combien de pages distinctes ?

   • < 1000 → SSG sans souci

   • 10000 → ISR avec fallback: 'blocking'

Patterns avancés

Hybride : statique + client-side

Pour une page produit e-commerce, combinez :

• SSG/ISR pour le contenu principal (nom, description, images)
• Fetching client pour les données dynamiques (stock, prix)

// Page générée statiquement
export async function getStaticProps({ params }) {
  const product = await fetchProduct(params.id);
  return { props: { product }, revalidate: 3600 };
}

// Composant avec données temps réel
function ProductPage({ product }) {
  const { data: stock } = useSWR(`/api/stock/${product.id}`);

  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <span>En stock : {stock?.quantity ?? '...'}</span>
    </div>
  );
}

On-demand Revalidation

Déclenchez la régénération manuellement via une API :

// pages/api/revalidate.ts
export default async function handler(req, res) {
  await res.revalidate('/products/' + req.body.productId);
  return res.json({ revalidated: true });
}

Utile quand un admin met à jour un produit dans le CMS.

Erreurs courantes

1. Utiliser SSR pour du contenu statique — gaspillage de ressources serveur
2. SSG avec trop de pages — builds de 30+ minutes
3. Oublier fallback — pages non générées qui retournent 404
4. ISR avec revalidate trop court — charge serveur inutile

Conclusion

Il n'y a pas de stratégie universelle. La bonne approche dépend de vos contraintes : fréquence de mise à jour, volume de pages, besoins de personnalisation.

Commencez par SSG. Passez à ISR si les données changent. Réservez SSR aux cas qui le nécessitent vraiment.