Perché scegliamo Next.js invece di Astro per i SaaS nel 2026

Next.js è un framework React full-stack che renderizza pagine, gestisce il routing ed esegue logica server in un unico processo. Astro è un content-first site builder che spedisce quasi zero JavaScript di default e idrata soltanto le isole che hanno davvero bisogno di interattività. Nel 2026 la domanda per un team SaaS non è quale dei due sia migliore in astratto. È quale dei due si adatta alla forma del prodotto che stai costruendo.

La maggior parte dei SaaS ha un'app autenticata al centro. Una dashboard, un pannello impostazioni, un workspace, un portale di fatturazione. Quelle schermate leggono e scrivono dati utente a ogni navigazione, mantengono stato fra componenti e dipendono da cookie di sessione che il server deve verificare a ogni richiesta. Next.js è stato progettato per questa forma. Astro riesce a coprirne una parte sorprendente tramite server islands, server actions e Sessions API, ma più ti avvicini alla superficie reale di un prodotto, più finisci per montare librerie che riempiono ciò che il framework non possiede. Quest'anno abbiamo spedito entrambi. Per un SaaS, Next.js resta la nostra scelta di default.

TL;DR

Scegli Next.js quando il sito è il prodotto. Scegli Astro quando il sito è contenuto attorno al prodotto. Se hai un solo codebase e quel codebase deve ospitare signup, login, dashboard e billing, Next.js è la risposta. Se hai un sito marketing separato fatto soprattutto di pagine, post, documentazione e pricing, Astro è più veloce e più economico da gestire. Il divario si sta allargando in entrambe le direzioni: Next.js detiene la quota dominante dei nuovi progetti React enterprise nel 2026, e Astro è stato acquisito da Cloudflare nel gennaio 2026, segnale di una scommessa seria sull'islands architecture per i contenuti (Alex Bobes, 2026).

Dove Next.js vince per i SaaS

Un solo repo per l'app e la sua API

Next.js 16 spedisce Turbopack come bundler di default sia per next dev sia per next build, e il React Compiler è stabile in produzione (Vercel, 2026). Il framework possiede rendering, routing, server actions, route handler, middleware ed edge function dentro un unico progetto. Per un SaaS questo conta perché lo stesso git push deploya la dashboard, il callback di auth, il webhook Stripe e l'endpoint di upload. Non c'è un secondo servizio da mantenere allineato, niente tipi condivisi che attraversano una rete, niente secondo pipeline di deploy.

Astro può ospitare route handler e ha aggiunto server action tipizzate nella versione 4.15 con validazione Zod integrata (Astro Actions). È capace, sul serio. Ma nel momento in cui ti serve un processo long-lived, una coda worker o un websocket, Astro ti spinge verso un runtime separato e la storia integrata si rompe.

Sessioni, autenticazione e middleware

I SaaS vivono di cookie di sessione. Il middleware di Next.js gira a ogni richiesta, può leggere e riscrivere cookie, può controllare lo stato di auth e può redirigere utenti anonimi a /login prima che qualunque pagina renderizzi. Il pattern è documentato e le librerie della community (NextAuth, Supabase Auth, Clerk, Lucia) assumono tutte questa superficie.

Astro ha aggiunto una Sessions API che salva dati lato server ed è disponibile dentro le action, e si integra con auth-astro e Better Auth. La fregatura è nella documentazione: le sessioni non sono supportate nel middleware edge e richiedono server-side rendering per funzionare. Se una pagina è prerenderizzata, i dati di sessione non sono disponibili (Astro Sessions). Per un SaaS questo significa che la maggior parte delle pagine, quelle che dipendono dall'utente, non può essere prerenderizzata. La cosa che rende Astro veloce sulle pagine marketing è esattamente quella che non puoi usare sull'app.

L'ecosistema React 19 atterra prima

Una dashboard SaaS tende ad appoggiarsi a TanStack Query, primitive headless UI, grafici, drag-and-drop, form complessi, file picker, rich text editor. Queste librerie assumono un singolo albero React. Next.js te lo dà nativamente. Astro può renderizzare isole React, e dentro un'isola puoi montare qualunque di queste librerie, ma ogni isola è un confine JavaScript a sé, e questo complica la condivisione di stato fra componenti della stessa pagina.

Concretamente: in una dashboard Next.js un filtro nella sidebar e un grafico si abbonano alla stessa cache di TanStack Query senza cerimonie. In Astro due isole non possono condividere uno stesso client React Query out of the box senza esportare un singleton da un modulo vanilla e collegare ogni isola.

