Site icon Blog ARC Optimizer

Un guide complet de la régénération statique incrémentielle (ISR) avec Next.js


À propos de l'auteur

Lee est un développeur, un écrivain et un créateur de cours. Il travaille actuellement chez Vercel en tant qu'architecte de solutions et dirige DevRel pour Next.js. Il parle souvent de…
En savoir plus sur
Lee

La régénération statique incrémentielle (ISR) est une nouvelle évolution du Jamstack, vous permettant de mettre à jour le contenu statique instantanément sans avoir besoin d'une reconstruction complète de votre site. L'approche hybride de Next.js vous permet d'utiliser ISR pour le commerce électronique, les pages marketing, les articles de blog, les supports publicitaires, etc.

Il y a un an, Next.js 9.3 a publié le support pour la génération de sites statiques (SSG), ce qui en fait le premier framework hybride. J'étais un heureux utilisateur de Next.js depuis environ quelques années à ce stade, mais cette version a fait de Next.js ma nouvelle solution par défaut. Après avoir beaucoup travaillé avec Next.js, j'ai rejoint Vercel pour aider des entreprises comme Tripadvisor et le Washington Post à adopter et à faire évoluer Next.js.

Dans cet article, j'aimerais explorer une nouvelle évolution du Jamstack: Régénération statique incrémentale (ISR) . Vous trouverez ci-dessous un guide d'ISR – y compris des cas d'utilisation, des démos et des compromis.

Le problème de la génération de sites statiques

L'idée derrière le Jamstack est séduisante: des pages statiques pré-rendues qui peuvent être poussées vers un CDN et disponible dans le monde entier en quelques secondes. Le contenu statique est rapide, résilient aux temps d'arrêt et immédiatement indexé par les robots d'exploration. Mais il y a quelques problèmes.

Si vous avez adopté l'architecture Jamstack lors de la création d'un site statique à grande échelle, vous risquez de devoir attendre des heures la création de votre site. Si vous doublez le nombre de pages, le temps de construction double également. Prenons Target.com . Est-il possible de générer statiquement des millions de produits à chaque déploiement?

Le problème de la génération de sites statiques: comme les temps de construction évoluent de manière linéaire avec le nombre de pages, vous pourriez être bloqué en attente pendant des heures pour votre site à construire. ( Grand aperçu )

Même si chaque page était générée statiquement en un temps irréaliste de 1ms, il faudrait encore heures pour reconstruire l'ensemble du site . Pour les applications Web volumineuses, choisir complete génération de sites statiques n'est pas une solution. Les équipes à grande échelle ont besoin d'une solution hybride plus flexible et personnalisée.

Systèmes de gestion de contenu (CMS)

Pour de nombreuses équipes, le contenu de leur site est découplé du code. L'utilisation d'un Headless CMS permet aux éditeurs de contenu de publier des modifications sans impliquer un développeur. Cependant, avec les sites statiques traditionnels, ce processus peut être lent.

Prenons une boutique de commerce électronique avec 100 000 produits. Les prix des produits changent fréquemment. Lorsqu'un éditeur de contenu modifie le prix des écouteurs de 100 $ à 75 $ dans le cadre d'une promotion, son CMS utilise un webhook pour reconstruire l'ensemble du site. Il n’est pas possible d’attendre des heures pour que le nouveau prix soit pris en compte.

Les constructions longues avec des calculs inutiles peuvent également entraîner des dépenses supplémentaires. Idéalement, votre application est suffisamment intelligente pour comprendre quels produits ont changé et progressivement mettre à jour ces pages sans avoir besoin d'une reconstruction complète .

Incremental Static Regeneration (ISR)

Next.js vous permet de créer ou de mettre à jour des pages statiques après vous avez construit votre site. La régénération statique incrémentielle (ISR) permet aux développeurs et aux éditeurs de contenu d'utiliser la génération statique par page, sans avoir à reconstruire le site entier . Avec ISR, vous pouvez conserver les avantages de la statique tout en passant à des millions de pages.

Les pages statiques peuvent être générées au moment de l'exécution (à la demande) plutôt qu'au moment de la construction avec ISR. En utilisant des analyses, des tests A / B ou d'autres mesures, vous êtes équipé de la flexibilité nécessaire pour faire votre propre compromis sur les temps de construction.

