SSR, SSG et ISR : comparatif complet des strategies de rendu Next.js en 2026

Le choix d'une strategie de rendu conditionne l'ensemble de l'experience utilisateur, du temps de chargement initial a la fraicheur des donnees affichees. Avec Next.js 15 et l'App Router, les developpeurs disposent d'un arsenal de methodes de rendu qui va bien au-dela du simple diptyque "statique ou dynamique". Server-Side Rendering, Static Site Generation, Incremental Static Regeneration et, desormais, Partial Prerendering coexistent au sein du meme framework, chacun repondant a des contraintes specifiques de performance, de referencement et de logique metier.

Pourtant, face a cette richesse d'options, de nombreuses equipes techniques peinent a identifier la strategie optimale pour chaque page de leur application. Un mauvais choix peut degrader le Time to First Byte, penaliser l'indexation par les moteurs de recherche, ou generer une charge serveur disproportionnee. Ce guide technique approfondi compare methodiquement ces strategies de rendu, analyse leur impact sur les metriques de performance et de SEO, et fournit un cadre de decision actionnable pour les architectes et developpeurs front-end.

Comprendre les strategies de rendu dans le contexte de l'App Router

Le paradigme Server Components

Avant de comparer les strategies de rendu, il faut ancrer la reflexion dans le modele architectural impose par l'App Router de Next.js 15. Contrairement au Pages Router historique, ou chaque page etait un composant React client par defaut, l'App Router repose nativement sur les React Server Components (RSC). Par defaut, chaque composant est execute cote serveur. Il ne consomme aucun JavaScript cote client, sauf si le developpeur ajoute explicitement la directive "use client".

Ce changement de paradigme modifie profondement la facon dont le rendu est conceptualise. Le serveur ne se contente plus de generer du HTML brut ; il produit un flux serialise (le RSC Payload) qui contient a la fois le HTML pre-rendu et les instructions necessaires pour hydrater les composants interactifs cote client. Cette dualite est la fondation sur laquelle reposent toutes les strategies de rendu evoquees dans cet article.

Rendu statique et rendu dynamique : la distinction fondamentale

Dans l'App Router, Next.js determine automatiquement si une route doit etre rendue de maniere statique (au moment du build) ou de maniere dynamique (a chaque requete). Cette decision repose sur la detection de fonctions dynamiques dans le code de la route. L'utilisation de cookies(), headers(), ou de searchParams dans un composant serveur signale a Next.js que la route ne peut pas etre pre-calculee et doit etre generee dynamiquement.

Cette detection automatique simplifie le travail du developpeur, mais elle peut aussi creer des comportements inattendus si l'on ne comprend pas les mecanismes sous-jacents. Une route que l'on pensait statique peut basculer en rendu dynamique parce qu'un composant enfoui dans l'arbre utilise une fonction dynamique. Maitriser cette logique est un prerequis indispensable pour exploiter efficacement les strategies de rendu.

Static Site Generation (SSG) : le rendu au moment du build

Fonctionnement et mecanisme interne

La Static Site Generation est la strategie de rendu la plus performante en termes de temps de reponse brut. Le principe est simple : les pages HTML sont entierement generees au moment de la compilation (build time) et stockees sous forme de fichiers statiques. Lorsqu'un utilisateur ou un robot d'indexation effectue une requete, le serveur ou le CDN retourne directement le fichier pre-calcule, sans aucun traitement supplementaire.

Dans l'App Router, une route est statiquement generee par defaut si elle ne contient aucune fonction dynamique. Pour les routes dynamiques (celles qui utilisent des parametres comme [slug]), le developpeur doit fournir la liste exhaustive des chemins a pre-rendre via la fonction generateStaticParams.

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({
    slug: post.slug,
  }));
}
 
