Next.js o Astro: quale scegliere per il tuo sito

Devi costruire un sito e la scelta si è ristretta a due nomi che sembrano fare la stessa cosa: entrambi generano pagine statiche, entrambi fanno rendering lato server, entrambi vanno benissimo per la SEO. La differenza però esiste, è profonda, e riguarda una sola domanda: quanto JavaScript arriva al browser di chi visita. In questo articolo trovi quella differenza spiegata bene e quale scegliere in base a cosa stai costruendo.

La differenza di fondo

Next.js parte dal presupposto che la pagina sia un'applicazione e poi cerca di alleggerirla; Astro parte dal presupposto che sia un documento e aggiunge interattività solo dove la chiedi.

È una differenza di punto di partenza, e da lì discende tutto il resto.

Next.js è un meta-framework su React. Anche quando genera HTML statico, quell'HTML viene poi "idratato": il browser scarica React, ricostruisce l'albero dei componenti e riattacca gli eventi. La pagina diventa un'applicazione React anche se mostra solo un articolo.

Astro genera HTML e basta. Per impostazione predefinita non spedisce JavaScript al browser — zero. Se ti serve un componente interattivo, lo dichiari esplicitamente e solo quello viene idratato. È l'architettura a isole: isolotti di interattività in un mare di HTML statico.

La conseguenza pratica è semplice: su un blog, una vetrina o una documentazione, Astro manda al browser una frazione del codice che manda Next.js, a parità di risultato visibile.

Quanto pesa davvero

Vale la pena essere concreti, perché è il punto che decide.

Una pagina di articolo fatta con Next.js spedisce il runtime di React, il runtime del framework e il codice dei componenti — anche se l'utente deve solo leggere. Su una connessione mobile lenta quel costo si sente nel tempo che passa prima che la pagina diventi utilizzabile.

La stessa pagina in Astro spedisce HTML e CSS. Se c'è un menu che si apre, arriva il codice del menu e nient'altro.

Questo incide direttamente sui Core Web Vitals, in particolare sulla reattività ai primi input: meno codice da elaborare significa una pagina che risponde prima.

Ma attenzione a non trarne la conclusione sbagliata. Su un'applicazione vera — una dashboard, un gestionale, qualcosa con stato che cambia di continuo — quel JavaScript ti serve comunque. Lì il vantaggio di Astro svanisce, perché staresti ricostruendo a mano ciò che Next.js ti dà già pronto.

Cosa cambia scrivendo il codice

Con Astro scrivi componenti .astro che somigliano a HTML con un blocco di codice in cima. Il codice gira in fase di costruzione, non nel browser:

---
const articoli = await fetch('https://api.esempio.it/articoli').then(r => r.json());
---
<ul>
  {articoli.map(a => <li>{a.titolo}</li>)}
</ul>

Niente hook, niente stato, niente effetti: è un template che produce HTML.

Quando serve interattività, porti un componente di un framework vero e dichiari quando idratarlo:

<Contatore client:load />     <!-- subito -->
<Ricerca client:visible />    <!-- quando entra nello schermo -->
<Grafico client:idle />       <!-- quando il browser è libero -->

client:visible è la direttiva che fa la differenza più concreta: un componente pesante in fondo alla pagina non costa nulla finché nessuno ci arriva.

E una cosa che Astro fa e gli altri no: puoi mescolare framework. React per un componente, Vue per un altro, nella stessa pagina. Utile in migrazione, meno in un progetto nuovo.

Con Next.js scrivi React ovunque, e la distinzione tra Server Component e Client Component gioca un ruolo simile — ma resti dentro l'ecosistema React, e il runtime arriva comunque al browser per le parti client.

Il confronto

	Next.js	Astro
JavaScript predefinito	Il runtime React	Zero
Punto di partenza	Applicazione	Documento
Interattività	Ovunque, nativa	Solo dove la dichiari
Più framework insieme	No	Sì
Contenuti da file Markdown	Possibile	Integrato e ottimo
Applicazioni complesse	Sì	Fa attrito
Ecosistema e lavoro	Molto più grande	Piccolo
Curva di apprendimento	Media	Bassa se sai HTML

Cosa scegliere

Blog, sito vetrina, documentazione, portfolio, landing page → Astro. È il terreno per cui è stato costruito, e il vantaggio in prestazioni è reale e misurabile.

Dashboard, gestionale, area riservata, applicazione con molto stato → Next.js. Astro qui rema contro il proprio progetto.

E-commerce → dipende da dove sta la complessità. Catalogo e schede prodotto stanno benissimo in Astro; un carrello e un checkout elaborati stanno meglio in Next.js. La via ibrida — catalogo statico, checkout su un servizio dedicato — funziona più spesso di quanto si pensi.

Sito con contenuti oggi, che forse diventerà un'applicazione → Next.js, ma con onestà: quel "forse" spesso non arriva mai, e nel frattempo paghi complessità. Astro ha il rendering lato server e le API, quindi non è un vicolo cieco.

Cerchi lavoro come sviluppatore → Next.js, senza discussione. Il mercato italiano chiede React e Next; Astro è una competenza in più, non un sostituto. È lo stesso ragionamento fatto in React, Vue o Angular.

Il team conosce già React ma il progetto è un sito di contenuti → Astro comunque. Si impara in un pomeriggio e i componenti React esistenti si possono riusare come isole.

Errori comuni

Scegliere Astro e poi idratare tutto. Mettere client:load su ogni componente riproduce esattamente il problema che Astro doveva risolvere, con in più un framework che non conosci bene. Se ti accorgi di farlo, la risposta giusta era Next.js.

Scegliere Next.js per un blog e poi inseguire le prestazioni. Passare settimane a ottimizzare il bundle di un sito che avrebbe potuto non averne uno è lavoro speso male — vedi come velocizzare un sito.

Credere che Astro sia solo per siti statici. Ha rendering lato server, rotte API e funziona con i contenuti dinamici. La differenza è nel valore predefinito, non nelle possibilità.

Ignorare da dove arrivano i contenuti. Se il sito vive su un CMS con anteprime in tempo reale e redattori che pubblicano di continuo, verifica l'integrazione prima di decidere: è un vincolo che pesa più della scelta del framework.

Confrontare i due sul rendering. SSG, SSR e ISR li fanno entrambi: i modelli di rendering non sono il criterio distintivo. La quantità di JavaScript lo è.

In sintesi

Entrambi producono siti veloci e ben indicizzabili. La differenza è cosa arriva al browser.

Astro spedisce zero JavaScript finché non lo chiedi; Next.js porta React con sé. Su un sito di contenuti questo è un vantaggio netto per Astro. Su un'applicazione è irrilevante, perché quel codice ti serve comunque.

La domanda che risolve la scelta: questa pagina è un documento o un'applicazione? Se l'utente legge e clicca qualche link, è un documento. Se manipola dati e lo stato cambia di continuo, è un'applicazione.

E se stai scegliendo anche in funzione del lavoro, Next.js resta la competenza che il mercato chiede — un fattore che pesa più delle differenze tecniche.

Per il funzionamento dei due singolarmente: cos'è Next.js e Astro per i siti di contenuti. Per inquadrare la scelta nel progetto completo, vedi come scegliere lo stack per una web app.