Next.js 15 Fullstack (App Router + Server Actions) · Lezione

Esclusione dalla cache: rendering dinamico e no-store

Forzi il comportamento dinamico con cookie, header e la direttiva no-store quando la cache non è appropriata.

Lezione 4 di 413 passaggi

Esclusione dalla cache: rendering dinamico e no-store è una lezione Next.js 15 Fullstack (App Router + Server Actions) gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Next.js 15 Fullstack (App Router + Server Actions), e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Next.js 15 Fullstack (App Router + Server Actions) include 4 lezioni in totale.

Quando la memorizzazione nella cache è sbagliata

Per impostazione predefinita, Next.js 15 cerca di rendere le route statiche durante la fase di build e memorizza aggressivamente i dati nella cache. Questo è ottimo per le pagine di marketing, ma non è adatto agli elementi che devono riflettere la richiesta corrente.

Una dashboard che mostra i dati dell'utente autenticato
Una pagina che legge i cookies() o gli headers() della richiesta
Prezzi, disponibilità o notifiche che cambiano ogni secondo

Questa lezione spiega come rinunciare alla memorizzazione nella cache: forzare il rendering dinamico e disabilitare la cache di fetch con no-store.

Rendering statico e dinamico

Una route viene renderizzata in una delle due modalità:

Statica: viene renderizzata una volta, durante la build o in background, e l'HTML e i dati vengono riutilizzati per tutti.
Dinamica: viene renderizzata nuovamente a ogni richiesta, così può leggere input specifici della richiesta.

Next.js decide automaticamente. Nel momento in cui il codice utilizza una Dynamic API, come cookies(), headers() o searchParams, oppure una richiesta fetch non memorizzata nella cache, la route passa al rendering dinamico. Raramente è necessario attivarlo manualmente: rinuncia alla cache e il renderer si adegua.

cookies() forza il rendering dinamico

Leggere cookies() all'interno di un Server Component segnala che l'output dipende dalla richiesta in arrivo. In Next.js 15 queste API sono asincrone: deve applicare await.

Il solo utilizzo di cookies() sposta la route al rendering dinamico. Non è possibile leggere un cookie in modo statico, perché una pagina statica non ha alcuna richiesta da cui leggerlo.

import { cookies } from 'next/headers';

export default async function DashboardPage() {
  const cookieStore = await cookies();
  const theme = cookieStore.get('theme')?.value ?? 'light';

  // Reading cookies() opts this page out of static rendering
  return <main data-theme={theme}>Welcome back</main>;
}

Anche headers() forza il rendering dinamico

Come cookies(), in Next.js 15 headers() è asincrono e la sua lettura forza il rendering dinamico. Lo utilizzi quando l'output dipende dagli header della richiesta, ad esempio Authorization, User-Agent o un header geografico del CDN.

Poiché il valore dell'header varia per ogni richiesta, la pagina non può mai essere memorizzata nella cache come un unico HTML statico per tutti gli utenti.

import { headers } from 'next/headers';

export default async function GreetingPage() {
  const headerList = await headers();
  const country = headerList.get('x-vercel-ip-country') ?? 'unknown';

  return <h1>Hello from {country}</h1>;
}

fetch con cache: 'no-store'

Next.js estende fetch nativo con opzioni di caching. Per impostazione predefinita, il risultato di fetch può essere memorizzato nella cache, ma questo non è corretto per i dati che devono essere sempre aggiornati.

Passi cache: 'no-store' per ignorare completamente la cache. A ogni rendering viene eseguita una vera richiesta di rete e la route diventa dinamica.

cache: 'no-store' → non memorizza mai nella cache, esegue sempre un nuovo fetch
cache: 'force-cache' → memorizza nella cache indefinitamente (il vecchio valore predefinito)

async function getLivePrice(symbol: string) {
  const res = await fetch(`https://api.example.com/price/${symbol}`, {
    cache: 'no-store',
  });
  return res.json() as Promise<{ price: number }>;
}

export default async function PricePage() {
  const { price } = await getLivePrice('BTC');
  return <p>Current price: {price}</p>;
}

Anche next: { revalidate: 0 } ha lo stesso effetto

Esistono due modi equivalenti per disabilitare la cache su una singola richiesta fetch:

{ cache: 'no-store' }
{ next: { revalidate: 0 } }

Entrambi significano «non servire questo contenuto dalla cache». Per una maggiore leggibilità, preferisca cache: 'no-store'. Non combini cache: 'force-cache' con revalidate: 0: le due impostazioni sono in conflitto e Next.js mostrerà un avviso.

// These two calls behave identically
await fetch(url, { cache: 'no-store' });
await fetch(url, { next: { revalidate: 0 } });

Segmento di route: dynamic = 'force-dynamic'

Anziché rinunciare alla cache per ogni singola richiesta fetch, può farlo per un intero segmento di route usando la configurazione del segmento di route. Esportare dynamic = 'force-dynamic' da un page.tsx o layout.tsx forza il rendering dinamico a ogni esecuzione e disabilita la cache dei dati per quel segmento.

Utilizzi questa opzione quando la maggior parte dei dati della pagina deve essere aggiornata, così non dovrà annotare singolarmente ogni fetch.

// app/feed/page.tsx
export const dynamic = 'force-dynamic';

export default async function FeedPage() {
  // No need for cache: 'no-store' on each fetch —
  // the whole segment is dynamic
  const res = await fetch('https://api.example.com/feed');
  const items = await res.json();
  return <ul>{items.map((i: { id: string; text: string }) => <li key={i.id}>{i.text}</li>)}</ul>;
}

