Next.js 16.4 : Cache Components devient la norme

Next.js 16.4 : Cache Components devient la norme

Pourquoi cette version compte pour les sites vitrine et e-commerce

Depuis la série 16.x, Next.js pousse un nouveau modèle de programmation pour l'App Router. Il promet trois choses : un chargement initial rapide, même pour des pages personnalisées, des navigations clientes instantanées, et un cache opt-in, déclaratif et composable.

Jusqu'ici, Next.js ne le recommandait pas universellement, car certains cas ne tenaient pas les mêmes garanties de coût et de performance que l'ancien modèle. La version 16.4 comble ces écarts. Concrètement, Next.js annonce que Cache Components est désormais la meilleure option pour chaque application, et que ce sera le comportement par défaut dans Next.js 17.

Pour une équipe qui livre un site vitrine, une boutique ou un blog, c'est le signal à prendre au sérieux : les choix d'architecture faits aujourd'hui vont devenir la norme.

Ce que fait 'use cache'

La directive 'use cache' s'applique au niveau du composant. Vous pouvez la voir comme l'équivalent, côté composant, de l'en-tête HTTP Cache-Control.

import { cacheLife } from 'next/cache';

export default async function DashboardPage() {
  const currentUser = await getCurrentUser(); // rendu à la requête

  return (
    <div>
      <p>Bienvenue, {currentUser.name}</p>

      <Suspense fallback={<Loading />}>
        <Projects userId={currentUser.id} />
      </Suspense>
    </div>
  );
}

async function Projects({ userId }) {
  'use cache';
  cacheLife('hours'); // le résultat est mis en cache pendant quelques heures

  const projects = await db.query.projects.findMany({
    where: eq(projectsTable.userId, userId),
  });

  return (
    <div>
      {projects.map((project) => (
        <p key={project.id}>{project.name}</p>
      ))}
    </div>
  );
}

Next.js interprète ces annotations au moment du rendu. Il met en cache l'interface du composant dans le navigateur lors des navigations clientes, et éventuellement côté serveur, pendant le rendu ou en amont, au moment du build. Une même page peut donc mélanger cache client, cache serveur pluggable et rendu à la requête, sans configuration globale.

Activer le modèle dans votre projet

Le modèle s'active avec deux flags dans la configuration Next.js :

// next.config.ts
import type { NextConfig } from 'next';

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

export default nextConfig;

partialPrefetching n'était pas inclus à la première sortie de Cache Components, mais il fait désormais partie du modèle. Il limite le préchargement par défaut à un shell par route, puis charge le reste à la demande. Si vous avez lu notre article sur Next.js 16.3 et les Instant Navigations, c'est la suite logique.

ensureStatic : verrouiller ce qui doit rester statique

C'est la nouveauté la plus utile pour un site vitrine ou une boutique. Un composant dynamique glissé par erreur dans une page marketing peut dégrader les performances et les coûts sans qu'on s'en aperçoive. Avec ensureStatic, Next.js refuse de compiler la route.

// app/blog/[slug]/page.tsx
export const ensureStatic = 'navigation';

export default function Page() {
  return (
    <>
      <UserAvatar /> {/* ce composant fait échouer le build */}
      <Content />
    </>
  );
}

async function UserAvatar() {
  const currentUser = await getCurrentUser(); // rendu à la requête
  // ...
}

async function Content() {
  'use cache';
  await fetch('...');
  // ...
}

Trois niveaux sont disponibles :

Vous pouvez aussi poser ensureStatic sur un layout, par exemple 'navigation' sur le layout racine, pour appliquer la règle à tout le site, puis la redescendre dans les layouts qui ont réellement besoin de dynamique. Pour une équipe qui livre plusieurs sites, c'est un garde-fou simple à mettre en place dès le départ.

Maîtriser le préchargement avec navigation() et prefetch()

Le préchargement (<Link prefetch>) supprime les écrans de chargement, mais il peut aussi charger trop de données. Prenons une liste de messages : précharger chaque lien revient à charger tous les fils de discussion, même ceux que personne n'ouvrira.

Next.js 16.4 ajoute deux APIs pour arbitrer ce compromis :

• navigation() exclut un composant du préchargement. Il n'est rendu que lors d'une navigation complète.
• prefetch() fait l'inverse pour un contenu qui serait sinon inclus dans le shell : son rendu est reporté jusqu'à un préchargement explicite.

Le principe est de précharger le strict nécessaire et de charger le reste au clic. Sur un catalogue e-commerce, cela permet par exemple de précharger la fiche produit sans charger tous les avis clients avant que l'utilisateur ne s'y intéresse.

Ce qui change pour toutes les apps, même sans Cache Components

Certaines améliorations s'appliquent sans modifier votre code :

• Cache disque Turbopack : réduit de 20 à 25 % selon Next.js, grâce à la compression Zstandard sur les données volumineuses.
• HMR serveur paresseux : en développement, les modules serveur ne sont recompilés que lorsqu'une requête en a besoin. Moins de travail en arrière-plan quand vous naviguez dans l'app.
• Runtime Turbopack partagé : le runtime est livré dans un seul chunk commun à toutes les routes, ce qui réduit les téléchargements et améliore le taux de cache.
• Bundles de production plus petits : noms de classes CSS Modules raccourcis et mangling des exports internes. Les noms longs sont conservés en développement pour faciliter le débogage.

Next.js 16.4 embarque aussi React 19.3, avec les View Transitions désormais stables. Pour une interface avec des transitions soignées entre pages, c'est une bonne nouvelle côté UX.

Migrer avec un agent IA

Next.js ajoute une commande pensée pour les agents de code :

npx next@canary upgrade --agent=latest

Elle identifie la version installée, choisit la cible, prépare les guides de migration, les codemods éventuels et les étapes de vérification. L'agent applique la mise à jour, résout les problèmes de migration et vérifie que l'application fonctionne encore.

La version 16.4 introduit aussi experimental.agentUpgrade : pendant next dev ou next build, Next.js signale automatiquement qu'une mise à jour pertinente est disponible.

Côté analyse, le Turbopack Bundle Analyzer gagne une vue de synthèse des plus grosses routes client, un tableau pour trier les contributeurs, des snapshots automatiques et la distinction des modules sur le chemin critique de rendu. Un skill expérimental, next-bundle-optimizer, peut même chercher le JavaScript superflu.

Notre recommandation

Pour un site vitrine ou une boutique existante :

1. Mettez à jour avec npm install next@latest, ou lancez la commande de migration par agent.
2. Activez cacheComponents et partialPrefetching sur une branche de test.
3. Ajoutez ensureStatic = 'navigation' sur les layouts marketing et catalogue, puis redescendez-le là où du dynamique est vraiment nécessaire.
4. Mesurez avant et après avec le Bundle Analyzer, en comparant les snapshots.

Pour un nouveau projet, create-next-app active déjà Cache Components : il n'y a aucune raison de partir sur l'ancien modèle.

En bref

Next.js 16.4 fait de Cache Components le modèle recommandé, avec ensureStatic pour verrouiller le statique, des APIs de préchargement plus fines et un Turbopack plus léger. Pour un site vitrine ou une boutique, c'est le bon moment de planifier la migration avant que Next.js 17 n'en fasse le défaut.