Mise en cache dans Next.js

Next.js améliore les performances de votre application et réduit les coûts en mettant en cache le rendu et les requêtes de données. Cette page offre une vue détaillée des mécanismes de mise en cache de Next.js, des API que vous pouvez utiliser pour les configurer et de leur interaction mutuelle.

Bon à savoir : Cette page vous aide à comprendre le fonctionnement interne de Next.js, mais ce n'est pas une connaissance essentielle pour être productif avec Next.js. La plupart des heuristiques de mise en cache de Next.js sont déterminées par votre utilisation des API et ont des valeurs par défaut pour les meilleures performances avec une configuration nulle ou minimale. Si vous préférez passer directement aux exemples, commencez ici.

Aperçu

Voici un aperçu général des différents mécanismes de mise en cache et leur objectif :

Par défaut, Next.js met en cache autant que possible pour améliorer les performances et réduire les coûts. Cela signifie que les routes sont rendues statiquement et les requêtes de données sont mises en cache sauf si vous choisissez de ne pas le faire. Le diagramme ci-dessous montre le comportement de mise en cache par défaut : lorsqu'une route est rendue statiquement au moment de la construction et lorsqu'une route statique est visitée pour la première fois.

Le comportement de mise en cache change selon que la route est rendue statiquement ou dynamiquement, que les données sont mises en cache ou non, et si une requête fait partie d'une visite initiale ou d'une navigation ultérieure. Selon votre cas d'utilisation, vous pouvez configurer le comportement de mise en cache pour des routes et des requêtes de données individuelles.

Mémorisation des requêtes

Next.js étend l'API fetch pour mémoriser automatiquement les requêtes qui ont la même URL et les mêmes options. Cela signifie que vous pouvez appeler une fonction fetch pour les mêmes données à plusieurs endroits dans un arbre de composants React tout en ne l'exécutant qu'une seule fois.

Par exemple, si vous avez besoin d'utiliser les mêmes données dans une route (par exemple dans une mise en page, une page et plusieurs composants), vous n'avez pas besoin de récupérer les données en haut de l'arbre et de les transmettre entre les composants. Au lieu de cela, vous pouvez récupérer les données dans les composants qui en ont besoin sans vous soucier des implications sur les performances de faire plusieurs requêtes réseau pour les mêmes données.

async function getItem() {
  // La fonction `fetch` est automatiquement mémorisée et le résultat
  // est mis en cache
  const res = await fetch('https://.../item/1')
  return res.json()
}

// Cette fonction est appelée deux fois, mais n'est exécutée que la première fois
const item = await getItem() // cache MISS

// Le deuxième appel peut être n'importe où dans votre route
const item = await getItem() // cache HIT

async function getItem() {
  // La fonction `fetch` est automatiquement mémorisée et le résultat
  // est mis en cache
  const res = await fetch('https://.../item/1')
  return res.json()
}

// Cette fonction est appelée deux fois, mais n'est exécutée que la première fois
const item = await getItem() // cache MISS

// Le deuxième appel peut être n'importe où dans votre route
const item = await getItem() // cache HIT

Comment fonctionne la mémorisation des requêtes

• Pendant le rendu d'une route, la première fois qu'une requête particulière est appelée, son résultat ne sera pas en mémoire et ce sera un cache MISS.
• Par conséquent, la fonction sera exécutée, les données seront récupérées depuis la source externe, et le résultat sera stocké en mémoire.
• Les appels ultérieurs de la fonction dans le même passage de rendu seront un cache HIT, et les données seront retournées depuis la mémoire sans exécuter la fonction.
• Une fois que la route a été rendue et que le passage de rendu est terminé, la mémoire est "réinitialisée" et toutes les entrées de mémorisation des requêtes sont effacées.

Bon à savoir :

