Next.js 16.3 est maintenant disponible. Parmi les changements mis en avant, il y a les navigations instantanées et la suite du modèle Cache Components.
Sur le papier, c’est exactement le genre de nouveauté qui devrait m’intéresser. Mon portfolio utilise l’App Router, lit son contenu depuis SQLite et tourne sur mon VPS. Le cache n’est pas un détail d’infrastructure : il décide directement quand la base est interrogée et quand un nouvel article devient visible.
Pourtant, je ne vais pas activer Cache Components immédiatement.
## Ce que j’utilise aujourd’hui
J’ai commencé avec une solution beaucoup plus brutale : toutes les pages publiques étaient en force-dynamic.
C’était simple à comprendre. Chaque visite relançait le rendu et frappait SQLite. Le contenu était toujours frais, mais mon site recalculait des pages qui changent seulement après une action dans l’admin ou la publication d’un article.
J’ai ensuite basculé le public en ISR avec une revalidation d’une heure. Les fiches projet sont prérendues, et une revalidation explicite est lancée lorsque le contenu change.
Ce passage n’a pas été propre du premier coup. Une navigation interne pouvait encore afficher une version périmée du parcours. Le script de génération d’articles pouvait aussi créer un article sans le faire apparaître immédiatement si le secret de revalidation manquait. J’ai dû rendre cette étape bruyante dans les logs au lieu de laisser le cache échouer silencieusement.
Mon modèle actuel est donc assez simple :
- les visiteurs reçoivent principalement des pages déjà rendues ;
- SQLite n’est pas interrogé à chaque affichage ;
- l’admin et le cron déclenchent la mise à jour du contenu public ;
- l’heure de revalidation reste un filet de sécurité.
Ce n’est pas très fin, mais je sais où regarder quand un article existe en base sans apparaître sur le site.
## Ce que Cache Components change
Avec Cache Components, Next.js ne demande plus de choisir le comportement au niveau de la route entière. Une page peut contenir une coquille prérendue, des composants explicitement mis en cache et des parties rendues au moment de la requête.
La documentation de Cache Components décrit ce mélange entre contenu statique, contenu mis en cache et contenu dynamique. Le cache devient une décision locale, portée notamment par use cache, au lieu d’être seulement une durée posée sur toute la page.
C’est intéressant pour mon portfolio. Le cadre d’une page, la navigation et une grande partie du contenu éditorial peuvent être servis immédiatement. Une zone réellement dynamique pourrait rester séparée sans rendre toute la route dynamique.
Le problème est que mon portfolio possède peu de zones de ce genre. Les projets, le parcours et les articles changent depuis mon panneau d’admin, mais ils n’ont pas besoin d’être recalculés pour chaque visiteur. Mon ISR correspond déjà assez bien à leur rythme réel.
Le dashboard est différent. Ses widgets sont indépendants et certains récupèrent des informations extérieures. Le découpage proposé par Cache Components colle mieux à cette architecture. Mais le gain annoncé autour des navigations compte moins pour lui : je l’ouvre surtout comme nouvel onglet. Je ne passe pas mon temps à naviguer entre ses routes.
## Pourquoi je ne bascule pas maintenant
Activer cacheComponents ne consiste pas seulement à ajouter un booléen. La documentation de migration indique que les configurations comme revalidate, dynamic et fetchCache sont remplacées par un modèle basé sur use cache et cacheLife.
Sur mon portfolio, cela toucherait précisément la partie que je viens de stabiliser : la publication, l’ISR et la revalidation depuis l’admin ou le cron.
Je gagnerais des limites de cache plus précises. En échange, je devrais reconstruire ma représentation mentale de la fraîcheur du contenu et vérifier le comportement sur mon propre serveur Node. Ce n’est pas un mauvais échange. Ce n’est simplement pas encore un échange nécessaire.
Je garde donc l’ISR actuel en production. Je vais tester Cache Components sur une branche du portfolio, avec un seul critère : publier un article depuis l’admin, naviguer vers le blog sans rechargement complet, puis vérifier exactement quelle version apparaît et pourquoi. Tant que ce chemin n’est pas plus clair que mon système actuel, le booléen restera à false.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.