Regénération statique incrémentale (ISR)

Qu'est-ce que la regénération statique incrémentale (ISR) ?

La regénération statique incrémentale est une stratégie de rendu hybride qui combine la rapidité de la static-site-generation avec la fraîcheur du server-side-rendering. Les pages sont pré-rendues, mises en cache à l'edge et reconstruites en arrière-plan après un TTL configurable ou après qu'un webhook signale un changement de contenu. L'ISR est la stratégie de bataille pour les grands catalogues headless.

Définition

Avec l'ISR, la première requête vers une route renvoie le HTML statique mis en cache, tandis qu'un job de regénération s'exécute côté serveur pour produire une nouvelle version. Les requêtes suivantes reçoivent la page rafraîchie une fois prête. Next.js a popularisé l'ISR avec des intervalles de revalidation et la revalidation à la demande via des webhooks, et des modèles similaires existent dans Nuxt, SvelteKit et Astro. Le HTML mis en cache réside à l'edge d'un content-delivery-network-cdn ou dans un worker edge comme Vercel Edge ou Cloudflare Workers, offrant un TTFB comparable à de la SSG pure.

Pourquoi c'est important

Pour les sites de commerce comptant des millions de PDP, tout construire d'un coup est impraticable et reconstruire tout le site à chaque changement de contenu est gaspilleur. L'ISR permet aux équipes de traiter le catalogue comme un jeu de données évolutif : les pages à fort trafic restent chaudes en cache, les pages froides se regénèrent à la demande et les mises à jour de stock ou de prix se propagent en quelques secondes via des hooks de revalidation. Le résultat est un excellent LCP et un excellent TTFB sur toute la longue traîne, sans sacrifier l'agilité éditoriale d'un CMS headless, et avec un coût d'infrastructure prévisible.

Cas d'usage

Les stacks composable-commerce utilisent l'ISR pour les pages catégorie et produit où le prix, les badges et le stock changent fréquemment mais où la personnalisation n'est pas strictement requise. Un flux typique : Hygraph, Contentful ou Sanity émettent des webhooks à la publication, la boutique sous Next.js ou Nuxt revalide les slugs concernés sur Vercel ou Netlify, et le nouveau HTML est poussé sur le réseau edge. L'ISR est souvent superposé à l'Edge Rendering pour les fragments personnalisés et à des pipelines d'image-optimization pour que les shells statiques restent cacheables. C'est aussi un facteur clé lors d'une migration d'une monolithic-architecture vers le headless-commerce, car il maintient des budgets de performance stables pendant les déploiements incrémentaux.

Voir aussi

Découvrez Composable Headless Frontend · Performance and Core Web Vitals.

Frontend Insights