export default async function BlogPost({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const post = await getPostBySlug(slug);
  return <Article post={post} />;
}

A la compilation, Next.js invoque generateStaticParams, obtient la liste complete des slugs, puis genere une page HTML et un RSC Payload pour chacun d'entre eux. Le resultat est un ensemble de fichiers statiques prets a etre distribues par un CDN.

Avantages du SSG

Le premier atout du SSG est la vitesse de reponse. Un fichier statique servi depuis un CDN affiche un Time to First Byte de l'ordre de 20 a 50 millisecondes, quel que soit le volume de trafic. Il n'y a aucune requete base de donnees, aucune execution de code serveur au moment de la requete. Le fichier est simplement transfere.

Le deuxieme avantage est la scalabilite native. Puisque les fichiers sont statiques, ils peuvent etre dupliques sur des centaines de noeuds CDN a travers le monde. Un pic de trafic soudain ne genere aucune charge supplementaire sur le serveur d'origine. Le cout d'infrastructure reste constant, independamment du nombre de visiteurs simultanes.

Le troisieme point fort est la fiabilite. Un site statique ne peut pas tomber en panne a cause d'une surcharge base de donnees ou d'une erreur d'execution serveur. Si le CDN fonctionne, le site est disponible.

Limites et contraintes

La contrepartie du SSG reside dans la fraicheur des donnees. Le contenu est fige au moment du build. Si un article est modifie ou qu'un nouveau produit est ajoute, il faut relancer une compilation complete pour que le changement soit visible. Pour un blog de quelques dizaines d'articles, cela reste acceptable. Pour un catalogue e-commerce de cinquante mille references, le temps de build devient prohibitif.

L'autre limitation est l'impossibilite de personnaliser le contenu. Une page statique est identique pour tous les visiteurs. Impossible d'afficher un panier personnalise, un message de bienvenue nominatif, ou des recommandations basees sur l'historique de navigation sans recourir a du JavaScript cote client.

Cas d'usage ideaux

Le SSG est la strategie de reference pour les contenus a faible frequence de mise a jour. Les pages institutionnelles, les articles de blog, les pages de documentation technique, les pages d'atterrissage marketing et les catalogues de produits avec des mises a jour planifiees sont des candidats parfaits. Le denominateur commun : un contenu qui ne change pas entre deux deploiements.

Server-Side Rendering (SSR) : le rendu a la demande

Rendu dynamique dans l'App Router

Le Server-Side Rendering genere le HTML de la page a chaque requete entrante. Contrairement au SSG, il n'y a pas de fichier pre-calcule. Le serveur recoit la requete, execute le code du composant React, effectue les appels de donnees necessaires, produit le HTML complet et le renvoie au client.

Dans l'App Router, le SSR est declenche automatiquement lorsque Next.js detecte l'utilisation de fonctions dynamiques dans la route. Vous pouvez egalement forcer le comportement dynamique de maniere explicite :

// Force le rendu dynamique pour cette route
export const dynamic = "force-dynamic";
 
export default async function DashboardPage() {
  const session = await getSession();
  const data = await fetchUserData(session.userId);
 
  return (
    <main>
      <h1>Tableau de bord</h1>
      <UserStats data={data} />
    </main>
  );
}

Le segment de configuration dynamic = "force-dynamic" indique a Next.js que cette route doit toujours etre rendue au moment de la requete, meme si le code ne contient pas de fonction dynamique explicite.

Streaming et Suspense boundaries

L'une des avancees majeures du SSR dans l'App Router est le streaming. Au lieu d'attendre que la page entiere soit generee avant d'envoyer la reponse, le serveur commence a diffuser le HTML au fur et a mesure de sa generation. Les parties de la page qui sont pretes immediatement sont envoyees en premier, tandis que les composants dont les donnees necessitent un temps de chargement plus long sont diffuses ulterieurement.

Ce mecanisme repose sur les Suspense boundaries de React. En enveloppant un composant lent dans un composant <Suspense>, le developpeur definit un point de decoupe dans le flux de rendu. Le serveur envoie d'abord le fallback (un squelette de chargement, par exemple), puis injecte le contenu reel des que les donnees sont disponibles.

import { Suspense } from "react";
 
export default async function ProductPage({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await params;
  const product = await getProduct(id);
 
  return (
    <main>
      <ProductDetails product={product} />
      <Suspense fallback={<ReviewsSkeleton />}>
        <ProductReviews productId={id} />
      </Suspense>
      <Suspense fallback={<RecommendationsSkeleton />}>
        <RelatedProducts productId={id} />
      </Suspense>
    </main>
  );
}

Avec cette architecture, l'utilisateur voit les informations essentielles du produit presque instantanement. Les avis clients et les recommandations apparaissent progressivement, sans bloquer l'affichage initial. Le Time to First Byte est considerablement reduit, car le navigateur commence a recevoir du contenu des les premieres millisecondes.

Avantages du SSR

Le SSR garantit que chaque requete recoit des donnees a jour. Pour les applications ou la fraicheur de l'information est critique (tableaux de bord, pages de resultats de recherche, paniers d'achat, contenus personnalises), c'est un avantage determinant.

Le SSR permet egalement la personnalisation cote serveur. En accedant aux cookies, aux headers HTTP et aux parametres de requete, le serveur peut adapter le contenu en fonction de l'utilisateur : afficher un prix dans la bonne devise, adapter le contenu a la geolocalisation, ou pre-rendre un etat authentifie.

Le streaming ameliore significativement les metriques de performance percue. Meme si la page complete prend deux secondes a generer, l'utilisateur voit un premier affichage coherent en quelques centaines de millisecondes grace au flux progressif.

Limites et contraintes

Le SSR impose une charge serveur proportionnelle au trafic. Chaque requete declenche une execution de code, des appels de donnees et un rendu React. Pour un site a fort trafic, cela necessite une infrastructure serveur robuste et correctement dimensionnee. Les couts d'hebergement sont mecaniquement plus eleves qu'avec du SSG.

Le Time to First Byte est egalement plus eleve qu'en SSG, car le serveur doit effectuer un traitement avant de commencer a envoyer la reponse. Meme avec le streaming, le premier octet arrive plus tard qu'avec un fichier statique servi depuis un CDN.

Incremental Static Regeneration (ISR) : le compromis entre statique et dynamique

Le principe de revalidation

L'ISR represente un compromis elegant entre la performance du SSG et la fraicheur du SSR. Le concept est le suivant : les pages sont generees statiquement au moment du build, exactement comme en SSG, mais elles peuvent etre regenerees en arriere-plan apres un intervalle de temps defini, sans necessite de redeploiement complet.

Dans l'App Router, l'ISR est configure via l'option revalidate sur les appels fetch ou au niveau du segment de route :

// Revalidation au niveau du fetch
async function getProducts() {
  const res = await fetch("https://api.example.com/products", {
    next: { revalidate: 3600 }, // Revalide toutes les heures
  });
  return res.json();
}
 
// Ou au niveau du segment de route
export const revalidate = 3600;

Lorsqu'un utilisateur demande une page ISR dont le delai de revalidation est expire, le serveur retourne immediatement la version en cache (la version "perimee") tout en declenchant une regeneration en arriere-plan. Le visiteur suivant recevra la version fraichement regeneree. C'est le pattern stale-while-revalidate applique au rendu de pages.

Revalidation a la demande (on-demand revalidation)

Au-dela de la revalidation basee sur le temps, Next.js propose un mecanisme de revalidation a la demande. Ce systeme permet de declencher la regeneration d'une page specifique en reponse a un evenement exterieur, comme la mise a jour d'un contenu dans un CMS headless ou la modification d'un enregistrement en base de donnees.

// app/api/revalidate/route.ts
import { revalidatePath, revalidateTag } from "next/cache";
import { NextRequest, NextResponse } from "next/server";
 
export async function POST(request: NextRequest) {
  const { path, tag, secret } = await request.json();
 
  if (secret !== process.env.REVALIDATION_SECRET) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }
 
  if (tag) {
    revalidateTag(tag);
  } else if (path) {
    revalidatePath(path);
  }
 
  return NextResponse.json({ revalidated: true, now: Date.now() });
}

