Astro vs Next.js per un sito di contenuti: la domanda è quanto JavaScript ti serve

Questo pezzo è per chi deve scegliere il framework di un sito di contenuti: un blog, una documentazione, un sito marketing, un magazine. È un confronto costruito sulla documentazione ufficiale di Astro e Next.js, letta il 26 ottobre 2026. Nessun test o benchmark: dove servono numeri, rimando alle fonti.

Le versioni di riferimento su npm, lo stesso giorno: astro 7.4.2, next 16.4.3, @astrojs/cloudflare 14.4.2.

In breve:

• Per un sito di contenuti la domanda non è "quale framework è più veloce". È: quanto JavaScript serve davvero nel browser del lettore.
• Astro manda zero JavaScript per default. Ogni componente interattivo è un'isola che attivi tu, con una direttiva client:*.
• Next.js parte dai Server Components, che riducono il JavaScript inviato. Ma il sito resta un'app React: c'è l'idratazione dei Client Components, c'è la navigazione lato client con prefetch.
• Per i contenuti Astro ha le content collections, con schema e validazione. Next.js documenta MDX con @next/mdx, che non supporta il frontmatter senza plugin.
• Next.js dà il meglio con un server Node.js, Docker o un adapter verificato (oggi Vercel e Bun). Un sito Astro statico è una cartella di file che va ovunque.
• Se il sito è soprattutto un'app, con login, dashboard e stato condiviso tra pagine, Next.js resta la scelta onesta.

La domanda giusta: contenuti o app

La pagina "Why Astro?" della documentazione mette la distinzione al primo posto. Astro è pensato per siti guidati dai contenuti: blog, marketing, documentazione, portfolio, e-commerce. La stessa pagina descrive gli altri framework moderni, Next.js incluso, come pensati per applicazioni web: dashboard con login, inbox, social network.

È la presentazione di un vendor, quindi va letta come tale. Ma la distinzione regge anche senza fidarsi del marketing. Non "Astro o Next.js?". È: le tue pagine si leggono o si usano?

Una pagina che si legge ha bisogno di HTML, CSS, immagini e qualche widget: un menu mobile, una ricerca, un modulo. Una pagina che si usa ha stato, sessioni, aggiornamenti continui. La quantità di JavaScript che serve nel browser segue da lì. E il JavaScript è il punto dove i due framework partono da premesse diverse.

Astro: zero JavaScript, poi isole dove servono

La documentazione sulle isole è esplicita. I componenti Astro diventano HTML statico, senza runtime lato client. Anche un componente React dentro una pagina Astro, per default, viene reso solo in HTML e CSS: il JavaScript viene tolto.

Per renderlo interattivo aggiungi una direttiva:

---
import Search from '../components/Search.jsx';
---
<!-- Solo HTML: nessun JavaScript inviato -->
<Search />

<!-- Isola interattiva: Astro carica il JavaScript di questo componente -->
<Search client:visible />

Le direttive decidono anche quando caricare il codice: client:load subito, client:idle quando il browser è libero, client:visible quando il componente entra nello schermo. Ogni isola è indipendente dalle altre. Nella stessa pagina puoi avere un'isola React e una Svelte.

Esistono anche le server island, con server:defer. Servono per una parte personalizzata dentro una pagina altrimenti statica, per esempio l'avatar di chi ha fatto login. Secondo la guida al rendering on-demand, richiedono un adapter installato.

La conseguenza pratica: in Astro il JavaScript è una scelta che fai componente per componente. Se non scrivi client:*, non parte niente.

Next.js: Server Components, ma resta un'app React

Next.js è andato nella stessa direzione per un'altra strada. Nell'App Router, secondo la guida Server and Client Components, layout e pagine sono Server Components per default. Tra i motivi per usarli la documentazione cita proprio la riduzione del JavaScript inviato al browser.

Il confine si mette con "use client" in cima a un file. Da lì in giù, tutto quello che il file importa finisce nel bundle client. Un "use client" messo troppo in alto, per esempio nel layout, porta nel bundle mezzo albero di componenti.

Il modello però resta quello di un'applicazione. Al primo caricamento la documentazione descrive tre passaggi: l'HTML per l'anteprima, il payload RSC per riconciliare gli alberi, il JavaScript per idratare i Client Components. Nelle navigazioni successive, spiega la guida Linking and Navigating, <Link> fa prefetch delle route quando entrano nello schermo e la transizione avviene lato client.