• La mémorisation des requêtes est une fonctionnalité de React, pas de Next.js. Elle est incluse ici pour montrer comment elle interagit avec les autres mécanismes de mise en cache.
• La mémorisation ne s'applique qu'à la méthode GET dans les requêtes fetch.
• La mémorisation ne s'applique qu'à l'arbre de composants React, ce qui signifie :
  • Elle s'applique aux requêtes fetch dans generateMetadata, generateStaticParams, les mises en page, les pages et autres composants serveur.
  • Elle ne s'applique pas aux requêtes fetch dans les gestionnaires de route car ils ne font pas partie de l'arbre de composants React.
• Pour les cas où fetch n'est pas adapté (par exemple certains clients de base de données, CMS ou GraphQL), vous pouvez utiliser la fonction cache de React pour mémoriser les fonctions.

Durée

Le cache dure le temps de vie d'une requête serveur jusqu'à ce que l'arbre de composants React ait fini de rendre.

Revalidation

Comme la mémorisation n'est pas partagée entre les requêtes serveur et ne s'applique que pendant le rendu, il n'est pas nécessaire de la revalider.

Désactivation

La mémorisation ne s'applique qu'à la méthode GET dans les requêtes fetch, les autres méthodes comme POST et DELETE ne sont pas mémorisées. Ce comportement par défaut est une optimisation de React et nous ne recommandons pas de le désactiver.

Pour gérer des requêtes individuelles, vous pouvez utiliser la propriété signal de AbortController. Cependant, cela ne désactivera pas la mémorisation des requêtes, mais annulera plutôt les requêtes en cours.

const { signal } = new AbortController()
fetch(url, { signal })

Cache de données

Next.js a un cache de données intégré qui persiste le résultat des récupérations de données entre les requêtes serveur entrantes et les déploiements. Cela est possible car Next.js étend l'API native fetch pour permettre à chaque requête sur le serveur de définir sa propre sémantique de mise en cache persistante.

Bon à savoir : Dans le navigateur, l'option cache de fetch indique comment une requête interagit avec le cache HTTP du navigateur. Dans Next.js, l'option cache indique comment une requête côté serveur interagit avec le cache de données du serveur.

Vous pouvez utiliser les options cache et next.revalidate de fetch pour configurer le comportement de mise en cache.

Comment fonctionne le cache de données

• La première fois qu'une requête fetch avec l'option 'force-cache' est appelée pendant le rendu, Next.js vérifie le cache de données pour une réponse mise en cache.
• Si une réponse mise en cache est trouvée, elle est retournée immédiatement et mémorisée.
• Si aucune réponse mise en cache n'est trouvée, la requête est faite vers la source de données, le résultat est stocké dans le cache de données et mémorisé.
• Pour les données non mises en cache (par exemple sans option cache définie ou avec { cache: 'no-store' }), le résultat est toujours récupéré depuis la source de données et mémorisé.
• Que les données soient mises en cache ou non, les requêtes sont toujours mémorisées pour éviter de faire des requêtes en double pour les mêmes données pendant un passage de rendu React.

Différences entre le cache de données et la mémorisation des requêtes

Bien que les deux mécanismes de mise en cache aident à améliorer les performances en réutilisant les données mises en cache, le cache de données est persistant entre les requêtes entrantes et les déploiements, tandis que la mémorisation ne dure que le temps de vie d'une requête.

Durée

Le cache de données est persistant entre les requêtes entrantes et les déploiements, sauf si vous le revalidez ou le désactivez.

Revalidation

Les données mises en cache peuvent être revalidées de deux manières, avec :

• Revalidation basée sur le temps : Revalider les données après un certain temps écoulé et une nouvelle requête effectuée. C'est utile pour les données qui changent rarement et où la fraîcheur n'est pas critique.
• Revalidation à la demande : Revalider les données en fonction d'un événement (par exemple une soumission de formulaire). La revalidation à la demande peut utiliser une approche basée sur des tags ou des chemins pour revalider des groupes de données à la fois. C'est utile lorsque vous voulez vous assurer que les données les plus récentes sont affichées dès que possible (par exemple lorsque le contenu de votre CMS headless est mis à jour).

Revalidation basée sur le temps