Ce webhook peut etre appele par un CMS headless (Sanity, Contentful, Strapi) a chaque publication de contenu. La page concernee est regeneree en quelques secondes, sans attendre l'expiration du delai de revalidation. C'est le meilleur compromis entre performance statique et fraicheur editoriale.

Le systeme de cache tags

L'App Router de Next.js 15 offre un systeme de cache tags granulaire qui ameliore considerablement la precision de la revalidation. Au lieu de revalider un chemin entier, vous pouvez associer des tags semantiques a vos appels de donnees et invalider uniquement les caches concernes :

// Associer un tag a un fetch
async function getPost(slug: string) {
  const res = await fetch(`https://api.cms.com/posts/${slug}`, {
    next: { tags: [`post-${slug}`, "posts"] },
  });
  return res.json();
}
 
// Invalider toutes les pages qui utilisent le tag "posts"
revalidateTag("posts");

Ce niveau de granularite permet de construire des strategies de cache sophistiquees ou chaque segment de donnees possede son propre cycle de vie. Modifier une fiche produit ne revalide que les pages qui affichent ce produit, sans toucher au reste du site.

Cas d'usage ideaux

L'ISR excelle pour les sites avec un grand volume de pages et des mises a jour moderees. Les catalogues e-commerce ou les prix changent quotidiennement, les portails d'actualites ou les articles sont publies plusieurs fois par jour, et les sites de contenu genere par les utilisateurs sont des cas d'usage naturels. L'ISR offre des temps de reponse proches du statique tout en garantissant une fraicheur de contenu raisonnable.

