nextjs.org

Next.js è un framework React per creare applicazioni web full-stack. React fornisce il modello a componenti per le interfacce utente; Next.js aggiunge routing, rendering, convenzioni per l'accesso ai dati, funzionalità server, compilazione, bundling, memorizzazione nella cache e strumenti orientati alla produzione.

L'argomento principale è il framework, non il suo dominio. nextjs.org è il sito ufficiale nel quale i visitatori possono trovare documentazione aggiornata, guide, collegamenti alla community e informazioni sul progetto.

Next.js è particolarmente rilevante quando un team vuole sviluppare con React offrendo più di un'interfaccia eseguita soltanto nel browser. Un singolo progetto può contenere pagine prerenderizzate, risposte generate al momento della richiesta, accesso ai dati lato server, endpoint in stile API e componenti interattivi eseguiti nel browser.

Cosa aggiunge Next.js a React

React aiuta gli sviluppatori a descrivere le interfacce come componenti, ma non prescrive un'architettura applicativa completa. Next.js fornisce convenzioni per associare i file alle route, decidere dove viene eseguito il codice, caricare i dati, produrre risposte e preparare un'applicazione per la distribuzione.

Il suo valore è quindi più ampio del rendering lato server. Un'applicazione Next.js può utilizzare vari metodi di rendering e distribuzione, talvolta all'interno dello stesso progetto. Il framework coordina questi metodi attorno a React anziché imporre a ogni route un unico modello.

Una sintesi utile di questa suddivisione è:

• React definisce componenti, stato, props e composizione dell'interfaccia.
• Next.js definisce route, layout, scelte di rendering, punti di ingresso server e comportamento della build.
• L'applicazione definisce le proprie regole sui dati, i confini client, la politica della cache e i requisiti di distribuzione.
• L'ambiente di hosting determina quali funzionalità di runtime sono disponibili e come operano.

Questa distinzione è importante quando si confronta Next.js con un'applicazione React lato client, un generatore di siti statici o un altro framework web. Il framework offre un'ampia gamma di funzionalità, ma un progetto trae vantaggio soltanto da quelle che utilizza bene.

Componenti server e client

Nell'App Router, per impostazione predefinita layout e pagine sono Server Components. I Server Components vengono eseguiti in un ambiente server e possono svolgere operazioni sui dati lato server senza inviare al browser l'implementazione del componente.

I Client Components vengono utilizzati quando una parte dell'interfaccia richiede stato nel browser, gestori di eventi, effetti o API disponibili soltanto nel browser. Gli sviluppatori definiscono un confine client con la direttiva use client e i componenti sottostanti a quel confine entrano a far parte del grafo dei moduli lato client.

Domanda	Server Component	Client Component
Dove viene eseguita la logica del componente?	Nell'ambiente di rendering server	Nel browser dopo essere stata inclusa nel bundle client
Può utilizzare lo stato del browser o gestori dei clic?	No	Sì
Può utilizzare direttamente API disponibili soltanto nel browser?	No	Sì
Il codice del componente viene inviato al browser?	Non come codice di un componente client	Sì
Ruolo tipico	Contenuti basati sui dati, layout e composizione lato server	Moduli, menu, editor, filtri e altri controlli interattivi

Una route non deve scegliere esclusivamente un solo tipo. Un Server Component può eseguire il rendering dei contenuti e comporre Client Components selezionati per le parti interattive della pagina. Questo consente ai team di collocare JavaScript per il browser attorno a esigenze specifiche, anziché trattare l'intera route come un'applicazione client.

Il confine richiede comunque attenzione. Spostare un grande sottoalbero di componenti dietro use client può inviare più JavaScript al browser, mentre suddividere ogni piccolo controllo in un confine separato può rendere più difficile comprendere il codice. Le pagine rappresentative dovrebbero essere misurate anziché giudicate soltanto in base all'etichetta del framework.