fetchCache: 'default-no-store'

fetchCache è un'opzione più sottile. Impostando fetchCache = 'default-no-store' si modifica il valore predefinito di ogni fetch nel segmento portandolo a no-store, lasciando comunque a ogni singolo fetch la possibilità di riattivare la cache con cache: 'force-cache'.

È utile in un'area autenticata, dove quasi tutto è specifico dell'utente, ma alcune richieste di dati pubblici possono comunque essere memorizzate nella cache.

// app/(app)/layout.tsx
export const fetchCache = 'default-no-store';

// Now any plain fetch() in this segment defaults to no-store.
// Opt back in explicitly when you want caching:
// await fetch(url, { cache: 'force-cache' });

API dinamiche nei Route Handler

I Route Handler (route.ts) seguono le stesse regole. Un handler GET può essere memorizzato nella cache, a meno che non legga un'API dinamica o che non si rinunci esplicitamente alla cache.

La lettura dei parametri di ricerca di request.url o la chiamata a cookies()/headers() rende dinamico l'handler. Può anche forzare questo comportamento con export const dynamic = 'force-dynamic'.

// app/api/me/route.ts
import { cookies } from 'next/headers';
import { NextResponse } from 'next/server';

export const dynamic = 'force-dynamic';

export async function GET() {
  const session = (await cookies()).get('session')?.value;
  if (!session) {
    return NextResponse.json({ error: 'unauthorized' }, { status: 401 });
  }
  return NextResponse.json({ user: session });
}

Le Server Actions sono sempre dinamiche

Le Server Actions vengono eseguite in risposta a un'interazione dell'utente, quindi sono dinamiche per natura: non vengono mai memorizzate staticamente nella cache. Possono leggere la cache e invalidarla, ma il corpo dell'action viene sempre eseguito con dati aggiornati.

Dopo aver modificato i dati in un'action, chiami revalidatePath o revalidateTag affinché le pagine memorizzate nella cache eseguano nuovamente il fetch. L'action non ha bisogno di usare direttamente no-store.

'use server';
import { revalidatePath } from 'next/cache';

export async function addComment(postId: string, text: string) {
  await db.comment.create({ data: { postId, text } });
  // Force the post page to refetch its (otherwise cached) data
  revalidatePath(`/posts/${postId}`);
}

Non ricorra a no-store troppo presto

Rinunciare alla cache ha un costo reale in termini di prestazioni: ogni richiesta raggiunge il server di origine e il database. Prima di forzare ovunque il rendering dinamico, si chieda se sia sufficiente la revalidazione basata sul tempo.

Dati aggiornati entro pochi secondi → next: { revalidate: 5 }
I dati devono riflettere questa specifica richiesta → no-store / dinamico
I dati cambiano in seguito a un evento noto → cache + revalidateTag durante la modifica

Utilizzi no-store quando la correttezza dipende davvero dall'aggiornamento a ogni richiesta, non come riflesso automatico per «far funzionare le cose».

Verifica rapida

Verifichi la Sua comprensione di come rinunciare alla cache in Next.js 15.

Rispondi nella lezione interattiva

Riepilogo

Ha imparato come rinunciare alla cache quando sarebbe errato utilizzarla:

API dinamiche — attendere cookies() o headers() forza automaticamente il rendering dinamico.
Per singolo fetch — cache: 'no-store' (oppure next: { revalidate: 0 }) ignora la cache dei dati.
Per segmento — export const dynamic = 'force-dynamic' rende dinamica l'intera route; fetchCache = 'default-no-store' modifica il valore predefinito per ogni fetch.
Route Handler — seguono le stesse regole; le Server Actions sono sempre dinamiche e invalidano le cache con revalidatePath/revalidateTag.
Moderazione — preferisca la revalidazione basata sul tempo o sui tag; ricorra a no-store solo quando la correttezza richiede dati aggiornati a ogni richiesta.

Gratis per iniziare

Impara TypeScript con un tutor IA — gratis

Scrivi ed esegui vero codice nel tuo browser, ricevi aiuto istantaneo da un tutor IA disponibile 24/7, e riprendi da dove hai lasciato sul web o nell'app.

Corsi: 22
Lezioni: 88

Inizia a imparare gratis Visualizza il corso completo

Domande Frequenti

La lezione «Esclusione dalla cache: rendering dinamico e no-store» è gratuita?

Sì — il testo completo di «Esclusione dalla cache: rendering dinamico e no-store» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Next.js 15 Fullstack (App Router + Server Actions), passa a CoddyKit PRO. Il corso Next.js 15 Fullstack (App Router + Server Actions) include 4 lezioni in totale.

Cosa imparerò in «Esclusione dalla cache: rendering dinamico e no-store»?

Forzi il comportamento dinamico con cookie, header e la direttiva no-store quando la cache non è appropriata. Eserciti Next.js 15 Fullstack (App Router + Server Actions) con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Next.js 15 Fullstack (App Router + Server Actions)?

Non è richiesta alcuna esperienza precedente. Next.js 15 Fullstack (App Router + Server Actions) su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.

Quanto tempo richiede la lezione «Esclusione dalla cache: rendering dinamico e no-store»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Next.js 15 Fullstack (App Router + Server Actions)?

Sì. Ogni lezione Next.js 15 Fullstack (App Router + Server Actions) include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

Le quattro cache: Request, Data, Full Route e Router
Strategie di revalidazione basate sul tempo e on demand
Invalidazione basata su tag per svuotare la cache in modo granulare
Esclusione dalla cache: rendering dinamico e no-store

← Torna a Next.js 15 Fullstack (App Router + Server Actions)