La montée de version vers Next.js 15 sur un projet de guide culinaire a d’abord semblé anodine : les tests automatisés passaient, le site se construisait sans erreur. Le problème est apparu au premier déploiement en production : les temps de réponse avaient nettement augmenté, et les journaux du serveur WordPress montraient un nombre de requêtes bien plus élevé qu’avant la migration.
La cause tenait en une ligne de changelog facile à survoler : Next.js 15 change le comportement par défaut du cache des appels fetch, qui n’est plus mis en cache automatiquement comme c’était le cas dans les versions précédentes.
Le changement de comportement par défaut
Avant cette version, un appel fetch exécuté dans un composant serveur ou un gestionnaire de route était mis en cache par défaut, sauf mention contraire explicite. Depuis Next.js 15, c’est l’inverse : chaque appel fetch est traité comme non mis en cache par défaut, et il faut désormais déclarer explicitement l’intention de cache.
// Avant : mis en cache implicitement
const donnees = await fetch(URL_WPGRAPHQL, { method: 'POST', body: requete });
// Après Next.js 15 : il faut être explicite
const donnees = await fetch(URL_WPGRAPHQL, {
method: 'POST',
body: requete,
next: { revalidate: 300, tags: ['articles'] },
});
Pourquoi ce changement a du sens malgré la migration douloureuse
Un cache implicite et invisible avait tendance à surprendre les équipes qui ne s’attendaient pas à voir un contenu resservi en cache alors qu’elles pensaient chaque requête toujours fraîche. Rendre ce comportement explicite force à réfléchir, route par route, à la vraie fraîcheur nécessaire, plutôt que de subir un cache appliqué uniformément sans y avoir pensé.
Ce qu’il a fallu revoir sur ce projet
- Chaque appel à WPGraphQL a été audité un par un pour lui attribuer un
revalidateet destagscohérents avec la nature du contenu demandé. - Les pages de recettes, peu volatiles, ont reçu une durée de cache généreuse.
- La page d’accueil, qui affiche les publications les plus récentes, a reçu une durée bien plus courte pour rester réactive aux nouvelles publications.
L’impact sur les temps de build
Sans réglage adapté, une partie des pages auparavant construites une seule fois au build se remettent à interroger WordPress à chaque requête, ce qui augmente la charge sur l’origine et peut ralentir le temps de réponse perçu si aucune stratégie de revalidation n’est explicitement définie. Le correctif ne consiste pas à revenir en arrière, mais à choisir consciemment, requête par requête, entre génération statique, revalidation périodique ou appel dynamique à chaque visite.
Ce changement de version a eu le mérite de forcer une vraie revue de la stratégie de cache du projet, alors qu’elle reposait jusque-là sur un comportement implicite que personne n’avait vraiment challengé depuis le lancement initial.
Le rôle des tags dans la revalidation ciblée
Au-delà du simple délai fixé par revalidate, associer des tags à chaque appel fetch permet de déclencher une revalidation ciblée depuis un webhook WordPress, via un appel à revalidateTag, sans attendre l’expiration naturelle du délai. Sur ce projet, chaque webhook de publication déclenche désormais la revalidation du seul tag concerné (articles, recettes ou ingredients) plutôt qu’un rechargement global de tout le site, ce qui limite la charge imposée à WordPress au moment de chaque publication.
Un conseil pour toute migration future
Avant de monter de version sur un projet qui dépend fortement d’appels fetch vers une API externe comme WPGraphQL, vérifier systématiquement les notes de version concernant le comportement de cache par défaut. Un changement de ce type ne provoque aucune erreur de compilation : il se manifeste uniquement en production, sous forme de charge supplémentaire sur l’origine, ce qui le rend particulièrement facile à manquer en phase de test.
En résumé
Next.js 15 ne retire aucune capacité de cache, il en change simplement la philosophie par défaut, du cache implicite vers le cache explicite. Pour un front WordPress, cela signifie revoir chaque appel à l’API comme une décision consciente plutôt qu’un comportement hérité, ce qui, une fois fait, rend la stratégie de fraîcheur du site bien plus lisible qu’auparavant.