Per un'app è esattamente quello che vuoi: navigazione istantanea, stato che sopravvive al cambio pagina. Per un articolo che si legge dall'inizio alla fine è lavoro che il browser fa comunque, anche quando il lettore apre una pagina sola.

Dove vivono i contenuti

Qui la differenza è di attrezzatura, non di filosofia.

Astro ha le content collections. Una collection è un insieme di contenuti con la stessa forma: una cartella di Markdown, un file JSON, oppure dati presi da un CMS o da un'API. Un loader li carica, uno schema opzionale li valida e dà i tipi TypeScript. I loader forniti leggono Markdown, MDX, Markdoc, YAML, TOML e JSON. Le live collections, stabili da Astro 6, leggono i dati a ogni richiesta invece che al build.

Next.js documenta i contenuti nella guida Markdown e MDX. Con @next/mdx le pagine .mdx vivono nella cartella app/, ed è possibile anche caricare MDX remoto lato server. La guida precisa che @next/mdx non supporta il frontmatter per default: suggerisce plugin come remark-frontmatter o librerie come gray-matter, oppure gli export di MDX. Schema e validazione dei metadati li costruisci tu.

Con un CMS headless la distanza si accorcia. In entrambi i casi chiami un'API e rendi i dati sul server. Resta il fatto che Astro ha un contratto per i contenuti già pronto, Next.js no.

Cache e pagine dinamiche: la novità è da tutte e due le parti

Un sito di contenuti non è sempre tutto statico. Commenti, prezzi, pagine che cambiano spesso: prima o poi serve rendere qualcosa a richiesta e metterlo in cache. Qui i due framework si sono mossi di recente.

Astro 7, uscito il 22 giugno 2026, ha reso stabile il route caching. Imposti un provider di cache una volta, poi controlli la cache per risposta con Astro.cache.set() o per gruppi di route con routeRules. L'invalidazione passa da cache.invalidate(), per tag o per percorso, utile come webhook chiamato dal CMS. Astro 7 aggiunge anche provider CDN per Netlify, Vercel e Cloudflare, ancora sperimentali: la cache finisce sull'edge della piattaforma e le risposte in cache non invocano la funzione server.

// astro.config.mjs
import { defineConfig, memoryCache } from 'astro/config';

export default defineConfig({
  cache: { provider: memoryCache() },
  routeRules: {
    '/blog/[...path]': { maxAge: 300, swr: 60 },
  },
});

Next.js 16.4, del 6 ottobre 2026, raccomanda Cache Components per ogni app. Le nuove app create con create-next-app li hanno attivi per default, e il post annuncia che diventeranno il default in Next.js 17. Con 'use cache' marchi le parti dell'albero da mettere in cache; nella stessa pagina convivono parti statiche e parti rese a richiesta.

Per chi fa un sito di contenuti, 16.4 aggiunge un dettaglio utile: ensureStatic. Con export const ensureStatic = 'navigation' il build fallisce se un componente dinamico entra nella route. Il post lo presenta come un modo per evitare calcolo non voluto e costi server. È la protezione dal caso opposto a quello di Astro: in Next.js la pagina statica è una garanzia che chiedi, in Astro è il punto di partenza.

Deploy: cosa ti chiede ciascuno

Per default Astro prerenderizza tutto al build. Un sito interamente statico è una cartella dist/ di HTML, CSS e asset. Per il rendering a richiesta serve un adapter: quelli ufficiali sono Node.js, Netlify, Vercel e Cloudflare. Su Cloudflare, la guida Workers per Astro parte da npm create cloudflare@latest -- my-astro-app --framework=astro. Per un sito statico basta una configurazione Wrangler che punta assets.directory a ./dist.

La documentazione di deploy di Next.js mette in tabella le opzioni. Server Node.js e Docker supportano tutte le funzioni. La static export ha un supporto limitato. Gli adapter variano: quelli verificati, che girano la suite di test completa, oggi sono Vercel e Bun. Cloudflare e Netlify stanno lavorando ai loro adapter verificati.

