Articlepar DevBlog

use cache et cacheComponents en pratique

Ce que change cacheComponents dans Next.js 16 : prérendu, cacheLife, et les pièges rencontrés en construisant ce blog (Date.now dans Shiki, soft 404).

  • #nextjs
  • #cache
  • #performance
  • #react

Le principe

Avec cacheComponents activé, Next.js 16 prérend ce qu'il peut et vous demande de dire explicitement ce qui est mis en cache. La directive "use cache" marque une fonction ou un composant dont le résultat peut être conservé et réutilisé.

typescript
import { cacheLife } from "next/cache";

export async function getSummaries() {
  "use cache";
  cacheLife("max");

  // lecture des fichiers Markdown
}

Ici, le contenu ne change qu'au build : on peut le garder très longtemps. cacheLife("max") porte la revalidation à 30 jours, contre 15 minutes par défaut.

Ce qui est prérendu

Le résultat est visible dans la table des routes après npm run build :

SymboleSignification
○Entièrement statique
◐Prérendu partiel (coque statique, reste dynamique)
ƒRendu à la demande

Une route de contenu qui passe de ○ à ◐ ou ƒ est une régression : vérifiez-le à chaque build.

Piège n°1 : l'heure courante

Dans ce mode, lire new Date() ou Date.now() en dehors d'un "use cache" bloque le prérendu. Le piège est discret : Shiki lit l'heure en interne pour sa coloration syntaxique.

La solution est d'envelopper l'appel dans une fonction mise en cache :

typescript
async function highlight(code: string, lang: string) {
  "use cache";
  cacheLife("max");
  return codeToHtml(code, { lang, themes: { dark: "...", light: "..." } });
}

Piège n°2 : le soft 404

La route d'un article est prérendue en partie (◐). Pour un slug inconnu, Next streame alors la page « introuvable »… avec un statut 200. Les moteurs de recherche y voient une vraie page.

La parade : un proxy.ts qui vérifie l'existence du contenu et renvoie un vrai 404 avant le rendu.

Piège n°3 : dynamicParams

Avec cacheComponents, l'option dynamicParams est interdite. Vous décrivez les chemins connus dans generateStaticParams, et le reste est géré en amont (voir le point précédent).

Bonnes pratiques

  • Mettez en cache au niveau des lecteurs de données plutôt qu'à l'échelle de la page.
  • Donnez une durée de vie explicite avec cacheLife.
  • Gardez un œil sur la table des routes.
  • Testez les cas limites (slug inconnu, majuscules, caractères encodés).

À retenir

"use cache" rend le modèle explicite : ce qui est mis en cache est écrit dans le code, et non plus deviné par le framework. C'est plus de rigueur, mais des pages prérendues rapides et prévisibles.