Partial Prerendering (PPR) : l'approche hybride de 2026

Un changement de paradigme

Le Partial Prerendering represente l'evolution la plus significative des strategies de rendu dans Next.js. Alors que les approches precedentes imposent un choix binaire par route (statique ou dynamique), le PPR permet de combiner du contenu statique et du contenu dynamique au sein d'une meme page.

Le principe est le suivant : lors du build, Next.js genere un shell statique contenant toutes les parties de la page qui ne dependent pas de donnees dynamiques. Les zones dynamiques (contenu personnalise, donnees en temps reel) sont delimitees par des Suspense boundaries et sont remplies au moment de la requete via le streaming.

import { Suspense } from "react";
 
export default function StorePage() {
  return (
    <main>
      {/* Contenu statique : genere au build */}
      <Header />
      <HeroBanner />
      <CategoryNavigation />
 
      {/* Contenu dynamique : streame a la requete */}
      <Suspense fallback={<CartSkeleton />}>
        <UserCart />
      </Suspense>
 
      {/* Contenu statique */}
      <FeaturedProducts />
 
      {/* Contenu dynamique */}
      <Suspense fallback={<RecommendationsSkeleton />}>
        <PersonalizedRecommendations />
      </Suspense>
 
      {/* Contenu statique */}
      <Footer />
    </main>
  );
}

Comment le PPR fonctionne en pratique

Lorsqu'un utilisateur demande cette page, le CDN retourne immediatement le shell statique pre-genere. Le TTFB est celui d'un fichier statique : quelques dizaines de millisecondes. L'utilisateur voit instantanement le header, la banniere, la navigation et les produits mis en avant. Simultanement, le serveur execute les composants dynamiques (panier utilisateur, recommandations personnalisees) et les injecte dans la page via le streaming.

Le resultat est une page qui combine le meilleur des deux mondes : la vitesse instantanee du SSG pour la structure et le contenu permanent, et la personnalisation en temps reel du SSR pour les zones qui en ont besoin.

Impact sur l'architecture des applications

Le PPR modifie fondamentalement la facon dont les developpeurs structurent leurs applications. Au lieu de raisonner en termes de "cette page est statique" ou "cette page est dynamique", la reflexion se fait au niveau du composant. Chaque composant est evalue individuellement : peut-il etre pre-rendu au build, ou necessite-t-il des donnees dynamiques ?

Cette granularite encourage une architecture ou les frontieres entre contenu statique et dynamique sont clairement definies dans le code via les Suspense boundaries. Les equipes qui adoptent le PPR constatent une amelioration notable du LCP, car le contenu principal est toujours servi de maniere statique, tandis que les elements secondaires sont charges progressivement.

Implications SEO de chaque strategie

Crawlabilite et indexation

Du point de vue des moteurs de recherche, la strategie de rendu determine la vitesse et la fiabilite avec laquelle le contenu est decouvert et indexe. Le SSG offre la meilleure garantie d'indexation : le HTML est complet, pre-rendu, et immediatement disponible. Les robots d'indexation n'ont pas besoin d'executer du JavaScript ni d'attendre un rendu serveur. Le contenu est indexable des la premiere visite du crawler.

