Désactivation du préchargement des pages
Par défaut, Next.js précharge les pages dont les liens sont visibles dans la page consultée par un visiteur, ce qui peut entraîner un appel massif de fonctions lambdas pour générer les pages via l'ISR, lorsque leur Full Route Cache est invalidé.
Pour y remédier, passez à prefetch={false} les balises <Link> de next/link à des endroits stratégiques de votre site. Vous pourriez par exemple conserver le préchargement sur les pages principales de votre site, comme les liens de votre menu de navigation, en vous assurant une bonne configuration de leur cache.
Ce simple ajustement peut significativement diminuer la consommation de nombreuses métriques Vercel en même temps.
Optimisation du Data Cache
Ah, le Data Cache chez Vercel et Next.js, quel sujet passionnant ! Un outil d'optimisation puissant, souvent incompris et mal utilisé, même parfois détesté.
Le Data Cache stocke temporairement les résultats des requêtes utiles à la génération des pages d'une application Next.js, évitant ainsi de solliciter inutilement des fournisseurs de données, généralement trop lents, à chaque visite. Mais attention, un cache trop gourmand peut vite devenir un fardeau pour votre budget Vercel. C'est là que notre expertise entre en jeu.
Désactivation stratégique du cache des fetch
Il arrive parfois de récupérer des quantités de données très importantes et non optimisées auprès d'API ; pour lesquelles une faible quantité est utile à la génération de nos pages Next.js.
Dans ce cas, nous préconisons de désactiver le cache des fetch via l'option cache: 'no-cache'. Les fetch depuis l'App Router dans les versions de Next.js 13 et 14 sont cachés par défaut, cela n'est plus le cas à partir de Next.js 15. Cela peut sembler contre-intuitif, mais faites-nous confiance. Ensuite, sélectionnez manuellement les données essentielles à cacher grâce à la fonction unstable_cache.
1import { unstable_cache } from 'next/cache';
2
3const fetchHeavyData = async () => {
4 const result = await fetch('https://example.com/api/heavy-data', {
5 cache: 'no-cache',
6 });
7
8 // The body variable contains an huge amount of data.
9 const body = await result.json();
10
11 return {
12 items: body.items.map((item) => {
13 // We manually select the properties we need to
14 // reduce the size of the response.
15 return {
16 id: item.id,
17 title: item.title,
18 description: item.description,
19 };
20 }),
21 };
22};
23
24export const fetchData = unstable_cache(fetchHeavyData, ['fetchHeavyData'], {
25 // Here goes your caching strategy
26 revalidate: 3600,
27});Cette méthode, bien que laborieuse, vous permettra de réduire considérablement votre consommation de Data Cache, en Read comme en Write. Votre portefeuille vous remerciera, et vos utilisateurs n'y verront que du feu. Gagnant-gagnant.
Les inconvénients de la fonction unstable_cache
Cependant, ne nous emballons pas trop vite. La fonction unstable_cache, bien que prometteuse, n'est pas exempte de défauts. Son nom même devrait éveiller votre méfiance : "unstable", vraiment ? Ce n'est guère rassurant pour une fonction censée gérer nos précieuses données.
C'est pourquoi nous recommandons vivement l'utilisation de la librairie nextjs-better-unstable-cache. Cette alternative, véritable panacée des développeurs avertis, pallie les lacunes de son prédécesseur. D'ailleurs, son auteur Alfonsus Ardani a rédigé un article sur le sujet que nous vous invitons à le consulter pour approfondir votre compréhension.
Optimiser votre Data Cache est un exercice d'équilibriste. Il faut jongler entre performance et économie, rapidité et frugalité. Mais avec les bons outils et un peu de pratique, vous deviendrez bientôt un véritable virtuose du cache avec Next.js sur Vercel.
La puissance du "force-static" : quand et comment bien l'utiliser
L'introduction de l'App Router avec Next.js 13 semble avoir chamboulé tous les concepts de cache. Mais il garde, dans son fond, les mêmes codes que le précédent système Pages Router et de ses bien connues fonctions getStaticProps et getServerSideProps, que l'on retrouve dans de nombreux autres framework web.
Assurez-vous d'utiliser dès que possible le paramètre export const dynamic = 'force-static' pour vos pages App Router pour bénéficier au maximum du Full Route Cache pour vos pages web. Pour bien faire, veillez à bien configurer vos règles de revalidation du cache, sans cela cette configuration pourrait s'avérer absolument inefficace :
Revalidation temporelle : trouver le juste équilibre
Configurez finement le délai de revalidation de chacun de vos appels d'API via le paramètre revalidate. Déterminez la juste valeur pour optimiser votre consommation d'infrastructure Vercel et l'expérience de vos visiteurs.
Toutefois, n'imaginez pas de résultats miracles en augmentant le délai de revalidation du cache de vos routes et fetchs. Notre expérience nous a demontré qu'il s'agit bien d'une optimisation peu impactante sur l'usage Vercel. Certes, allonger ce délai peut réduire la charge sur vos serveurs. Mais attention, cela peut aussi rendre votre site moins réactif aux mises à jour.
Revalidation via un webhook : synchronisation avec votre CMS Headless
Parlons maintenant d'une technique bien plus optimisée, mais pas plus sophistiquée pour autant : la revalidation (ou purge de votre cache) via un webhook.
L'idée est simple : dès qu'une modification est publiée dans votre CMS Headless, par exemple, un webhook est déclenché pour purger tous les fetchs liés à l'API de ce CMS. C'est efficace, et ça évite d'avoir des contenus obsolètes sur votre site, sans avoir à décider d'un délai de revalidation par soi-même.
Voici un exemple d'endpoint que vous pourriez mettre en place :
1// app/api/revalidate/storyblok/route.js
2
3import { revalidateTag } from 'next/cache';
4import { NextResponse } from 'next/server';
5
6export const GET = async (request) => {
7 const { searchParams } = new URL(request.url);
8
9 if (searchParams.get('token') !== process.env.REVALIDATE_SECRET) {
10 return NextResponse.json({ message: 'Invalid token' }, { status: 401 });
11 }
12
13 revalidateTag('storyblok');
14
15 return NextResponse.json({ message: 'Success' });
16};Veillez à inclure le tag 'storyblok' dans chacun de vos appels d'api fetch via le paramètre next.tags :
1await fetch('https://api.storyblok.com/v2/cdn', {
2 next: {
3 tags: ['storyblok'],
4 },
5});Enfin, depuis le panneau de configuration du service externe, Storyblok dans cet exemple, configurez un webhook menant vers votre nouvel endpoint, incluant le token secret en search param de l'URL.
Function Duration : éviter les pièges
Vercel étant une plateforme serverless, nous devons être vigilants sur notre usage de leur infrastructure, car chaque seconde compte. La métrique Function Duration mesure le temps d'exécution de nos fonctions serverless, qui pourrait parfois vite s'emballer. À garder également en tête : la fonctionnalité ISR (Incremental Static Regeneration) de Next.js consomme aussi ces précieuses secondes.
Déjouer les boucles infinies : le cauchemar des lambdas
Imaginez un instant : vos fonctions s'emballent et tournent sans fin. C'est le scénario catastrophe par excellence. Bien que nous pensions ne jamais laisser l'opportunité d'une boucle infinie de se créer dans notre projet, elles peuvent parfois être créées par des librairies externes, par exemple.
Pour éviter tout ennui, nous vous conseillons une seule chose : la configuration du paramètre Next.js maxDuration. En fixant une durée maximale, nous posons des barrières salvatrices à nos fonctions. Par défaut, la durée maximale d'execution des fonction sur Vercel est de 10 ou 15 secondes, selon votre forfait. Ce sont probablement bien trop de secondes nécessaires pour la génération des pages de votre site web (nous l'espérons du moins).
Éviter la panique des lambdas avec @storyblok/js
Certains SDK de services externes utiles pour votre projet Next.js intègrent une fonctionnalitées de renouvellement de tentatives. C'est notamment le cas de la librairie @storyblok/js.
Notre conseil ? Configurez vos SDK avec des stratégies de renouvellement de tentatives optimales pour votre projet.
Par exemple, ajoutez ce petit réglage lors de l'initialisation du client Storyblok via la fonction storyblokInit : apiOptions.maxRetries = 0. Évitez ainsi les tentatives frénétiques de requêtes en cas de Rate-limit atteint, plus de consommation excessive possible. Votre site retrouvera son calme, et vous, votre sérénité.
Notre expertise Next.js à votre service
Nous espérons sincèrement que ces conseils vous aideront à dompter votre consommation Vercel !
Toutefois, gardez à l'esprit que chaque projet Next.js ou React est unique, avec ses propres défis et particularités. Si vous vous sentez dépassé ou si vous souhaitez simplement bénéficier d'un regard expert, n'hésitez pas à faire appel à nos experts Next.js pour un audit approfondi. Nous serons ravis de mettre notre expertise au service de votre projet web.