I Server Components sono inoltre distinti dalla strategia di distribuzione di una route. Un Server Component può contribuire a un output prerenderizzato o partecipare al rendering dinamico. Definire un componente come lato server non indica, di per sé, se la route venga generata durante una build, aggiornata in seguito o prodotta per ogni richiesta.

App Router e Pages Router

Next.js documenta attualmente due sistemi di routing. L'App Router è il sistema più recente e integra funzionalità di React come i Server Components. Il Pages Router è il sistema precedente e continua a essere supportato.

Area	App Router	Pages Router
Struttura principale delle route	La directory app	La directory pages
Modello di componente predefinito	Layout e pagine sono Server Components	Utilizza il precedente modello di pagina di Next.js
Interfaccia condivisa	I layout annidati sono una convenzione centrale	Comunemente composta attraverso pattern dell'applicazione e delle pagine
Punto di partenza ideale	Nuovi progetti che adottano l'architettura attuale	Applicazioni esistenti o dipendenze costruite attorno alle API del Pages Router

Una migrazione non consiste soltanto nel rinominare le cartelle. Il codice dell'App Router introduce un modello di componenti orientato innanzitutto al server e pattern diversi per layout, accesso ai dati, stati di caricamento e comportamento delle route. I team dovrebbero individuare questi cambiamenti concettuali prima di convertire un'applicazione matura.

I nuovi progetti dovrebbero generalmente consultare per prima la documentazione dell'App Router, perché descrive il modello attuale del framework. Le applicazioni esistenti basate sul Pages Router dovrebbero valutare la migrazione in base a vantaggi effettivi, dipendenze, impegno necessario per i test e costi di manutenzione, anziché considerare il supporto continuato come un difetto.

Documentazione ed esempi potrebbero riferirsi a un solo router. Prima di copiare un'implementazione, gli sviluppatori dovrebbero verificare quale router utilizza e se le API citate siano applicabili al loro progetto.

Rendering, cache e riconvalida

Next.js non esegue il rendering di ogni pagina nello stesso modo. Una route può essere preparata prima dell'arrivo di un visitatore, generata utilizzando informazioni specifiche della richiesta, memorizzata nella cache oppure aggiornata secondo una politica di riconvalida.

Esigenza della route	Probabile approccio di distribuzione	Domanda da verificare
Gli input sono noti in anticipo	Output prerenderizzato	Quale evento dovrebbe causare la modifica dell'output?
L'output dipende da cookie, header o dati della richiesta	Rendering dinamico	Una parte del lavoro può comunque essere memorizzata nella cache in sicurezza?
Il contenuto cambia secondo una pianificazione controllata	Output memorizzato nella cache con riconvalida	Quanto può diventare obsoleta la risposta?
Non sono necessarie funzionalità disponibili soltanto sul server	L'esportazione statica può essere adatta	Tutte le route e le risorse sono compatibili con i limiti dell'esportazione?

La memorizzazione nella cache non è un singolo interruttore che può essere compreso indipendentemente dall'accesso ai dati. I team devono sapere quali operazioni vengono memorizzate nella cache, quali route diventano dinamiche e come avvengono l'invalidazione o la riconvalida. Queste regole dovrebbero essere testate con modifiche realistiche ai contenuti.

Questo è particolarmente importante per pagine autenticate, prezzi, inventari, dashboard e altre informazioni con requisiti espliciti di aggiornamento. Servire output memorizzato nella cache può essere utile, ma soltanto quando le regole di correttezza dell'applicazione lo consentono.

Le prestazioni e la visibilità nei motori di ricerca non dovrebbero essere dedotte soltanto dall'etichetta del rendering. Il prerendering può ridurre il lavoro al momento della richiesta e il rendering server può fornire HTML iniziale significativo, ma i risultati effettivi dipendono dalla struttura della pagina, dalle risorse, dalla latenza dei dati, dal JavaScript eseguito nel browser, dalla cache e dal comportamento della distribuzione.