Le novità React arrivano prima in Next.js

Next.js 16 include funzionalità di React 19.2 come View Transitions, useEffectEvent e Activity per tenere alberi in background montati ma nascosti. Il React Compiler è stabile e memoizza i componenti in automatico. Sono le funzionalità di cui beneficia una dashboard sotto carico, e atterrano in Next.js nel momento in cui si stabilizzano perché l'App Router segue il canary di React.

Dove Astro vince

Pagine marketing e pricing

Per una homepage, una pagina pricing, una griglia features, un form contatti, Astro è difficile da battere. L'output di default è HTML statico con zero JavaScript e idratazione selettiva tramite Islands architecture. Report di produzione collocano le pagine Astro intorno ai 18 KB di JavaScript contro i 180 KB di un setup Next.js equivalente carico di React, in funzione delle scelte di idratazione. Per i Core Web Vitals di un sito marketing quel divario conta.

Documentazione

La documentazione è un albero di contenuti con blocchi di codice, search e piccoli widget interattivi. È esattamente la forma per cui Astro è stato costruito. Starlight, lo starter ufficiale per la docs, ti dà search, sidebar nav, syntax highlighting e i18n out of the box, e il risultato è un sito statico che carica in meno di un secondo su una 3G.

Blog di contenuto

Per un blog di contenuto, le content collection di Astro più la Content Layer API di Astro 5 rendono Markdown e MDX cittadini di prima classe. Le Server Islands consentono di iniettare snippet personalizzati (carrello, foto profilo, variante A/B) in una pagina altrimenti completamente statica (Astro Server Islands). Il risultato è un blog che spedisce zero JavaScript su ogni articolo e resta in verde sui Core Web Vitals.

E un ibrido?

Il pattern che ricorre più spesso: sito marketing su Astro, app su Next.js, due deployment separati su sottodomini diversi (www e app). È un'architettura valida e l'abbiamo spedita. Il costo è reale:

• Due repository, due pipeline CI, due target di deploy, due set di variabili d'ambiente.
• Lo stato di autenticazione deve attraversare i sottodomini: cookie domain, CORS, redirect URL OAuth.
• Token di design e componenti primitivi vanno condivisi, di solito tramite un pacchetto npm privato.
• Analytics, feature flag, error reporting e observability girano due volte.

Per un team di due, l'overhead non vale i KB risparmiati sul marketing. Per un team di quindici con un team contenuti dedicato e un sito marketing che porta traffico organico vero, può valerne. Il trigger non è tecnico, è di forma del team.

Cosa usiamo e perché

Per il sito di Studio e per ogni SaaS spedito nel 2026 la risposta è Next.js. Le ragioni in ordine:

1. Un codebase, un deploy, un runtime. Le pagine marketing e l'app autenticata vivono sotto lo stesso router. Aggiungere una nuova rotta dashboard è un file in /app/dashboard. Aggiungere una nuova pagina pricing è un file in /app/pricing. Niente cuciture fra sottodomini.
2. La storia delle sessioni è chiusa. Il middleware gira a ogni richiesta, legge il cookie di auth e redirige gli utenti non autenticati prima del render. Sviluppatori junior lo estendono senza leggere il source del framework.
3. Le novità React 19 atterrano prima. View Transitions, React Compiler, server actions e le caching API raffinate (updateTag, revalidateTag) arrivano in Next.js il giorno in cui si stabilizzano.
4. Lo svantaggio, ovvero il bundle size sulle pagine marketing, lo mitighiamo con route segment che escludono i client component e con confini di componente disciplinati. Le nostre rotte marketing spediscono meno di 50 KB di JavaScript senza uscire da Next.js.

Se un cliente arriva con un sito a forte densità di contenuti (un centinaio di pagine di redazione strutturata, nessuna app autenticata), Astro è la risposta giusta e non lo spingiamo verso Next.js. La scelta del framework segue la forma del prodotto, non le nostre preferenze. Per qualunque cosa chiameremmo SaaS, la forma dice Next.js. Vedi anche le nostre note sul React Compiler in produzione e su Server vs Client Components per come strutturiamo quelle app Next.js nel quotidiano.

Nel 2026 entrambi i framework sono abbastanza maturi da rendere difendibile la scelta dell'uno o dell'altro. La domanda è quale problema stai risolvendo. SaaS significa app prima, contenuto poi. Quell'ordine rende Next.js il default più sicuro.