Mémo sur Next.js 16 Cache Component

C'était il y a environ six mois, mais Next.js 16 a été officiellement publié le 21 octobre 2025.

Le concept de Cache Components lui-même a été introduit avec Next.js 16, et le cache peut désormais être contrôlé explicitement.

Seul l'endroit où la directive use cache est écrite est mis en cache, et il est aussi possible d'utiliser pour mettre en cache au niveau du composant.

Eh bien, comme il y a aussi des articles publiés, je vais cette fois résumer l'utilisation de « Cache Components » de Next.js 16 et en faire aussi un mémo !

Les 4 types de cache du routeur App Next.js

Il existe 4 types de cache dans le routeur App Next.js.

• Request Memoization : C'est la déduplication des demandes identiques. Même si le même fetch est appelé dans différents composants, il n'est exécuté qu'une seule fois. C'est une fonctionnalité que Next.js gère automatiquement.
• Data Cache : contrôle la mise en œuvre du cache via l'option fetch.
• Full Route Cache : cache au niveau de la page fonctionnant avec le rendu statique (SSG, ISR). Mécanisme de mise en cache côté serveur du payload RSC et du HTML.
• Router Cache : mécanisme de mise en cache temporaire du payload RSC uniquement en mémoire côté client. Fonctionne avec l'utilisation du composant de Next.js.

Nouvelle fonctionnalité de Next.js 16 : "use cache"

À propos de la nouvelle fonctionnalité Cache Components : ce qui devient possible.

• Utiliser use cache pour simplifier la configuration du cache. Seul l'endroit où use cache est écrit est mis en cache, ce qui permet un contrôle explicite du cache.
• En enveloppant avec , il est possible de séparer les composants et de spécifier le cache au niveau du composant.

Avec Next.js 15 et les versions antérieures, fetch était mis en cache par défaut, ce qui rendait difficile la compréhension de quels emplacements étaient mis en cache ou non, rendant les mises en cache inattendues faciles à survenir.

Étant mis en cache automatiquement par défaut, il était nécessaire d'ajouter fetch(URL, { cache: 'no-store' }) pour l'invalider.

En revanche, Next.js 16 change l'approche en spécifiant use cache lorsque le cache est nécessaire, ce qui crée une méthode explicite et simple.

Auparavant, le cache de données de Next.js ne pouvait être utilisé que via fetch, mais il est maintenant possible d'appliquer directement le cache aux fonctions asynchrones qui n'utilisent pas fetch, comme les requêtes de base de données.

Méthode d'implémentation

Vous devez activer les Cache Components dans le fichier next.config.js.

Avec cette configuration, la fonctionnalité des Cache Components devient disponible !

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  cacheComponents: true,
};

export default nextConfig;

Ajoutez la directive use cache au début du composant que vous souhaitez mettre en cache. Si vous souhaitez mettre en cache une fonction spécifique uniquement, écrivez-la à l'intérieur de cette fonction.

'use cache'

async function getPosts() {
  const res = await fetch('<https://api.example.com/posts>')
  return res.json()
}

export default async function PostList() {
  const posts = await getPosts()
  return (
    <ul>
      {posts.map(post => <li>{post.title}</li>)}
    </ul>
  )
}

Que se passe-t-il si je n'ajoute pas use cache à la fonction fetch ?

À partir de Next.js 16, il est nécessaire d'ajouter use cache pour mettre en cache, mais que se passe-t-il si ni use cache ni l'option cache ne sont appliqués ?

Si vous configurez cacheComponents: true, une erreur se produira. Pour désactiver intentionnellement le cache, n'utilisez pas fetch(url, { cache: 'no-store' }), mais enveloppez simplement avec ! (Si cacheComponents: false (par défaut), vous pouvez utiliser no-store comme avant)

Mise en cache au niveau des fonctions

Auparavant, seules les spécifications de cache au niveau des pages étaient possibles, mais grâce à use cache, , il est maintenant possible de configurer le cache au niveau des composants et des fonctions.

L'avantage réside dans la possibilité de combiner le rendu statique et le rendu dynamique au sein d'une même page, permettant la coexistence d'une distribution statique rapide et de contenu dynamique. Cela améliore considérablement la vitesse de chargement initiale et l'UX. (PPR, une technique de rendu)

Suspense

Le rôle de est de traiter individuellement les composants en les isolant du reste de la page.

En englobant un composant avec , vous pouvez le séparer. Si vous souhaitez mettre en cache par unité de composant, spécifiez-le à l'intérieur du composant englobé.

À propos du rendu

La méthode de rendu est déterminée par la configuration du cache.

« Comment voulez-vous présenter cette page/ces données ? » (fréquence de mise à jour, etc.)

↓

Déterminer la méthode de rendu (SSG / ISR / SSR / PPR / CSR)

↓

Configurer le cache en conséquence

C'est cette approche.

Il existe plusieurs modèles de rendu, mais nous allons les laisser de côté cette fois-ci !

Par exemple,

« Une page de routage dynamique qui récupère les données de microCMS et affiche les articles de blog »

↓

SSG ou ISR est optimal pour la méthode de rendu (puisque le contenu des articles n'est pas mis à jour fréquemment)

↓

La mise en cache est optimale → ajouter use cache

voilà comment on peut l'implémenter.

À propos, si vous ne définissez pas Cache Components à true dans le fichier next.config.js, vous pouvez continuer à utiliser l'option cache de fetch de la manière habituelle.

Conclusion

Lorsque vous réfléchissez à la configuration du cache, il est important de suivre le processus suivant : « Comment veux-je afficher ces données et cette page ? » puis implémenter les performances optimales en fonction de cette page.

Une fois que vous avez trouvé la réponse, il devient naturel de décider si vous devez utiliser use cache ou non.

Je pense que beaucoup de gens comprennent séparément le cache, les méthodes de rendu et la récupération de données, mais tout est connecté !

Il est important de les considérer non pas comme des concepts distincts, mais comme un seul flux !