Caching in Next.js: Strategie e Controllo della Cache

Introduzione

Next.js implementa un sistema di caching aggressivo per migliorare le prestazioni delle applicazioni. Questo capitolo esplora i quattro tipi di cache gestiti da Next.js, come controllarli e come invalidarli quando necessario per garantire che i dati visualizzati siano sempre aggiornati.

Comprendere il sistema di caching è fondamentale per costruire applicazioni Next.js performanti e per evitare problemi comuni legati a dati obsoleti.

I Quattro Tipi di Cache in Next.js

Next.js gestisce quattro diversi tipi di cache, ognuno con uno scopo specifico:

1. Request Memoization

La request memoization (memoizzazione delle richieste) è un meccanismo che evita richieste duplicate alla stessa fonte di dati durante una singola richiesta gestita dal server Next.js.

Scopo: deduplicare richieste con la stessa configurazione all’interno di un singolo ciclo di richiesta.

Durata: solo durante una singola richiesta al server.

2. Data Cache

La data cache memorizza i dati recuperati da fonti esterne (API, database) per riutilizzarli in richieste successive, evitando viaggi di andata e ritorno non necessari.

Scopo: evitare richieste ripetute a fonti di dati quando i dati non sono cambiati.

Durata: persiste fino a riconvalida manuale o dopo un periodo di tempo configurato.

3. Full Route Cache

La full route cache memorizza l’intera pagina renderizzata (HTML completo e payload dei Server Components) invece di solo i dati.

Scopo: evitare il rendering completo di pagine che non sono cambiate.

Durata: persiste fino a quando la data cache correlata viene riconvalidata.

4. Router Cache

La router cache è una cache lato client che memorizza i payload dei Server Components nella memoria del browser per velocizzare la navigazione tra le pagine.

Scopo: migliorare la velocità di navigazione evitando richieste al server quando possibile.

Durata: invalidata quando il server renderizza nuove pagine o quando l’utente lascia il sito.

Nota: con Next.js 15, la router cache è stata resa meno aggressiva per evitare situazioni in cui le pagine potrebbero non riflettere i dati più recenti.

Request Memoization con Fetch

La request memoization funziona automaticamente quando si utilizza la funzione fetch con la stessa configurazione in punti diversi dell’applicazione durante una singola richiesta.

Esempio

1
export default async function MessagesLayout() {
2
  const messages = await fetch('http://localhost:8080/messages')
3
  // ...
4
}
5

6
// app/messages/page.js
7
export default async function MessagesPage() {
8
  const messages = await fetch('http://localhost:8080/messages')
9
  // ...
10
}

Se entrambe le richieste hanno la stessa configurazione (stesso URL, stesse opzioni), Next.js invierà una sola richiesta e riutilizzerà la risposta in entrambi i componenti.

Importante: la request memoization funziona solo se le richieste hanno esattamente la stessa configurazione. Differenze nelle opzioni (headers, method, ecc.) impediscono la deduplicazione.

Data Cache con Fetch

Quando si utilizza fetch in Next.js, i dati vengono automaticamente memorizzati nella data cache. Il comportamento predefinito varia tra Next.js 14 e 15.

Next.js 14 (Comportamento Predefinito)

1
// Comportamento predefinito: 'force-cache'
2
const response = await fetch('http://localhost:8080/messages')

Con force-cache, i dati vengono memorizzati nella cache e riutilizzati indefinitamente fino a riconvalida manuale.

Next.js 15 (Comportamento Predefinito)

1
// Comportamento predefinito: 'no-store'
2
const response = await fetch('http://localhost:8080/messages')

Con no-store, i dati non vengono memorizzati nella cache e viene sempre inviata una nuova richiesta.

Configurazione Esplicita della Cache

È possibile configurare esplicitamente il comportamento della cache:

1
// Forzare la cache (comportamento Next.js 14)
2
const response = await fetch('http://localhost:8080/messages', {
3
  cache: 'force-cache'
4
})
5

6
// Disabilitare la cache
7
const response = await fetch('http://localhost:8080/messages', {
8
  cache: 'no-store'
9
})

Revalidazione Temporale

È possibile configurare un periodo di tempo dopo il quale la cache viene automaticamente riconvalidata:

1
const response = await fetch('http://localhost:8080/messages', {
2
  next: { revalidate: 3600 } // Riconvalida dopo 1 ora
3
})

Con questa configurazione, i dati vengono memorizzati nella cache e riutilizzati per 3600 secondi (1 ora). Dopo questo periodo, la cache viene invalidata e viene inviata una nuova richiesta.

Tag per la Riconvalida