Considérez le magasin de commerce électronique d'autrefois avec 100 000 produits. À 50 ms réaliste pour générer statiquement chaque page de produit, cela prendrait près de 2 heures sans ISR . Avec ISR, nous pouvons choisir parmi:

  • Constructions plus rapides
    Générez les 1 000 produits les plus populaires au moment de la construction. Les demandes adressées à d'autres produits seront manquantes dans le cache et seront générées statiquement à la demande: compilations en 1 minute.
  • Taux de succès du cache plus élevé
    Générez 10 000 produits au moment de la construction, garantissant ainsi la mise en cache d'un plus grand nombre de produits avant la demande d'un utilisateur. : Constructions de 8 minutes.
L'avantage d'ISR: Vous avez la flexibilité de choisir quelles pages sont générées à la construction ou à la demande. Choisissez parmi (A) des versions plus rapides ou (B) plus mises en cache. ( Grand aperçu )

Voyons un exemple d'ISR pour une page de produit de commerce électronique.

Mise en route

Récupération de données

Si vous n'avez jamais utilisé Next.js avant, je vous recommande de lire Getting Started With Next.js pour comprendre les bases. ISR utilise la même API Next.js pour générer des pages statiques: getStaticProps . En spécifiant revalidate: 60 nous informons Next.js d'utiliser ISR pour cette page.

Un diagramme du flux de demande pour la régénération statique incrémentielle . ( Grand aperçu )
  1. Next.js peut définir un temps de revalidation par page. Définissons-le à 60 secondes.
  2. La demande initiale à la page du produit affichera la page mise en cache avec le prix d'origine.
  3. Les données du produit sont mises à jour dans le CMS.
  4. Toute demande à la page après la requête initiale et avant 60 secondes sont mises en cache et instantanées.
  5. Après la fenêtre de 60 secondes, la requête suivante affichera toujours la page mise en cache (périmée). Next.js déclenche une régénération de la page en arrière-plan .
  6. Une fois la page générée avec succès, Next.js invalidera le cache et affichera la page produit mise à jour. Si la régénération en arrière-plan échoue, l'ancienne page reste inchangée.
 // pages / products / [id] .js

Exporter la fonction asynchrone getStaticProps ({params}) {
  revenir {
    accessoires: {
      produit: attendez getProductFromDatabase (params.id)
    },
    revalider: 60
  }
}

Génération de chemins

Next.js définit les produits à générer au moment de la construction et ceux à la demande. Générons uniquement les 1 000 produits les plus populaires au moment de la construction en fournissant à getStaticPaths une liste des 1 000 principaux ID de produits.

Nous devons configurer la manière dont Next.js «se replie» lors de la demande de l'un des les autres produits après la construction initiale. Vous avez le choix entre deux options: blocking et true .

  • fallback: blocking (de préférence)
    Lorsqu'une requête est adressée à une page qui n'a pas t été généré, Next.js rendra la page par le serveur à la première requête. Les demandes futures serviront le fichier statique à partir du cache.
  • fallback: true
    Lorsqu'une demande est faite à une page qui n'a pas été générée, Next.js servira immédiatement une page statique avec un chargement état à la première demande. Une fois le chargement des données terminé, la page sera de nouveau rendue avec les nouvelles données et mise en cache. Les demandes futures serviront le fichier statique à partir du cache.
 // pages / products / [id] .js

Exporter la fonction asynchrone getStaticPaths () {
  const products = attendre getTop1000Products ()
  chemins const = products.map ((produit) => ({
    paramètres: {id: product.id}
  }))

  return {chemins, repli: "blocage"}
}

Compromis

Next.js se concentre avant tout sur l'utilisateur final. La «meilleure solution» est relative et varie selon le secteur, le public et la nature de l'application. En permettant aux développeurs de passer d'une solution à une autre sans quitter les limites du cadre, Next.js vous permet de choisir le bon outil pour le projet.

Rendu côté serveur

ISR n'est pas toujours la bonne solution. Par exemple, le fil d'actualité Facebook ne peut pas afficher de contenu périmé. Dans ce cas, vous souhaitez utiliser SSR et éventuellement vos propres en-têtes de contrôle de cache avec clés de substitution pour invalider le contenu. Puisque Next.js est un framework hybride, vous pouvez faire ce compromis vous-même et rester dans le framework.

 // Vous pouvez mettre en cache les pages SSR à la périphérie en utilisant Next.js
// à l'intérieur de getServerSideProps et des routes API
res.setHeader ('Cache-Control', 's-maxage = 60, stale-while-revalidate');

SSR et la mise en cache de périphérie sont similaires à ISR (surtout si vous utilisez les en-têtes de mise en cache stale-while-revalidate ), la principale différence étant la première requête . Avec ISR, la première requête peut être garantie statique si elle est pré-rendue. Même si votre base de données tombe en panne ou s'il y a un problème de communication avec une API, vos utilisateurs verront toujours la page statique correctement diffusée. Cependant, SSR vous permettra de personnaliser votre page en fonction de la demande entrante.

