Next.js Incremental Static Regeneration vs SSR – Analisi approfondita delle prestazioni e dei costi

Next.js è diventato lo standard de facto per la creazione di applicazioni React moderne, e le due modalità di rendering più importanti – Incremental Static Regeneration (ISR) e Server‑Side Rendering (SSR) – suscitano spesso dubbi nella scelta dell'architettura. In questo articolo esamineremo i loro meccanismi interni, misureremo i tempi di rendering reali, stimiamo i costi delle risorse e indicheremo quando conviene scegliere una soluzione rispetto all'altra.

Come funziona Incremental Static Regeneration?

ISR combina i vantaggi della generazione statica (SSG) con la possibilità di aggiornare i contenuti dopo il deployment. Alla prima richiesta Next.js genera l'HTML e lo salva nella cache (Edge o CDN). Successivamente, per le richieste successive, il server restituisce il file già memorizzato, mentre in background, se è trascorso il revalidate specificato in getStaticProps, avvia il processo di rigenerazione.

export async function getStaticProps() {
  const data = await fetchAPI();
  return {
    props: { data },
    revalidate: 60 // aggiorna ogni 60 s
  };
}

Il meccanismo si basa sulla funzione unstable_revalidate (da Next.js 13) o su una coda interna di chiamate Lambda/Edge. Grazie a ciò non è necessario mantenere un server sempre attivo – basta una breve funzione che genera una nuova versione della pagina.

Server‑Side Rendering – classico con cache moderna

SSR rende la pagina ad ogni richiesta, invocando getServerSideProps. Il risultato viene inviato direttamente al browser, dopodiché React “idrata” l'interfaccia interattiva. In pratica SSR richiede un processo Node.js permanente, con un consumo maggiore di memoria e CPU.

export async function getServerSideProps(context) {
  const data = await fetchAPI(context.params.id);
  return { props: { data } };
}

Le prestazioni di SSR possono essere migliorate aggiungendo uno strato di cache (ad es. stale‑while‑revalidate su Vercel Edge) o memoizzando le query, ma ogni request richiede comunque l'elaborazione in Node.

Confronto ISR e SSR in Next.js – tempi di rendering e costi

• Cold start ISR: la prima richiesta dopo il deploy genera l'HTML – costo simile a SSR, ma una tantum.
• Warm ISR: le richieste successive restituiscono il file statico dal CDN – latenza 20‑40 ms con distribuzione globale.
• SSR: ogni request richiede l'intero ciclo Node – tipicamente 120‑250 ms a seconda della complessità delle query.
• Costi: ISR paga solo per lo storage CDN e le invocazioni occasionali di Lambda; SSR paga per le istanze sempre attive (CPU, RAM) e per il traffico.

In pratica le differenze diventano critiche con alti RPS (richieste al secondo). Con 10 000 RPS ISR può gestire il traffico a costi minimi, mentre SSR richiede scaling orizzontale, aumentando la bolletta.

Quando usare ISR e quando no?

• ISR: contenuti che cambiano raramente (es. blog, catalogo prodotti), importanti per SEO ma tolleranti al ritardo di revalidate.
• SSR: dati che necessitano aggiornamenti immediati (es. carrello, personalizzazione post‑login), UI dinamica dipendente dalla sessione.

Se la tua applicazione richiede una combinazione – è possibile mescolare entrambi gli approcci nello stesso progetto, definendo getStaticProps per le pagine pubbliche e getServerSideProps per le sezioni protette.

Trappole della migrazione da SSR a ISR

Il passaggio non è banale. I problemi più comuni sono:

• Dipendenze dimenticate da req/res nel codice – ISR non ha accesso all'oggetto request.
• Cache‑stale data – dati non aggiornati dopo una modifica al database, se revalidate è troppo lungo.
• Mancanza di gestione degli header di autorizzazione nella CDN, che impedisce la consegna di pagine personalizzate.

La soluzione è estrarre la logica di business in un layer di servizi (es. microservizio) e nei componenti usare solo dati puri.

“Non si tratta di quale approccio sia più veloce, ma di quale si adatti meglio ai requisiti del tuo prodotto.”

Checklist pratica per la migrazione SSR → ISR

• Verifica quali pagine non necessitano di dati contestuali (sessione, auth).
• Identifica i punti in cui usi req.headers – spostali in API routes.
• Stabilisci un intervallo revalidate ragionevole basato sulla frequenza di cambiamento dei dati.
• Esegui test di performance (k6, Artillery) prima e dopo la migrazione.
• Monitora i cache miss in Vercel Analytics o nel tuo Prometheus.

Errori tipici e compromessi architetturali

Molti team cadono nell'errore “ISR‑by‑default”, che porta a servire dati obsoleti inconsapevolmente. La soluzione è implementare webhook che chiamano unstable_revalidate dopo ogni modifica al database.

Un altro compromesso è fare eccessivo affidamento sulla cache CDN per componenti dinamici. In questi casi è consigliabile separare parte dell'UI in client‑side rendering (CSR) e mantenere lo scheletro statico generato da ISR.

In sintesi, la scelta tra Next.js Incremental Static Regeneration e SSR dovrebbe basarsi sull'analisi della frequenza di aggiornamento dei contenuti, dei requisiti SEO e del carico previsto. Con una strategia di caching consapevole e una corretta segmentazione del codice, è possibile ottenere risparmi significativi e migliorare l'esperienza utente.

Se hai bisogno di assistenza per ottimizzare l'architettura di Next.js o per migrare da SSR a ISR, il nostro team di Coderia.it è pronto a supportare il tuo progetto – contattaci oggi stesso.