Le cache Next.js : puissant mais piégeux
« Il y a seulement 2 problèmes compliqués en informatique : nommer les choses, et l’invalidation de cache » – Phil Karlton. Avec Next.js App Router, le cache est agressif par défaut, ce qui améliore les performances mais peut créer des comportements inattendus. Chez Eve Media, nous maîtrisons ces subtilités pour des apps Next.js robustes.
Les quatre couches de cache
Next.js App Router a plusieurs niveaux de cache : Request Memoization (durant une requête), Data Cache (persistant), Full Route Cache (pages statiques), et Router Cache (côté client). Chacun a son comportement et ses règles d’invalidation.
Request Memoization
Si vous appelez la même fonction fetch avec les mêmes arguments plusieurs fois dans un render tree, Next.js n’exécute qu’un seul appel réseau. C’est utile pour éviter les requêtes dupliquées dans des composants différents.
Data Cache
Par défaut, les résultats de fetch() sont cachés indéfiniment côté serveur. Cela signifie que vos données peuvent être stales même après un redéploiement. C’est souvent le cache le plus problématique pour les développeurs habitués aux comportements traditionnels.
Contrôler le Data Cache
fetch(url, { cache: ‘no-store’ }) désactive le cache. fetch(url, { next: { revalidate: 60 } }) revalide après 60 secondes. export const dynamic = ‘force-dynamic’ au niveau page désactive le cache pour toute la page.
Full Route Cache
Les pages sans données dynamiques sont rendues au build time et servies comme fichiers statiques. C’est excellent pour la performance mais signifie que les changements nécessitent un rebuild.
Router Cache (Client)
Le cache côté client stocke les segments de route visités. La navigation back/forward est instantanée. Mais ce cache peut montrer des données stales. router.refresh() force le rafraîchissement.
Revalidation à la demande
revalidatePath(‘/path’) et revalidateTag(‘tag’) permettent d’invalider le cache programmatiquement. Utile après une mutation pour s’assurer que les données fraîches sont servies.
Les pièges courants
Données qui ne se mettent pas à jour après un changement en base. Différences entre dev (souvent no-cache) et production. POST/PUT/DELETE qui ne déclenchent pas de rafraîchissement. Comprendre ces pièges évite des heures de debugging.
Bonnes pratiques
Soyez explicites sur vos intentions de cache. Utilisez les tags pour grouper les données liées. Implémentez la revalidation dans vos Server Actions. Testez le comportement de cache en production, pas seulement en dev.
Outils de debugging
Les headers de réponse (x-nextjs-cache) indiquent l’état du cache. Les logs serveur montrent les cache HIT/MISS. Next.js DevTools aide à visualiser le comportement du cache.
Conclusion
Le cache Next.js App Router est un outil puissant pour la performance, mais il nécessite une compréhension approfondie. Investissez le temps d’apprendre ses mécanismes pour éviter les surprises en production.
Chez Eve Media, nous développons des applications Next.js performantes et fiables. Contactez-nous pour vos projets React/Next.