Pour revalider les données à intervalles réguliers, vous pouvez utiliser l'option next.revalidate de fetch pour définir la durée de vie du cache d'une ressource (en secondes).

// Revalider au maximum toutes les heures
fetch('https://...', { next: { revalidate: 3600 } })

Alternativement, vous pouvez utiliser les options de configuration de segment de route pour configurer toutes les requêtes fetch dans un segment ou pour les cas où vous ne pouvez pas utiliser fetch.

Comment fonctionne la revalidation basée sur le temps

• La première fois qu'une requête fetch avec revalidate est appelée, les données seront récupérées depuis la source de données externe et stockées dans le cache de données.
• Toutes les requêtes appelées dans l'intervalle spécifié (par exemple 60 secondes) retourneront les données mises en cache.
• Après l'intervalle, la prochaine requête retournera toujours les données mises en cache (maintenant périmées).
  • Next.js déclenchera une revalidation des données en arrière-plan.
  • Une fois les données récupérées avec succès, Next.js mettra à jour le cache de données avec les nouvelles données.
  • Si la revalidation en arrière-plan échoue, les données précédentes seront conservées inchangées.

Cela est similaire au comportement stale-while-revalidate.

Revalidation à la demande

Les données peuvent être revalidées à la demande par chemin (revalidatePath) ou par tag de cache (revalidateTag).

Comment fonctionne la revalidation à la demande

• La première fois qu'une requête fetch est appelée, les données seront récupérées depuis la source de données externe et stockées dans le cache de données.
• Lorsqu'une revalidation à la demande est déclenchée, les entrées de cache appropriées seront purgées du cache.
  • Cela diffère de la revalidation basée sur le temps, qui conserve les données périmées dans le cache jusqu'à ce que les nouvelles données soient récupérées.
• La prochaine fois qu'une requête sera faite, ce sera à nouveau un cache MISS, et les données seront récupérées depuis la source de données externe et stockées dans le cache de données.

Désactivation

Si vous ne voulez pas mettre en cache la réponse de fetch, vous pouvez faire ce qui suit :

let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' })

Cache complet de route

Termes associés :

Vous pouvez voir les termes Optimisation statique automatique, Génération de site statique ou Rendu statique utilisés de manière interchangeable pour désigner le processus de rendu et de mise en cache des routes de votre application au moment de la construction.

Next.js rend et met en cache automatiquement les routes au moment de la construction. C'est une optimisation qui vous permet de servir la route mise en cache au lieu de la rendre sur le serveur pour chaque requête, ce qui résulte en des chargements de page plus rapides.

Pour comprendre comment fonctionne le cache complet de route, il est utile de regarder comment React gère le rendu et comment Next.js met en cache le résultat :

1. Rendu React sur le serveur

Sur le serveur, Next.js utilise les API de React pour orchestrer le rendu. Le travail de rendu est divisé en morceaux : par segments de route individuels et limites Suspense.

Chaque morceau est rendu en deux étapes :

1. React rend les composants serveur dans un format de données spécial, optimisé pour le streaming, appelé React Server Component Payload.
2. Next.js utilise le React Server Component Payload et les instructions JavaScript des composants client pour rendre le HTML sur le serveur.

Cela signifie que nous n'avons pas besoin d'attendre que tout soit rendu avant de mettre en cache le travail ou d'envoyer une réponse. Au lieu de cela, nous pouvons diffuser une réponse au fur et à mesure que le travail est terminé.

Qu'est-ce que le React Server Component Payload ?

Le React Server Component Payload est une représentation binaire compacte de l'arbre des composants serveur rendus. Il est utilisé par React côté client pour mettre à jour le DOM du navigateur. Le React Server Component Payload contient :

• Le résultat rendu des composants serveur
• Des espaces réservés pour les composants client qui doivent être rendus et des références à leurs fichiers JavaScript
• Toutes les props passées d'un composant serveur à un composant client

Pour en savoir plus, consultez la documentation des composants serveur.

2. Mise en cache Next.js sur le serveur (Cache complet de route)