Esportazione statica e requisiti di runtime

Next.js può generare un'esportazione statica quando il progetto non dipende da funzionalità del framework disponibili soltanto sul server. I file HTML, CSS, JavaScript e le risorse risultanti possono essere serviti da un'infrastruttura che supporta normali file statici.

L'output statico può comunque includere Client Components. La distribuzione statica descrive come viene ospitato il risultato della build; non significa che ogni interfaccia debba essere priva di interattività. Il codice lato browser può comunque fornire stato, eventi e altri comportamenti client.

Prima di scegliere l'esportazione statica, verifica che il progetto non richieda:

• Risposte generate da dati server specifici della richiesta.
• Comportamenti delle route che dipendono da un runtime Next.js attivo.
• Funzionalità non supportate per immagini, routing o server.
• Regole di aggiornamento che non possono essere rispettate ricostruendo il progetto o mediante un altro processo di aggiornamento supportato.
• Endpoint server che devono essere eseguiti insieme all'applicazione.

Quando queste funzionalità sono necessarie, l'applicazione richiede un runtime compatibile. Ciò non impone la distribuzione su Vercel: la guida ufficiale alla distribuzione documenta il self-hosting e gli adattatori per le piattaforme. Il supporto varia a seconda della piattaforma, quindi la compatibilità dovrebbe essere verificata rispetto alle specifiche funzionalità utilizzate.

Route Handlers ed endpoint lato server

Nell'App Router, i Route Handlers consentono a un'applicazione di definire gestori delle richieste HTTP utilizzando i concetti standard di richiesta e risposta. Sono utili per gli endpoint che appartengono all'applicazione, inclusi l'elaborazione dei moduli, i webhook, le risposte contenenti dati o i callback delle integrazioni.

Un Route Handler non è automaticamente la sede corretta per ogni sistema backend. I team dovrebbero comunque decidere come gestire autenticazione, autorizzazione, convalida, limiti di frequenza, attività durevoli e gestione degli errori. I servizi di lunga durata o scalabili in modo indipendente potrebbero essere separati più opportunamente dall'applicazione web.

Una valutazione pratica pone queste domande:

1. L'endpoint deve accedere al codice dell'applicazione o a tipi condivisi?
2. Richiede segreti al momento della richiesta o dipendenze disponibili soltanto sul server?
3. La piattaforma di distribuzione scelta può eseguire il gestore come documentato?
4. Quale comportamento della cache è corretto per ciascun metodo HTTP e ciascuna risposta?
5. Un servizio separato offrirebbe una proprietà o una scalabilità più chiare?

I Route Handlers rendono pratica la composizione full-stack, ma la praticità non elimina le normali responsabilità relative alla progettazione e alla sicurezza delle API.

Quando Next.js è una scelta pratica

Next.js è un candidato valido per i team che hanno già familiarità con React e necessitano di routing applicativo e funzionalità server nella stessa base di codice. Può inoltre essere adatto a prodotti nei quali route diverse presentano esigenze di distribuzione sostanzialmente differenti.

Gli utilizzi comuni includono:

• Aree account e dashboard con dati server e controlli interattivi.
• Esperienze commerciali o cataloghi che combinano contenuti stabili con informazioni dipendenti dalla richiesta.
• Siti di documentazione o marketing che includono anche flussi di lavoro applicativi.
• Prodotti che necessitano insieme di risposte HTML, interazione client ed endpoint server.
• Applicazioni React le cui route traggono vantaggio da politiche separate di cache e rendering.

Il framework può rappresentare un'infrastruttura più complessa di quanto richiesto da un semplice sito di contenuti. Un team che pubblica principalmente articoli statici dovrebbe confrontare le proprie esigenze con strumenti incentrati sulla distribuzione di contenuti, specialmente se soltanto una piccola parte del sito richiede interazione React.