È possibile assegnare tag alle richieste per riconvalidare selettivamente parti della cache:

1
const response = await fetch('http://localhost:8080/messages', {
2
  next: {
3
    revalidate: 3600,
4
    tags: ['messages']
5
  }
6
})

I tag permettono di riconvalidare dati specifici senza invalidare l’intera cache.

Configurazione a Livello di File

Invece di configurare ogni singola richiesta fetch, è possibile impostare configurazioni globali per un intero file.

Costante `revalidate`

1
export const revalidate = 3600 // Riconvalida ogni ora
2

3
export default async function MessagesPage() {
4
  const response = await fetch('http://localhost:8080/messages')
5
  // Tutte le richieste fetch in questo file useranno revalidate: 3600
6
}

La costante revalidate deve essere esportata e applica la riconvalida temporale a tutte le richieste fetch nel file.

Costante `dynamic`

1
export const dynamic = 'force-dynamic' // Disabilita completamente la cache
2

3
export default async function MessagesPage() {
4
  const response = await fetch('http://localhost:8080/messages')
5
  // Equivalente a cache: 'no-store' per tutte le richieste
6
}

Valori possibili per dynamic:

'auto' (default): comportamento normale
'force-dynamic': disabilita la cache (equivalente a cache: 'no-store')
'force-static': forza la cache (equivalente a cache: 'force-cache')

Funzione `unstable_noStore`

Per disabilitare la cache solo per un componente specifico invece che per l’intero file:

1
import { unstable_noStore } from 'next/cache'
2

3
export default async function MessagesPage() {
4
  unstable_noStore() // Disabilita la cache solo per questo componente
5

6
  const response = await fetch('http://localhost:8080/messages')
7
  // Questa richiesta non verrà memorizzata nella cache
8
}

Nota: al momento della scrittura, questa funzione è contrassegnata come unstable, ma potrebbe essere rinominata in noStore nelle versioni future.

Full Route Cache

La full route cache memorizza l’intera pagina renderizzata invece di solo i dati. Questo avviene automaticamente durante il processo di build in produzione.

Comportamento in Produzione

Quando si esegue npm run build, Next.js:

Pre-renderizza tutte le pagine statiche
Memorizza le pagine renderizzate nella cache
Serve le pagine dalla cache senza re-renderizzarle

Questo migliora significativamente le prestazioni, ma può causare problemi se i dati cambiano dopo il build.

Disabilitare la Full Route Cache

Per disabilitare la full route cache per una pagina specifica:

1
export const dynamic = 'force-dynamic'
2

3
export default async function MessagesPage() {
4
  // Questa pagina verrà renderizzata su ogni richiesta
5
  // invece di essere servita dalla cache
6
}

Con force-dynamic, la pagina viene renderizzata dinamicamente su ogni richiesta, garantendo dati sempre aggiornati ma con un costo in termini di performance.

Riconvalida della Cache

Quando i dati cambiano, è necessario invalidare la cache per mostrare i dati aggiornati.

`revalidatePath`

La funzione revalidatePath permette di invalidare la cache di una route specifica:

1
import { revalidatePath } from 'next/cache'
2

3
export async function createMessage(formData) {
4
  'use server'
5

6
  // Salvataggio del nuovo messaggio
7
  await addMessage(formData.get('content'))
8

9
  // Riconvalidare la cache della pagina /messages
10
  revalidatePath('/messages')
11
}

Modalità di riconvalida:

1
// Riconvalidare solo una pagina specifica
2
revalidatePath('/messages')
3

4
// Riconvalidare una pagina e tutte le route annidate
5
revalidatePath('/messages', 'layout')
6

7
// Riconvalidare tutte le pagine dell'applicazione
8
revalidatePath('/', 'layout')

`revalidateTag`

Quando si utilizzano tag nelle richieste fetch, è possibile riconvalidare selettivamente usando revalidateTag:

1
const response = await fetch('http://localhost:8080/messages', {
2
  next: { tags: ['messages'] }
3
})
4

5
// actions/messages.js
6
import { revalidateTag } from 'next/cache'
7

8
export async function createMessage(formData) {
9
  'use server'
10

11
  await addMessage(formData.get('content'))
12

13
  // Riconvalidare tutti i dati con il tag 'messages'
14
  revalidateTag('messages')
15
}

I tag permettono di riconvalidare dati specifici senza invalidare l’intera cache, rendendo il processo più efficiente.

Caching con Fonti Dati Personalizzate

Quando si accede direttamente a un database o a altre fonti di dati (invece di usare fetch), è necessario gestire manualmente la cache.

Deduplicazione Richieste con `cache` di React

