Caching

Ces règles identifient les motifs qui contournent la mise en cache CDN et ISR de Vercel, forçant un rendu côté serveur inutile et augmentant les coûts de calcul.

Comportement selon la version

Les diagnostics de cache s'adaptent à la version majeure de Next.js détectée :

• Next.js 15 : les avertissements soulignent que fetch et les handlers GET ne sont pas mis en cache par défaut.
• Next.js 16+ : les avertissements priorisent les recommandations sur Cache Components ("use cache", tags de cache, revalidation ciblée).
• Autres/versions inconnues : les avertissements utilisent des recommandations de politique de cache agnostiques du framework.

nextjs-no-side-effect-in-get-handler

Détecte les handlers de route GET contenant des side effects (modification de cookies, headers ou appels base de données) ou situés sur des segments de route mutants comme /logout, /signout, /delete, etc.

Why it matters: Les requêtes GET peuvent être déclenchées par le prefetching et sont vulnérables aux attaques CSRF. Les side effects dans les handlers GET empêchent aussi la mise en cache.

// app/api/logout/route.ts
export async function GET() {
  cookies().delete("session");
  return Response.json({ ok: true });
}

// app/api/logout/route.ts
export async function POST() {
  cookies().delete("session");
  return Response.json({ ok: true });
}

Segments de route mutants détectés : logout, log-out, signout, sign-out, unsubscribe, delete, remove, revoke, cancel, deactivate.

vercel-no-force-dynamic

Détecte les pages avec export const dynamic = "force-dynamic".

Why it matters: force-dynamic force le rendu côté serveur à chaque requête, contournant complètement la mise en cache full-page.

export const dynamic = "force-dynamic";

export default function Page() { ... }

export const revalidate = 3600;

export default function Page() { ... }

vercel-no-no-store-fetch

Détecte les appels fetch avec cache: "no-store" ou revalidate: 0.

Why it matters: Ces options désactivent complètement la mise en cache, augmentant la bande passante non mise en cache et les coûts de calcul à chaque requête.

const data = await fetch(url, { cache: "no-store" });

const data = await fetch(url, {
  next: { revalidate: 3600 },
});

vercel-missing-cache-policy

Détecte les handlers de route GET sans aucune config de cache explicite — pas de headers Cache-Control, pas d'export revalidate, pas d'export dynamic.

Why it matters: Sans politique de cache explicite, les réponses peuvent manquer des opportunités de mise en cache CDN, provoquant des accès répétés à l'origin.

export async function GET() {
  const data = await fetchData();
  return Response.json(data);
}

export const revalidate = 3600;

export async function GET() {
  const data = await fetchData();
  return Response.json(data);
}

vercel-prefer-get-static-props

Détecte les routes Pages Router utilisant getServerSideProps.

Why it matters: getServerSideProps s'exécute à chaque requête. Passer à getStaticProps (avec ISR optionnel) met les pages en cache au CDN et réduit le calcul serveur.

vercel-get-static-props-consider-isr

Détecte getStaticProps sans valeur de retour revalidate.

Why it matters: Sans revalidate, toutes les pages sont construites au moment du déploiement. Pour les sites volumineux, cela ralentit considérablement les builds. L'ISR génère les pages à la demande et les met en cache.

export async function getStaticProps() {
  const data = await fetchData();
  return {
    props: { data },
    revalidate: 3600,
  };
}