Remarque : L'utilisation de SSR sans mise en cache peut entraîner de mauvaises performances. Chaque milliseconde est importante pour empêcher l'utilisateur de voir votre site, ce qui peut avoir un effet dramatique sur votre TTFB (Time to First Byte).

Static-Site Generation

ISR n'est pas toujours ont du sens pour les petits sites Web. Si votre période de revalidation est plus longue que le temps nécessaire pour reconstruire l'intégralité de votre site, vous pouvez tout aussi bien utiliser la génération de sites statiques traditionnels.

Rendu côté client

Si vous utilisez React sans Next.js, vous êtes en utilisant le rendu côté client. Votre application présente un état de chargement, suivi de la demande de données dans JavaScript côté client (par exemple, useEffect ). Bien que cela augmente vos options d'hébergement (car aucun serveur n'est nécessaire), il existe des compromis.

Le manque de contenu pré-rendu du HTML initial conduit à une optimisation des moteurs de recherche (SEO) plus lente et moins dynamique. Il n’est pas non plus possible d’utiliser CSR avec JavaScript désactivé.

Options de secours ISR

Si vos données peuvent être récupérées rapidement, envisagez d’utiliser fallback: blocking . Ensuite, vous n'avez pas besoin de prendre en compte l'état de chargement et votre page affichera toujours le même résultat (qu'elle soit mise en cache ou non). Si la récupération de vos données est lente, fallback: true vous permet d'afficher immédiatement un état de chargement à l'utilisateur.

ISR: Not Just Caching!

Alors que j'ai expliqué ISR dans le contexte de un cache, il est conçu pour conserver vos pages générées entre les déploiements. Cela signifie que vous pouvez revenir instantanément en arrière et ne pas perdre vos pages précédemment générées.

Chaque déploiement peut être associé à un ID, que Next.js utilise pour conserver les pages générées de manière statique. Lorsque vous revenez en arrière, vous pouvez mettre à jour la clé pour qu'elle pointe vers le déploiement précédent, ce qui permet des déploiements atomiques. Cela signifie que vous pouvez visiter vos déploiements immuables précédents et ils fonctionneront comme prévu.

  • Voici un exemple de retour de code avec ISR:
  • Vous transmettez le code et obtenez un ID de déploiement 123.
  • Votre page contient un typo «Smshng Magazine».
  • Vous mettez à jour la page dans le CMS. Aucun redéploiement nécessaire.
  • Une fois que votre page affiche «Smashing Magazine», elle est conservée dans le stockage.
  • Vous transmettez du mauvais code et déployez l'ID 345.
  • Vous revenez à l'ID de déploiement 123.
  • Vous voyez toujours «Smashing Magazine».

Les retours et les pages statiques persistantes sont hors de portée de Next.js et dépendent de votre fournisseur d'hébergement. Notez que ISR diffère du rendu serveur avec les en-têtes Cache-Control car, de par leur conception, les caches expirent. Ils ne sont pas partagés entre les régions et seront purgés lors du rétablissement.

Exemples de régénération statique incrémentielle

La régénération statique incrémentielle fonctionne bien pour le commerce électronique, les pages marketing, les articles de blog, les médias adossés à des publicités, etc.

  • ] Démo de commerce électronique
    Next.js Commerce est un kit de démarrage tout-en-un pour les sites de commerce électronique haute performance.
  • Démo de réactions GitHub
    Réagissez au GitHub original émettez et regardez ISR mettre à jour la page de destination générée statiquement.
  • Démo de tweets statiques
    Ce projet se déploie en 30 secondes, mais peut générer de manière statique 500 millions de tweets à la demande en utilisant ISR.

Learn Next.js Today

Les développeurs et les grandes équipes choisissent Next.js pour son approche hybride et sa capacité à générer progressivement des pages à la demande. Avec ISR, vous bénéficiez des avantages de la statique avec la flexibilité du rendu sur serveur. ISR est prêt à l'emploi en utilisant next start .

Next.js a été conçu pour adoption progressive . Avec Next.js, vous pouvez continuer à utiliser votre code existant et ajouter autant (ou aussi peu) de React que vous en avez besoin. En commençant petit et en ajoutant progressivement plus de pages, vous pouvez empêcher le travail de fonction de dérailler en évitant une réécriture complète. En savoir plus sur Next.js – et bon codage!

(vf, il)




Source link
Quitter la version mobile