Topics

Notes sur Next.js 16 Cache Component

  • column

Il y a environ six mois, Next.js 16 a été officiellement publié, le 21 octobre 2025.

Le concept de Cache Components a été introduit avec Next.js 16 et permet de contrôler explicitement le cache.

Seul l'emplacement où la directive use cache est écrite est mis en cache, et il est désormais également possible de mettre en cache au niveau du composant avec <Sunpense>.

Puisque nous avons aussi un article à publier, cet article présente principalement l'utilisation des « Cache Components » de Next.js 16, et sert également de notes personnelles !

Les 4 caches de Next.js AppRouter

Dans Next.js AppRouter, il existe quatre types de cache :

  • Request Memoization : Il s'agit de la déduplication des requêtes identiques. Même si plusieurs composants appellent le même fetch, il n'est exécuté qu'une seule fois. Cette fonctionnalité est automatiquement fournie par Next.js.
  • Data Cache : mécanisme permettant de contrôler la mise en cache de l'implémentation via l'option fetch.
  • Full Route Cache : cache au niveau de la page, fonctionnant avec le rendu statique (SSG, ISR). Il s'agit d'un mécanisme qui met en cache côté serveur le payload RSC et le HTML.
  • Router Cache : mécanisme qui met temporairement en cache uniquement le « payload RSC » dans la mémoire du client. Il fonctionne grâce au composant de Next.js.

Nouveauté de Next.js 16 : "use cache"

Nouvelle fonctionnalité Cache Components : ce qu'elle permet désormais de faire.

  • Simplifiez la configuration du cache avec use cache. Seul l'emplacement où use cache est écrit est mis en cache, et le cache peut désormais être contrôlé explicitement.
  • En encapsulant des éléments avec <Suspense>, il est possible de séparer les composants et de définir la mise en cache au niveau de chaque composant.

Jusqu'à Next.js 15, fetch était mis en cache par défaut. Il était difficile de savoir ce qui était ou non mis en cache, ce qui provoquait facilement des mises en cache imprévues.

Comme la mise en cache était automatique, il fallait ajouter fetch(URL, { cache: 'no-store' }) pour la désactiver.

Avec Next.js 16, la mise en cache est désormais activée explicitement en indiquant use cache lorsqu'elle est nécessaire, ce qui rend l'approche nettement plus simple.

Par ailleurs, jusqu'ici, le Data Cache de Next.js ne pouvait être utilisé qu'avec fetch. Il est désormais possible d'appliquer directement un 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 Cache Components dans le fichier next.config.js.

Ce paramètre rend les fonctionnalités de Cache Components disponibles !

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. Pour ne mettre en cache qu'une fonction spécifique, placez-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 l'on n'ajoute pas use cache à la fonction fetch ?

Depuis Next.js 16, il est nécessaire d'ajouter use cache pour mettre en cache. Que se passe-t-il si l'on n'ajoute ni use cache ni l'option cache ?

Si vous définissez cacheComponents: true, une erreur se produit. Pour désactiver intentionnellement le cache, n'utilisez pas fetch(url, { cache: 'no-store' }) ; il suffit de la faire précéder de <Suspense> ! (Avec cacheComponents: false, valeur par défaut, no-store fonctionne comme auparavant.)

Mise en cache au niveau des fonctions

Auparavant, la mise en cache ne pouvait être configurée qu'au niveau des pages. Grâce à use cache, , il est désormais possible de configurer la mise en cache au niveau des composants et des fonctions.

Concrètement, cela permet de combiner rendu statique et rendu dynamique au sein d'une même page. Une diffusion statique rapide et du contenu dynamique peuvent ainsi coexister, ce qui améliore considérablement le temps de chargement initial et l'UX. (Il s'agit de la méthode de rendu PPR.)

Source : Documentation japonaise de Next.js 16

Suspense

Son rôle est de permettre un traitement indépendant de la partie du reste de la page<Suspense>

En encadrant des composants avec <Suspense>, ils peuvent être séparés. Si vous souhaitez mettre en cache au niveau du composant, spécifiez-le dans le composant encadré.

À propos du rendu

La configuration du cache détermine la méthode de rendu.

« Comment souhaitez-vous afficher cette page ou ces données ? » (par exemple, selon la fréquence de mise à jour)

↓

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

↓

Configurer le cache en conséquence

C'est le principe de base.

Il existe aussi plusieurs approches de rendu, mais je les laisse de côté cette fois-ci !


Par exemple,

Dans le cas d'une « page de routage dynamique qui récupère des données depuis microCMS et affiche des articles de blog »

↓

La méthode de rendu optimale est SSG ou ISR (le contenu des articles n'étant pas mis à jour fréquemment)

↓

Avec cache, c'est l'option optimale → ajoutez use cache

et vous pouvez l'implémenter de cette façon.

À titre indicatif, si vous ne définissez pas Cache Components sur true dans le fichier next.config.js, vous pouvez continuer à utiliser l'option cache de fetch comme auparavant.

Conclusion

Lorsque vous configurez le cache, il est important de suivre un processus qui se demande « comment souhaitez-vous que ces données et cette page soient affichées ? » puis d'implémenter les performances optimales adaptées à cette page.

Une fois cette réponse établie, la décision d'utiliser ou non use cache s'impose naturellement.

Beaucoup de gens ont tendance à comprendre le cache, les méthodes de rendu et la récupération de données séparément, mais ici, tout semble se relier !

Il est important de ne pas les considérer comme des concepts séparés, mais comme un seul et même flux !!

Auteur de cet article

Je travaille sur le développement frontend, principalement en balisage, avec JavaScript, React et Next.js. Je suis ravi lorsque les sites auxquels j'ai contribué sont mis en ligne avec succès ! Passionné de guitare, j'aime aussi les chats et les patates douces grillées 🐱🍠

Hiratchi

Ingénieur frontend / Entré en 2022

Voir les articles de cet auteur

Une équipe fiable et une réactivité rapide, qui font notre fierté

Chez Liberogic, nos collaborateurs expérimentés pilotent activement les projets, ce qui vaut à l'entreprise une grande satisfaction de la part de ses clients.
Nous veillons à désigner des chefs de projet et des directeurs de projet qualifiés afin de faire avancer l'ensemble du projet en douceur. Grâce à un modèle d'allocation des ressources au plus juste, évitant une hausse inutile des coûts liée à un engagement à temps plein, nous sommes également reconnus pour la rapidité avec laquelle nous comprenons les besoins et établissons/soumettons les devis.

Remarque : Liberogic ne propose pas de prestations de type SES (mise à disposition de personnel sur site) et vous remercie de bien vouloir en tenir compte.

Nous prenons en charge pratiquement tous les principaux outils de gestion de projet et de messagerie, notamment Slack, Teams, Redmine, Backlog, Asana, Jira, Notion, Google Workspace, Zoom, Webex, etc.

Dans les projets de grande envergure impliquant des SES ou de l'offshore, avez-vous des difficultés techniques ou des questions sur la manière de les aborder ?

Études de cas