Next.js può inoltre essere poco adatto quando il team non può supportarne i requisiti di runtime, non desidera concetti di rendering specifici del framework oppure avrebbe difficoltà a mantenere chiari i confini tra server e client. La flessibilità è preziosa soltanto quando l'architettura rimane comprensibile.

Confronto tra Next.js, Astro e altre opzioni

Next.js e Astro vengono spesso valutati per progetti che combinano contenuti ed elementi interattivi, ma le loro impostazioni predefinite e i loro modelli mentali sono differenti. La scelta appropriata dipende dalle route effettive, non dall'affermazione generica che un framework sia più veloce o migliore.

Per un confronto utile, crea la stessa pagina rappresentativa con ogni candidato e registra:

• Quanto JavaScript raggiunge il browser prima e dopo l'interazione.
• Come vengono caricati i dati e come ne viene controllato l'aggiornamento.
• Se sono necessarie funzionalità di runtime server.
• Come vengono implementati routing, layout, moduli e stati di errore.
• Se l'host scelto supporta ogni funzionalità necessaria.
• Quanto facilmente il team riesce a testare e spiegare l'architettura risultante.

Astro merita particolare considerazione per i siti incentrati sui contenuti, nei quali la maggior parte dell'output può rimanere statica e le isole interattive sono limitate. Next.js diventa più convincente quando React è il modello applicativo centrale e le funzionalità server e client devono essere composte in tutto il prodotto.

Nessuno dei due confronti predice un punteggio prestazionale. Immagini, font, script di terze parti, scelte dei componenti, latenza dei dati e confini client possono avere un impatto maggiore delle impostazioni predefinite del framework.

Origini, governance e community

La pagina ufficiale sulla governance afferma che il team di Vercel ha creato Next.js nel 2016. Afferma inoltre che il team principale di Vercel guida la ricerca e lo sviluppo del progetto. Questa è una dichiarazione sull'origine e sulla governance a livello di team; non dovrebbe essere sostituita da un'affermazione non supportata riguardante un singolo fondatore.

Come documentato nelle pagine sulla governance e nella documentazione disponibili il 27 agosto 2026, i percorsi di partecipazione pubblica al progetto includono:

• Il repository GitHub ufficiale per codice sorgente, problemi e attività del progetto.
• GitHub Discussions per domande e discussioni della community sulle RFC.
• Il Discord di Next.js per il supporto gratuito della community.
• Documentazione aggiornata sia per l'App Router sia per il Pages Router.

Questi canali offrono tipi diversi di assistenza. La documentazione dovrebbe essere il primo riferimento per il comportamento del framework, Discussions può far emergere proposte e domande condivise e Discord può sostenere la conversazione nella community. Nessuno di essi sostituisce i test specifici del progetto o il processo di supporto in produzione di un team.

Una checklist decisionale

Prima di adottare Next.js, i team dovrebbero rispondere a queste domande con un prototipo funzionante:

• Quali route sono statiche, dinamiche, memorizzate nella cache o riconvalidate?
• Quali componenti richiedono davvero stato, effetti, eventi o API del browser?
• Quanto JavaScript client invia ogni route rappresentativa?
• Quali endpoint appartengono ai Route Handlers e quali dovrebbero trovarsi altrove?
• La piattaforma scelta può eseguire ogni funzionalità Next.js necessaria?
• Come verranno gestiti l'aggiornamento della cache, gli errori, i log e le distribuzioni?
• Il team comprende le differenze tra il router scelto e gli esempi scritti per l'altro router?

Next.js consiste nell'applicare React a un'applicazione web completa scegliendo consapevolmente dove viene svolto il lavoro e come viene distribuita ciascuna route. La sua flessibilità documentata è notevole, ma non garantisce prestazioni, risultati nei motori di ricerca, bassi costi operativi o semplicità architetturale. Questi risultati devono essere stabiliti attraverso l'implementazione e la misurazione.