Le comportement par défaut de Next.js est de mettre en cache le résultat rendu (React Server Component Payload et HTML) d'une route sur le serveur. Cela s'applique aux routes rendues statiquement au moment de la construction ou pendant la revalidation.

3. Hydratation et réconciliation React côté client

Au moment de la requête, côté client :

1. Le HTML est utilisé pour afficher immédiatement un aperçu initial rapide et non interactif des composants client et serveur.
2. Le React Server Components Payload est utilisé pour réconcilier les arbres des composants client et serveur rendus, et mettre à jour le DOM.
3. Les instructions JavaScript sont utilisées pour hydrater les composants client et rendre l'application interactive.

4. Mise en cache Next.js côté client (Cache du routeur)

Le React Server Component Payload est stocké dans le Cache du routeur côté client - un cache en mémoire séparé, divisé par segments de route individuels. Ce cache du routeur est utilisé pour améliorer l'expérience de navigation en stockant les routes précédemment visitées et en préchargeant les routes futures.

5. Navigations ultérieures

Lors des navigations ultérieures ou pendant le préchargement, Next.js vérifiera si le React Server Components Payload est stocké dans le cache du routeur. Si c'est le cas, il évitera d'envoyer une nouvelle requête au serveur.

Si les segments de route ne sont pas dans le cache, Next.js récupérera le React Server Components Payload depuis le serveur et peuplera le cache du routeur côté client.

Rendu statique et dynamique

Le fait qu'une route soit mise en cache ou non au moment de la construction dépend de son rendu statique ou dynamique. Les routes statiques sont mises en cache par défaut, tandis que les routes dynamiques sont rendues au moment de la requête et ne sont pas mises en cache.

Ce diagramme illustre la différence entre les routes rendues statiquement et dynamiquement, avec des données mises en cache ou non :

En savoir plus sur le rendu statique et dynamique.

Durée

Par défaut, le cache complet de route est persistant. Cela signifie que le résultat du rendu est mis en cache entre les requêtes des utilisateurs.

Invalidation

Il existe deux façons d'invalider le cache complet de route :

• Revalidation des données : Revalider le cache de données invalidera à son tour le cache de route en re-rendant les composants côté serveur et en mettant en cache le nouveau résultat de rendu.
• Redéploiement : Contrairement au cache de données, qui persiste entre les déploiements, le cache complet de route est effacé lors de nouveaux déploiements.

Désactivation

Vous pouvez désactiver le cache complet de route, c'est-à-dire rendre dynamiquement les composants pour chaque requête entrante, en :

• Utilisant une API dynamique : Cela exclura la route du cache complet de route et la rendra dynamiquement au moment de la requête. Le cache de données peut toujours être utilisé.
• Utilisant les options de configuration de segment de route dynamic = 'force-dynamic' ou revalidate = 0 : Cela ignorera le cache complet de route et le cache de données. Les composants seront rendus et les données récupérées à chaque requête entrante vers le serveur. Le cache de routeur s'appliquera toujours car il s'agit d'un cache côté client.
• Désactivant le cache de données : Si une route a une requête fetch qui n'est pas mise en cache, cela exclura la route du cache complet de route. Les données pour la requête fetch spécifique seront récupérées pour chaque requête entrante. Les autres requêtes fetch qui ne désactivent pas la mise en cache seront toujours mises en cache dans le cache de données. Cela permet un mélange de données mises en cache et non mises en cache.

Cache de routeur côté client

Next.js dispose d'un cache de routeur côté client en mémoire qui stocke la charge utile RSC des segments de route, divisés par les mises en page, les états de chargement et les pages.

Lorsqu'un utilisateur navigue entre les routes, Next.js met en cache les segments de route visités et précharge les routes vers lesquelles l'utilisateur est susceptible de naviguer. Cela permet une navigation instantanée avant/arrière, pas de rechargement complet de page entre les navigations, et la préservation de l'état React et de l'état du navigateur.

Avec le cache de routeur :

