ISR
Définition
Incremental Static Regeneration. Pattern Next.js qui sert des pages statiques rapides tout en les régénérant en arrière-plan à intervalle régulier. Combine vitesse de site statique et données à jour.
Comment ça marche
L'ISR (Incremental Static Regeneration) génère des pages statiques au build, puis les régénère en arrière-plan à intervalle régulier ou sur invalidation explicite. L'utilisateur reçoit toujours une page statique ultra-rapide servie depuis le CDN, et le contenu se met à jour sans rebuilder tout le site. Concrètement, quand une page expire selon sa durée de revalidation, la première requête déclenche la régénération en arrière-plan : le visiteur reçoit la version actuelle, et le suivant verra la nouvelle. C'est un compromis entre la performance du SSG et la fraîcheur du SSR.
À quoi ça sert
L'ISR est la bonne approche pour les sites avec beaucoup de pages de contenu qui évoluent occasionnellement : blog, catalogue produits, glossaire, base d'articles, pages SEO programmatiques. On garde la performance d'un SSG (HTML pré-calculé, distribué depuis un CDN, TTFB sous les 100 ms) sans la contrainte de régénérer tout le site à chaque mise à jour. Pour un catalogue de 10 000 produits dont les prix changent quelques fois par jour, l'ISR évite des builds de plusieurs minutes tout en gardant les prix à jour.
Revalidation par durée
Sur Next.js, on déclare une durée de revalidation au niveau de la page ou de l'appel fetch : revalidate: 3600 sur un appel fetch indique que la page mise en cache sera régénérée au plus toutes les heures. La première requête après expiration sert encore l'ancienne version (stratégie stale-while-revalidate), et la régénération se fait en arrière-plan. C'est simple à mettre en place, mais peu adapté quand le contenu doit être mis à jour immédiatement après modification. On choisit la durée selon l'acceptabilité du décalage.
Revalidation à la demande
Pour invalider une page précise après une modification (publication d'un article, changement de prix, mise à jour de fiche), Next.js propose revalidatePath et revalidateTag. On appelle ces fonctions depuis une Server Action ou un webhook entrant (CMS, base de données). La page concernée est marquée stale, et la prochaine requête déclenche la régénération. C'est l'approche à privilégier pour les sites pilotés par CMS : Sanity, Strapi, Storyblok poussent un webhook à chaque publication, et le site se met à jour en quelques secondes.
Quand l'utiliser
L'ISR est pertinent quand vous avez beaucoup de pages, que le contenu évolue occasionnellement, et que la fraîcheur tolère un délai allant de quelques secondes à plusieurs heures. À l'inverse, pour des pages totalement statiques (page d'accueil marketing qui change tous les six mois), le SSG pur suffit. Pour des pages où chaque visiteur voit un contenu différent ou des données strictement temps réel (panier, dashboard personnalisé, prix bourse), on bascule sur SSR. L'ISR est le bon défaut pour les sites de contenu en production.
Les limites à connaître
L'ISR sur Vercel s'appuie sur leur infrastructure d'edge cache, qui fonctionne très bien mais coûte sur les très gros volumes de pages. Sur d'autres hébergeurs (auto-hébergé, AWS, autres clouds), l'implémentation est plus limitée : Next.js stocke les pages générées sur le disque local, ce qui pose problème en mode multi-instances sans stockage partagé. On utilise alors un cache externe (Redis, S3) avec un handler custom. Côté débogage, l'ISR cache plusieurs couches (CDN, build, runtime), donc reproduire localement un comportement de prod demande de la rigueur.