Per evitare richieste duplicate durante una singola richiesta, è possibile utilizzare la funzione cache di React:

1
import { cache } from 'react'
2
import sql from 'better-sqlite3'
3

4
const db = sql('messages.db')
5

6
// Avvolgere la funzione con cache per deduplicare le richieste
7
const getMessages = cache(() => {
8
  return db.prepare('SELECT * FROM messages').all()
9
})
10

11
export { getMessages }

Con questa configurazione, se getMessages viene chiamata più volte durante una singola richiesta, viene eseguita solo una volta e il risultato viene riutilizzato.

Cache dei Dati con `unstable_cache`

Per abilitare la data cache con fonti di dati personalizzate, è possibile utilizzare unstable_cache:

1
import { unstable_cache } from 'next/cache'
2
import { cache } from 'react'
3
import sql from 'better-sqlite3'
4

5
const db = sql('messages.db')
6

7
// Deduplicazione richieste
8
const getMessagesUncached = cache(() => {
9
  return db.prepare('SELECT * FROM messages').all()
10
})
11

12
// Cache dei dati
13
export const getMessages = unstable_cache(
14
  async () => {
15
    return getMessagesUncached()
16
  },
17
  ['messages'], // Chiavi della cache (usate internamente)
18
  {
19
    tags: ['messages'] // Tag per riconvalida selettiva
20
  }
21
)

Importante: unstable_cache restituisce sempre una Promise, quindi le funzioni che lo utilizzano devono essere async e le chiamate devono usare await.

Riconvalida con Fonti Dati Personalizzate

Quando si utilizzano fonti di dati personalizzate con unstable_cache, è possibile riconvalidare usando revalidatePath o revalidateTag:

1
import { revalidatePath, revalidateTag } from 'next/cache'
2

3
export async function createMessage(formData) {
4
  'use server'
5

6
  await addMessage(formData.get('content'))
7

8
  // Opzione 1: Riconvalidare per path
9
  revalidatePath('/messages')
10

11
  // Opzione 2: Riconvalidare per tag (se configurato)
12
  revalidateTag('messages')
13
}

Best Practices

Quando Usare `force-cache`

Utilizzare force-cache quando:

I dati cambiano raramente
Le prestazioni sono prioritarie
Si ha controllo completo su quando riconvalidare

Quando Usare `no-store`

Utilizzare no-store quando:

I dati cambiano frequentemente
È necessario mostrare sempre dati aggiornati
La performance non è critica

Quando Usare `revalidate`

Utilizzare revalidate quando:

I dati cambiano periodicamente ma non in tempo reale
Si vuole bilanciare performance e freschezza dei dati
Si conosce la frequenza di aggiornamento dei dati

Quando Usare `revalidatePath` vs `revalidateTag`

revalidatePath: quando si sa esattamente quale pagina riconvalidare
revalidateTag: quando più pagine condividono gli stessi dati e si vuole riconvalidarle tutte insieme

Pattern Consigliato

1
// 1. Configurare tag nelle richieste
2
const response = await fetch('http://localhost:8080/messages', {
3
  next: { tags: ['messages'] }
4
})
5

6
// 2. Riconvalidare per tag quando i dati cambiano
7
export async function createMessage(formData) {
8
  'use server'
9
  await addMessage(formData.get('content'))
10
  revalidateTag('messages') // Riconvalida tutte le pagine che usano questo tag
11
}

Questo pattern permette di:

Mantenere la cache per performance
Riconvalidare selettivamente quando necessario
Evitare riconvalidazioni eccessive

Differenze tra Next.js 14 e 15

Next.js 14

Comportamento predefinito: cache: 'force-cache'
Cache più aggressiva: dati e route vengono cachati più aggressivamente
Router cache: più aggressiva

Next.js 15

Comportamento predefinito: cache: 'no-store'
Cache meno aggressiva: per evitare problemi con dati obsoleti
Router cache: meno aggressiva per garantire dati più freschi

Raccomandazione: se si migra da Next.js 14 a 15, verificare il comportamento della cache e aggiustare le configurazioni se necessario.

Conclusione

Il sistema di caching di Next.js è potente ma complesso. Comprendere i diversi tipi di cache e come controllarli è essenziale per:

Performance: sfruttare la cache per migliorare le prestazioni
Freschezza dei dati: garantire che i dati visualizzati siano aggiornati quando necessario
Efficienza: riconvalidare solo quando necessario, evitando overhead non necessario

Le strategie di caching devono essere bilanciate in base alle esigenze specifiche dell’applicazione: dati che cambiano frequentemente richiedono cache meno aggressiva, mentre dati statici possono beneficiare di cache più aggressiva.