• Les mises en page sont mises en cache et réutilisées lors de la navigation (rendu partiel).
• Les états de chargement sont mis en cache et réutilisés lors de la navigation pour une navigation instantanée.
• Les pages ne sont pas mises en cache par défaut, mais sont réutilisées lors de la navigation avant/arrière dans le navigateur. Vous pouvez activer la mise en cache pour les segments de page en utilisant l'option expérimentale staleTimes.

Bon à savoir : Ce cache s'applique spécifiquement à Next.js et aux composants serveur, et est différent du bfcache du navigateur, bien qu'il ait un résultat similaire.

Durée

Le cache est stocké dans la mémoire temporaire du navigateur. Deux facteurs déterminent la durée de vie du cache de routeur :

• Session : Le cache persiste entre les navigations. Cependant, il est effacé lors du rafraîchissement de la page.
• Période d'invalidation automatique : Le cache des mises en page et des états de chargement est automatiquement invalidé après un certain temps. La durée dépend de la façon dont la ressource a été préchargée, et si la ressource a été générée statiquement :
  • Préchargement par défaut (prefetch={null} ou non spécifié) : non mis en cache pour les pages dynamiques, 5 minutes pour les pages statiques.
  • Préchargement complet (prefetch={true} ou router.prefetch) : 5 minutes pour les pages statiques et dynamiques.

Bien qu'un rafraîchissement de page efface tous les segments mis en cache, la période d'invalidation automatique n'affecte que le segment individuel à partir du moment où il a été préchargé.

Bon à savoir : L'option expérimentale staleTimes peut être utilisée pour ajuster les temps d'invalidation automatique mentionnés ci-dessus.

Invalidation

Il existe deux façons d'invalider le cache de routeur :

