Rendering Statico Con Supporto Della Modalita Di Modifica

Questa guida spiega come il sito della documentazione ottiene caricamenti statici rapidi delle pagine mantenendo la funzionalità della modalità di modifica del CMS.

Architettura a Doppio Percorso

Utilizziamo due route per lo stesso contenuto:

app/
├── [...slug]/page.tsx          # Produzione: force-static (veloce)
└── preview/[...slug]/page.tsx  # Modalità di modifica: force-dynamic (legge searchParams)

Un middleware proxy riscrive in modo trasparente le richieste della modalità di modifica:

Richiesta dell'utente: /en/headless/quickstart?edit_mode=true
       ↓
Il proxy rileva ?edit_mode=true
       ↓
Riscrittura interna in: /preview/en/headless/quickstart?edit_mode=true
       ↓
La route dinamica esegue il rendering con wrapper di modifica

L'utente non vede mai /preview nel proprio URL - è una riscrittura interna.

Come Funziona

Percorso di Produzione (Predefinito)

// app/[...slug]/page.tsx
export const dynamic = 'force-static';
export const revalidate = 60;

export default async function Page({ params }) {
  // Nessun searchParams - la pagina è completamente statica
  

• Le pagine sono prerenderizzate in fase di build
• Servite istantaneamente dalla cache edge della CDN
• Riconvalidate ogni 60 secondi (ISR) come rete di sicurezza

Percorso Modalità Modifica

// app/preview/[...slug]/page.tsx
export const dynamic = 'force-dynamic';

export default async function PreviewPage({ params, searchParams }) {
  // searchParams disponibile - può rilevare edit_mode
  return <ParametricRoutePage params={params

• Renderizzata a ogni richiesta
• Può leggere ?edit_mode=true dall'URL
• Viene renderizzata con wrapper modificabili del CMS e contorni dei blocchi

La Riscrittura del Proxy

// src/proxy.ts
export const proxy = async (request: NextRequest) => {
  const { pathname, searchParams } = request.nextUrl;

  const editMode = searchParams.get('edit_mode');

Confronto delle Prestazioni

Comprendere l'ISR (Incremental Static Regeneration)

L'impostazione revalidate = 60 abilita l'ISR. Questo NON significa che le pagine vengano ricalcolate ogni 60 secondi.

L'ISR utilizza uno schema stale-while-revalidate:

Richiesta in ingresso:
  → La pagina in cache ha meno di 60 s? → Servi dalla cache (istantaneo)
  → La pagina in cache ha più di 60 s? → Servi la cache obsoleta (istantaneo)
                                + rivalida in background per la richiesta successiva

Nessuna richiesta = Nessuna ricalcolazione. Mai.

Esempio:

• Pagina messa in cache alle 10:00
• Nessun visitatore fino alle 15:00
• Il primo visitatore alle 15:00 ottiene immediatamente la cache obsoleta
• L'aggiornamento in background avviene, il visitatore successivo riceve contenuto aggiornato

La finestra di 60 secondi è una rete di sicurezza. Idealmente, useremmo la rivalidazione on-demand tramite webhook quando il contenuto del CMS cambia.

Quando Utilizzare Ogni Route

Perché Non Usare Semplicemente il Rendering Dinamico?

L'approccio semplice (nessun force-static, nessuna route di anteprima) funziona ma è lento:

// Approccio semplice - funziona ma ~1-2s per richiesta
export default async function Page({ params, searchParams }) {
  return <ParametricRoutePage params={params} searchParams={searchParams} />;
}

Questo esegue il rendering in modo dinamico a ogni richiesta. Per un sito di documentazione con molte pagine, ciò significa:

• Avvii a freddo su ogni pagina
• Nessun vantaggio della cache edge della CDN
• Tempi di caricamento di 1-2 secondi contro millisecondi

L'architettura a doppia route ci offre il meglio di entrambi i mondi: velocità statica per i lettori, funzionalità dinamica per gli editor.