La static export merita attenzione, perché sembra la risposta per un sito di contenuti. Con output: 'export' ottieni file statici da servire ovunque. Ma la guida elenca cosa perdi: route dinamiche senza generateStaticParams(), rewrites, redirects, headers, proxy, ISR, ottimizzazione immagini con il loader predefinito, Draft Mode, Server Actions. Per un blog senza queste funzioni va bene. Appena ne serve una, torni a un server.

Se il sito deve stare su Cloudflare Workers, la situazione di Next.js è nel pezzo su Next.js su Workers con OpenNext e vinext: funziona per molte app, ma la cache ISR la configuri tu. Per Astro il percorso è quello della guida per migrare un sito Astro da Pages a Workers.

Chi c'è dietro, e perché conta poco per un sito statico

Next.js è sviluppato da Vercel. Il 16 gennaio 2026 The Astro Technology Company è entrata in Cloudflare. Nello stesso annuncio il team ha scritto che Astro resta open source con licenza MIT e continua a supportare piattaforme diverse da Cloudflare, con governance e roadmap aperte.

Quindi entrambi i framework hanno ora un'azienda cloud dietro. Per un sito statico conta poco: una cartella di HTML si sposta su un altro host senza riscrivere codice. Conta quando usi le funzioni server, perché lì l'integrazione migliore tende a essere quella della casa. È il ragionamento del confronto Vercel vs Cloudflare vs VPS: il vincolo che decide è il lock-in, non il prezzo di partenza.

Astro vs Next.js per un sito di contenuti: il confronto

Quando Next.js è la scelta onesta

Il confronto non finisce sempre con Astro. Ci sono tre casi in cui Next.js ha più senso, anche per un sito con molti contenuti:

• Il sito è metà app. Area riservata, dashboard, carrello con stato tra pagine, editor. Se le pagine si usano più di quanto si leggano, il modello di Next.js lavora per te.
• Il team vive in React. Next.js è React fino in fondo, con Server Actions, streaming e un'unica toolchain. Con Astro scrivi anche componenti .astro e ragioni a isole.
• Il resto del prodotto è già Next.js. Se il sito marketing sta accanto all'app, un solo framework vuol dire un solo deploy, un solo design system e meno contesto da tenere a mente.

Il caso opposto è altrettanto chiaro. Blog, documentazione, landing, magazine: pagine che si leggono, pochi widget. Lì Astro ti dà per default quello che in Next.js devi proteggere.

Perché fnbit è su Astro

fnbit.net è un sito di contenuti e gira su Astro, con EmDash come CMS, su Cloudflare. È il caso da manuale descritto sopra: articoli che si leggono, qualche parte interattiva come le FAQ a fisarmonica. Il confronto tra CMS è in Strapi vs EmDash vs WordPress, lo stack sotto in Workers, D1 e R2.

Se Next.js te l'ha scelto l'agente

Molti siti di contenuti nascono su Next.js perché è lo stack che il modello propone per primo. Il pezzo sulla trappola dello stack di default spiega perché succede. Prima di accettare il template, fai la domanda di questo articolo: quante pagine del sito si usano, e quante si leggono?

Se la risposta è "si leggono quasi tutte", chiedi all'agente un progetto Astro. Poi scrivi la scelta nel file di contesto del progetto, AGENTS.md o CLAUDE.md: così non torna a proporti Next.js alla prossima modifica. Gli altri errori tipici di un progetto nato con un agente sono raccolti nell'hub Vibe coding.

Cosa conviene fare adesso

• Fai l'elenco delle pagine del sito e segna quelle con stato o login. Se sono poche, il sito è di contenuti.
• Elenca i widget interattivi veri: ricerca, menu, moduli, commenti. Sono le tue isole.
• Se sei già su Next.js, cerca i "use client" nei layout: portano nel bundle tutto quello che importano.
• Se usi la static export di Next.js, controlla la lista delle funzioni non supportate prima di aggiungere redirects o ISR.
• Su un progetto nuovo, prova npm create astro@latest e misura il JavaScript inviato dalle pagine con gli strumenti del browser, non con i benchmark di qualcun altro.

Astro e Next.js oggi coprono entrambi statico e dinamico. La differenza vera è il punto di partenza: Astro parte dalla pagina che si legge e aggiunge JavaScript, Next.js parte dall'app e toglie JavaScript dove può.