• Dans une action serveur :
  • Revalider les données à la demande par chemin avec (revalidatePath) ou par étiquette de cache avec (revalidateTag)
  • Utiliser cookies.set ou cookies.delete invalide le cache de routeur pour empêcher les routes utilisant des cookies de devenir obsolètes (par exemple, l'authentification).
• Appeler router.refresh invalidera le cache de routeur et fera une nouvelle requête au serveur pour la route actuelle.

Désactivation

Depuis Next.js 15, les segments de page sont désactivés par défaut.

Bon à savoir : Vous pouvez également désactiver le préchargement en définissant la propriété prefetch du composant <Link> sur false.

Interactions entre les caches

Lors de la configuration des différents mécanismes de mise en cache, il est important de comprendre comment ils interagissent entre eux :

Cache de données et cache complet de route

• Revalider ou désactiver le cache de données invalidera le cache complet de route, car le résultat du rendu dépend des données.
• Invalider ou désactiver le cache complet de route n'affecte pas le cache de données. Vous pouvez rendre dynamiquement une route qui a à la fois des données mises en cache et non mises en cache. Cela est utile lorsque la plupart de votre page utilise des données mises en cache, mais que vous avez quelques composants qui dépendent de données devant être récupérées au moment de la requête. Vous pouvez effectuer un rendu dynamique sans vous soucier de l'impact sur les performances de la récupération de toutes les données.

Cache de données et cache de routeur côté client

• Pour invalider immédiatement le cache de données et le cache de routeur, vous pouvez utiliser revalidatePath ou revalidateTag dans une action serveur.
• Revalider le cache de données dans un gestionnaire de route n'invalidera pas immédiatement le cache de routeur car le gestionnaire de route n'est pas lié à une route spécifique. Cela signifie que le cache de routeur continuera à servir la charge utile précédente jusqu'à un rafraîchissement complet ou jusqu'à l'expiration de la période d'invalidation automatique.

APIs

Le tableau suivant donne un aperçu de la façon dont les différentes APIs Next.js affectent la mise en cache :

<Link>

Par défaut, le composant <Link> précharge automatiquement les routes depuis le cache complet de route et ajoute la charge utile du composant serveur React au cache de routeur.

Pour désactiver le préchargement, vous pouvez définir la propriété prefetch sur false. Mais cela ne désactivera pas le cache de façon permanente, le segment de route sera toujours mis en cache côté client lorsque l'utilisateur visitera la route.

En savoir plus sur le composant <Link>.

router.prefetch

L'option prefetch du hook useRouter peut être utilisée pour précharger manuellement une route. Cela ajoute la charge utile du composant serveur React au cache de routeur.

Voir la référence de l'API du hook useRouter.

router.refresh

L'option refresh du hook useRouter peut être utilisée pour rafraîchir manuellement une route. Cela efface complètement le cache de routeur et effectue une nouvelle requête au serveur pour la route actuelle. refresh n'affecte pas le cache de données ou le cache complet de route.

Le résultat rendu sera réconcilié côté client tout en préservant l'état React et l'état du navigateur.

Voir la référence de l'API du hook useRouter.

fetch

Les données retournées par fetch ne sont pas automatiquement mises en cache dans le cache de données.

Le comportement de mise en cache par défaut de fetch (par exemple, lorsque l'option cache n'est pas spécifiée) est équivalent à définir l'option cache sur no-store :

let data = await fetch('https://api.vercel.app/blog', { cache: 'no-store' })

Voir la référence de l'API fetch pour plus d'options.

fetch options.cache

Vous pouvez activer la mise en cache pour une requête fetch individuelle en définissant l'option cache sur force-cache :

// Activer la mise en cache
fetch(`https://...`, { cache: 'force-cache' })

Voir la référence de l'API fetch pour plus d'options.

fetch options.next.revalidate

Vous pouvez utiliser l'option next.revalidate de fetch pour définir la période de revalidation (en secondes) d'une requête fetch individuelle. Cela revalidera le cache de données, ce qui à son tour revalidera le cache complet de route. Les nouvelles données seront récupérées et les composants seront re-rendus côté serveur.

// Revalider au maximum après 1 heure
fetch(`https://...`, { next: { revalidate: 3600 } })

Voir la référence de l'API fetch pour plus d'options.

fetch options.next.tags et revalidateTag

Next.js dispose d'un système d'étiquetage de cache pour une mise en cache et une revalidation fine des données.

1. Lors de l'utilisation de fetch ou unstable_cache, vous avez la possibilité d'étiqueter les entrées de cache avec une ou plusieurs étiquettes.
2. Ensuite, vous pouvez appeler revalidateTag pour purger les entrées de cache associées à cette étiquette.

Par exemple, vous pouvez définir une étiquette lors de la récupération des données :

// Mettre en cache les données avec une étiquette
fetch(`https://...`, { next: { tags: ['a', 'b', 'c'] } })

Puis, appeler revalidateTag avec une étiquette pour purger l'entrée de cache :

// Revalider les entrées avec une étiquette spécifique
revalidateTag('a')

Il existe deux endroits où vous pouvez utiliser revalidateTag, selon ce que vous essayez d'accomplir :

1. Gestionnaires de route - pour revalider les données en réponse à un événement tiers (par exemple un webhook). Cela n'invalidera pas immédiatement le cache de routeur car le gestionnaire de route n'est pas lié à une route spécifique.
2. Actions serveur - pour revalider les données après une action utilisateur (par exemple la soumission d'un formulaire). Cela invalidera le cache de routeur pour la route associée.

revalidatePath

revalidatePath vous permet de revalider manuellement les données et de re-rendre les segments de route sous un chemin spécifique en une seule opération. Appeler la méthode revalidatePath revalide le cache de données, ce qui à son tour invalide le cache complet de route.

revalidatePath('/')

Il existe deux endroits où vous pouvez utiliser revalidatePath, selon ce que vous essayez d'accomplir :

1. Gestionnaires de route - pour revalider les données en réponse à un événement tiers (par exemple un webhook).
2. Actions serveur - pour revalider les données après une interaction utilisateur (par exemple la soumission d'un formulaire, le clic sur un bouton).

Voir la référence de l'API revalidatePath pour plus d'informations.

revalidatePath vs. router.refresh :

Appeler router.refresh effacera le cache de routeur et re-rendra les segments de route côté serveur sans invalider le cache de données ou le cache complet de route.

La différence est que revalidatePath purge le cache de données et le cache complet de route, tandis que router.refresh() ne modifie pas le cache de données et le cache complet de route, car il s'agit d'une API côté client.

APIs dynamiques

Les APIs dynamiques comme cookies et headers, ainsi que la propriété searchParams dans les Pages dépendent des informations de requête entrante en temps réel. Leur utilisation exclura une route du cache complet de route, c'est-à-dire que la route sera rendue dynamiquement.

cookies

L'utilisation de cookies.set ou cookies.delete dans une action serveur invalide le cache de routeur pour empêcher les routes utilisant des cookies de devenir obsolètes (par exemple pour refléter les changements d'authentification).

Voir la référence de l'API cookies.

Options de configuration des segments

Les options de configuration des segments de route peuvent être utilisées pour remplacer les valeurs par défaut du segment de route ou lorsque vous ne pouvez pas utiliser l'API fetch (par exemple, avec un client de base de données ou des bibliothèques tierces).

Les options de configuration de segment de route suivantes désactiveront le cache complet de route :

• const dynamic = 'force-dynamic'

Cette option de configuration désactivera le cache de données pour toutes les requêtes (c'est-à-dire no-store) :

• const fetchCache = 'default-no-store'

Consultez fetchCache pour voir des options plus avancées.

Consultez la documentation Configuration des segments de route pour plus d'options.

generateStaticParams

Pour les segments dynamiques (par exemple app/blog/[slug]/page.js), les chemins fournis par generateStaticParams sont mis en cache dans le cache complet de route au moment de la construction. Au moment de la requête, Next.js mettra également en cache les chemins qui n'étaient pas connus au moment de la construction lors de leur première visite.

Pour rendre statiquement tous les chemins au moment de la construction, fournissez la liste complète des chemins à generateStaticParams :

export async function generateStaticParams() {
  const posts = await fetch('https://.../posts').then((res) => res.json())

  return posts.map((post) => ({
    slug: post.slug,
  }))
}

Pour rendre statiquement un sous-ensemble de chemins au moment de la construction, et le reste lors de leur première visite au moment de l'exécution, retournez une liste partielle de chemins :

export async function generateStaticParams() {
  const posts = await fetch('https://.../posts').then((res) => res.json())

  // Rendre les 10 premiers articles au moment de la construction
  return posts.slice(0, 10).map((post) => ({
    slug: post.slug,
  }))
}

Pour rendre statiquement tous les chemins lors de leur première visite, retournez un tableau vide (aucun chemin ne sera rendu au moment de la construction) ou utilisez export const dynamic = 'force-static' :

export async function generateStaticParams() {
  return []
}

Bon à savoir : Vous devez retourner un tableau depuis generateStaticParams, même s'il est vide. Sinon, la route sera rendue dynamiquement.

export const dynamic = 'force-static'

Pour désactiver la mise en cache au moment de la requête, ajoutez l'option export const dynamicParams = false dans un segment de route. Lorsque cette option de configuration est utilisée, seuls les chemins fournis par generateStaticParams seront servis, et les autres routes renverront une erreur 404 ou correspondront (dans le cas des routes catch-all).

Fonction cache de React

La fonction cache de React vous permet de mémoriser la valeur de retour d'une fonction, vous permettant d'appeler la même fonction plusieurs fois tout en ne l'exécutant qu'une seule fois.

Comme les requêtes fetch sont automatiquement mémorisées, vous n'avez pas besoin de les encapsuler dans cache de React. Cependant, vous pouvez utiliser cache pour mémoriser manuellement les requêtes de données dans les cas où l'API fetch n'est pas adaptée. Par exemple, certains clients de base de données, clients CMS ou clients GraphQL.

import { cache } from 'react'
import db from '@/lib/db'

export const getItem = cache(async (id: string) => {
  const item = await db.item.findUnique({ id })
  return item
})

import { cache } from 'react'
import db from '@/lib/db'

export const getItem = cache(async (id) => {
  const item = await db.item.findUnique({ id })
  return item
})