Le SSR offre une indexation equivalente en qualite, car le HTML complet est genere cote serveur avant d'etre envoye au crawler. La difference reside dans la latence : le crawler doit attendre la generation de la page, ce qui consomme du budget de crawl. Pour les sites volumineux, cette latence supplementaire peut ralentir la decouverte de nouvelles pages.

L'ISR se comporte comme le SSG pour l'indexation initiale, puis beneficie de la revalidation pour maintenir le contenu a jour. Les crawlers voient toujours un HTML statique complet, avec la garantie que le contenu reflete les dernieres modifications dans un delai raisonnable.

Impact sur le TTFB et les signaux de performance

Google utilise les Core Web Vitals comme signaux de classement. Le TTFB, bien qu'il ne soit pas directement un Core Web Vital, influence fortement le LCP, qui en est un. Une strategie de rendu qui minimise le TTFB a donc un impact direct sur le positionnement dans les resultats de recherche.

Le SSG et le PPR (pour la partie statique) offrent le meilleur TTFB possible, car les fichiers sont servis depuis un CDN sans traitement serveur. L'ISR presente un TTFB similaire pour les pages en cache, avec une legere degradation lors de la premiere requete apres revalidation. Le SSR affiche systematiquement le TTFB le plus eleve, proportionnel a la complexite des operations serveur necessaires pour generer la page.

Strategies SEO par type de contenu

Pour les pages de contenu editorial (articles, guides, pages de documentation), le SSG est la strategie SEO optimale. Le contenu est immediatement disponible, le TTFB est minimal, et les moteurs de recherche indexent la page sans friction.

Pour les pages de catalogue produit avec des mises a jour frequentes (prix, disponibilite), l'ISR avec revalidation a la demande offre le meilleur equilibre. Le contenu est rapide a servir et reste synchronise avec les donnees du backend.

Pour les pages de resultats de recherche interne ou les pages fortement personnalisees, le SSR avec streaming est la seule option viable. Cependant, ces pages doivent etre soigneusement configurees avec des balises canoniques et des directives noindex appropriees pour eviter les problemes de contenu duplique.

Benchmarks de performance et metriques

Comparatif TTFB

Le Time to First Byte est la metrique qui differencie le plus nettement les strategies de rendu. Voici les ordres de grandeur constates en conditions reelles sur des applications Next.js 15 deployees sur une infrastructure edge :

SSG : 20 a 60 ms (fichier statique servi depuis le CDN le plus proche)

ISR (page en cache) : 25 a 70 ms (similaire au SSG, avec un leger overhead de verification du cache)

ISR (premiere requete apres revalidation) : 200 a 800 ms (regeneration en arriere-plan, l'ancien cache est servi)

PPR (shell statique) : 20 a 60 ms (identique au SSG pour le shell)

SSR (sans streaming) : 200 a 1500 ms (selon la complexite des operations serveur)

SSR (avec streaming) : premier octet en 50 a 150 ms, page complete en 200 a 1500 ms

First Contentful Paint et Largest Contentful Paint

Le FCP et le LCP sont directement influences par le TTFB. Avec du SSG, le FCP se situe generalement sous les 500 ms et le LCP sous les 1,2 secondes, en incluant le temps de rendu du navigateur et le chargement des ressources visuelles.

Le SSR avec streaming ameliore significativement le FCP par rapport au SSR classique, car le navigateur commence a afficher du contenu des la reception du premier fragment HTML. Le LCP peut toutefois rester eleve si l'element le plus volumineux de la page (une image hero, par exemple) depend d'une zone dynamique qui est streamee tardivement.

Le PPR offre les meilleurs resultats globaux : un FCP equivalent au SSG (le shell statique s'affiche immediatement) et un LCP optimal si l'element principal de la page fait partie du shell statique.

INP et interactivite

L'Interaction to Next Paint mesure la reactivite de la page aux interactions utilisateur. Cette metrique est moins directement influencee par la strategie de rendu que par la quantite de JavaScript cote client. Cependant, les strategies qui minimisent le JavaScript envoye au navigateur (SSG avec des Server Components purs, par exemple) produisent naturellement de meilleurs scores INP.

Le SSR avec une hydratation lourde cote client peut degrader l'INP si de nombreux composants interactifs doivent etre hydrates simultanement. L'utilisation judicieuse des Server Components et des Client Components est plus determinante pour l'INP que le choix entre SSG, SSR ou ISR.

Cadre de decision : choisir la bonne strategie

Criteres de selection

Le choix de la strategie de rendu doit etre guide par quatre criteres principaux :

Frequence de mise a jour du contenu. Si le contenu change rarement (moins d'une fois par jour), le SSG est suffisant. Si les mises a jour sont frequentes mais previsibles, l'ISR est adapte. Si le contenu est genere en temps reel ou personnalise, le SSR est necessaire.

Exigences de personnalisation. Si la page est identique pour tous les utilisateurs, le SSG ou l'ISR conviennent. Si la page doit afficher des donnees specifiques a l'utilisateur (panier, recommandations, tableau de bord), le SSR ou le PPR sont requis.

Volume de pages. Pour un site avec quelques centaines de pages, le build SSG reste rapide. Au-dela de plusieurs milliers de pages, le SSG pur devient contraignant et l'ISR prend tout son sens.

Budget d'infrastructure. Le SSG est le moins couteux a operer (hebergement statique). Le SSR est le plus couteux (serveur dimensionne pour le trafic). L'ISR se situe entre les deux.

Matrice de decision par type de page

Les pages marketing et institutionnelles (accueil, a propos, services) beneficient du SSG ou du PPR si elles contiennent un element personnalise. Les articles de blog et les pages de documentation sont des candidats ideaux pour le SSG pur. Les fiches produits e-commerce se pretent naturellement a l'ISR avec revalidation a la demande. Les tableaux de bord utilisateur et les pages de compte necessitent du SSR. Les pages hybrides, comme une page d'accueil e-commerce avec un contenu permanent et un panier personnalise, sont le territoire de predilection du PPR.

Patterns d'implementation dans Next.js 15

SSG avec generateStaticParams

L'implementation du SSG dans l'App Router repose sur l'export de la fonction generateStaticParams pour les routes dynamiques. Voici un pattern complet pour un blog multilingue :

// app/[locale]/blog/[slug]/page.tsx
import { getPostSlugs, getPost } from "@/lib/blog";
import { locales } from "@/lib/i18n";
 
export async function generateStaticParams() {
  const params = [];
  for (const locale of locales) {
    const slugs = await getPostSlugs(locale);
    for (const slug of slugs) {
      params.push({ locale, slug });
    }
  }
  return params;
}
 
export async function generateMetadata({
  params,
}: {
  params: Promise<{ locale: string; slug: string }>;
}) {
  const { locale, slug } = await params;
  const post = await getPost(locale, slug);
  return {
    title: post.title,
    description: post.description,
  };
}
 
export default async function BlogPostPage({
  params,
}: {
  params: Promise<{ locale: string; slug: string }>;
}) {
  const { locale, slug } = await params;
  const post = await getPost(locale, slug);
 
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

ISR avec revalidation configurable

Pour implementer l'ISR, il suffit d'ajouter une directive de revalidation au niveau du segment ou des appels fetch :

// app/products/[id]/page.tsx
 
// Revalidation toutes les heures
export const revalidate = 3600;
 
export async function generateStaticParams() {
  const products = await getTopProducts(100);
  return products.map((p) => ({ id: p.id }));
}
 
export default async function ProductPage({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await params;
 
  // Ce fetch herite du revalidate du segment
  const product = await getProduct(id);
 
  // Ce fetch a sa propre politique de revalidation
  const reviews = await fetch(
    `https://api.example.com/reviews/${id}`,
    { next: { revalidate: 300, tags: [`reviews-${id}`] } }
  ).then((r) => r.json());
 
  return (
    <main>
      <ProductDetails product={product} />
      <ReviewsList reviews={reviews} />
    </main>
  );
}

SSR avec streaming et Suspense

Le pattern SSR avec streaming s'appuie sur les Suspense boundaries pour definir les points de decoupe du flux :

// app/dashboard/page.tsx
import { Suspense } from "react";
 
export const dynamic = "force-dynamic";
 
export default async function DashboardPage() {
  return (
    <main>
      <h1>Tableau de bord</h1>
 
      <Suspense fallback={<StatsSkeleton />}>
        <DashboardStats />
      </Suspense>
 
      <div className="grid grid-cols-2 gap-6">
        <Suspense fallback={<ChartSkeleton />}>
          <RevenueChart />
        </Suspense>
        <Suspense fallback={<ChartSkeleton />}>
          <TrafficChart />
        </Suspense>
      </div>
 
      <Suspense fallback={<TableSkeleton />}>
        <RecentOrders />
      </Suspense>
    </main>
  );
}

Chaque composant enveloppe par <Suspense> est rendu et streame independamment. Si RevenueChart est pret avant TrafficChart, il est envoye au client en premier. L'utilisateur voit progressivement les elements de la page se materialiser, sans attendre que toutes les sources de donnees aient repondu.

Configuration PPR experimentale

Pour activer le Partial Prerendering, la configuration du projet doit inclure le flag experimental :

// next.config.ts
import type { NextConfig } from "next";
 
const nextConfig: NextConfig = {
  experimental: {
    ppr: true,
  },
};
 
export default nextConfig;

Une fois active, Next.js analyse automatiquement chaque route pour determiner quelles parties peuvent etre pre-rendues statiquement et quelles parties necessitent un rendu dynamique. Les Suspense boundaries servent de delimiter entre les deux modes.

Strategies de migration entre modes de rendu

De SSG vers ISR : la transition la plus naturelle

La migration du SSG vers l'ISR est la plus simple a executer. Elle ne necessite aucun changement structurel dans le code des composants. Il suffit d'ajouter une directive revalidate au segment de route ou aux appels fetch. Les pages continuent d'etre generees au build, mais elles sont desormais capables de se regenerer automatiquement.

Cette transition est recommandee lorsque le volume de contenu augmente au point ou les builds complets deviennent trop longs, ou lorsque les equipes editoriales ont besoin de voir leurs modifications publiees sans attendre un deploiement.

De SSR vers PPR : capturer le meilleur des deux mondes

Si votre application utilise du SSR pour des pages qui contiennent a la fois du contenu permanent et des zones personnalisees, le PPR permet de recuperer la performance du SSG pour les parties statiques. La migration consiste a identifier les composants qui ne dependent pas de donnees dynamiques et a les sortir des Suspense boundaries, puis a envelopper les composants dynamiques dans des <Suspense> avec des fallbacks explicites.

Le gain de performance est immediat : le shell statique est servi depuis le CDN, et seules les zones dynamiques necessitent un traitement serveur.

De l'ISR vers le SSG pur : simplifier quand c'est possible

Pour certaines pages dont le contenu a ete stabilise (une page "a propos" qui ne change plus, un article de blog ancien), il peut etre pertinent de retirer la directive de revalidation et de revenir a du SSG pur. Cela reduit la complexite du systeme de cache et garantit un comportement parfaitement previsible.

Adopter une approche incrementale

La force de Next.js reside dans sa capacite a melanger les strategies de rendu au sein d'une meme application. Il n'est ni necessaire ni souhaitable de choisir une seule strategie pour l'ensemble du projet. L'approche recommandee consiste a evaluer chaque route individuellement, en appliquant la strategie la plus adaptee a ses contraintes de fraicheur, de personnalisation et de performance.

Commencez par les pages a fort trafic et a fort impact SEO. Optimisez-les avec du SSG ou du PPR. Passez ensuite aux pages de catalogue avec l'ISR. Reservez le SSR pur aux pages authentifiees et aux interfaces administratives. Cette approche incrementale minimise les risques et permet de mesurer les gains a chaque etape.

Le paysage des strategies de rendu dans Next.js a profondement evolue avec l'App Router et les React Server Components. Le choix n'est plus binaire entre statique et dynamique. Les developpeurs disposent desormais d'un spectre complet d'options, du SSG pur au SSR avec streaming, en passant par l'ISR et le PPR. Maitriser ces strategies et savoir les appliquer au bon contexte est devenu une competence fondamentale pour tout ingenieur front-end qui vise l'excellence en performance et en referencement.