Architettura del sito nel 2026: home come app, il resto statico

Un sito di marketing per SaaS sono due prodotti travestiti da uno. La home porta il peso della conversione. Il resto porta il peso della fiducia. Quasi tutti li costruiscono con la stessa architettura, poi si chiedono perché la home sembri lenta e il blog sovradimensionato.

La nostra divisione: la home si costruisce come una single-page app, con stato, interazione, budget di animazione. Tutto il resto (chi siamo, servizi, case study, blog, contatti, manifesto, pagine sullo stack) si serve come documento statico. Target di build diversi, percorsi di codice diversi, budget di prestazioni diversi.

Non è una scelta furba di framework. È una lettura di dove stanno davvero attenzione e intento su un sito SaaS.

I due default che si scelgono quasi sempre

Primo default: "tutto è una SPA". Si prende Next.js, si idrata ogni pagina, il blog usa lo stesso router lato client della dashboard. La home va bene. Il blog ha un INP di 400ms e un LCP che dipende da quanto è veloce la CDN nel servire un bundle JS. I crawler aspettano l'idratazione. Il team aggiunge complessità incrementale per riparare una decisione strutturale.

Secondo default: "tutto è statico". Si prende Astro o Hugo, si pre-renderizzano home, blog, case study, contatti. Il blog vola. La home sembra spenta. Le animazioni che il founder voleva diventano una battaglia contro il framework, non una sua funzione. Il team aggiunge complessità incrementale per riparare una decisione strutturale.

Entrambi i default trattano home e pagine-documento come lo stesso prodotto. Non lo sono.

La home è un'app. Il resto è un documento.

La home ha un lavoro preciso: prendere chi arriva da una ricerca Google, un link X, un podcast, una citazione di un motore AI, e portarlo verso un contatto. La decisione avviene in 8-15 secondi. Il design deve lavorare in quella finestra: hero animato, reveal allo scroll, una demo interattiva, una CTA consapevole dello stato che sa se sei già passato di qui.

Niente di tutto questo è teatro. È la superficie di conversione che si guadagna il proprio budget.

Il case study su /it/progetti/kibank fa un altro lavoro. Esiste per chi ha già visto la home, è entrato in un case study, e ora vuole tre informazioni: qual era il problema, cosa abbiamo rilasciato, cosa è cambiato. Quella persona vuole il testo che carica subito, immagini che non saltano, e una pagina che scorre senza animazioni a 60fps che le interrompono la lettura. Il case study è un documento.

L'articolo del blog che stai leggendo ora è anch'esso un documento. Esiste per essere citato da ChatGPT, indicizzato da Google, letto da un product owner davanti a un caffè. Ogni grammo di JavaScript su questa pagina è una tassa su quel lavoro.

Come si costruisce la divisione in Next.js 16

L'implementazione poggia su tre primitive che l'App Router offre gratis, se le imposti con criterio:

1. Statico per default, dinamico per opt-in. Le pagine-documento non esportano alcun segnale di rendering dinamico. Niente cookies(), niente headers(), nessun searchParams nel percorso di render. Vengono pre-renderizzate in build e servite da una CDN. Il TTFB scende sotto i 100ms sull'edge di Vercel.
2. Suspense come confine. La home usa Partial Prerendering, stabile da Next.js 16: una shell statica (nav, hero copy, footer) si renderizza all'istante, poi le parti dinamiche (contatore live di testimonianze, variante CTA in A/B test, stato signed-in) arrivano in streaming dietro a Suspense. La shell sta sulla CDN. Le parti dinamiche sul runtime.
3. Nessun client component sulle pagine-documento. Case study e articoli del blog non usano nemmeno un "use client". L'unico JavaScript che arriva al browser è il toggle del tema globale e il selettore di lingua. Sono isolati nell'header. Il corpo del documento non ha costo di idratazione.

La home può importare GSAP, Lenis per lo smooth scroll, e un'animazione hero che gira a ogni paint. Le pagine-documento no. Il vincolo si applica al livello di routing: qualunque cosa sotto app/[lang]/(public)/(docs)/ passa per un layout che non carica il runtime di animazione.

Perché questo salva numeri precisi

Le pagine-documento escono con un LCP intorno a 0.8s su una 4G veloce, un INP sotto gli 80ms (perché c'è quasi nulla con cui interagire) e un TTFB al pavimento della CDN. Le soglie Core Web Vitals 2026 (LCP sotto 2.5s, INP sotto 200ms, TTFB sotto 800ms) non sono un obiettivo da raggiungere: sono un pavimento sotto cui stiamo comodi. Della parte più ampia sui Vitals abbiamo scritto in Core Web Vitals su Next.js nel 2026.

La home porta di più. Target LCP 1.5s, target INP 150ms, e il budget di animazione più pesante è ammesso perché la shell si renderizza prima che si carichi qualunque cosa. La pagina sembra viva ma il primo paint utile non aspetta la timeline GSAP.

Per i siti di marketing SaaS, nel 2026 il benchmark competitivo per LCP si è stretto da 2.5s a sotto i 2.0s. Dividere l'architettura è una delle poche mosse che ti ci portano senza toccare i contenuti.

Dove le pagine-documento rilanciano verso l'app

La trappola di questa divisione è trattare le pagine-documento come di serie B. Non lo sono. Sono la superficie di citazione per i motori AI, la superficie di indicizzazione per Google, la superficie di lettura per chi non converte alla prima visita. Generano traffico long-tail che la home non può catturare, e alimentano la home con i link interni.

L'autorità scorre dalle pagine-documento alla home se dai documenti si linka verso la superficie di conversione. Senza questo pattern, un documento che si guadagna 400 backlink l'anno non passa equity interna alla pagina principale. Usiamo un blocco footer (renderizzato dal template, non dall'HTML dell'articolo) che da ogni documento riporta a una superficie "raccontaci cosa stai costruendo".

I trade-off che accettiamo

Questa divisione non è gratuita.

• Il design system deve essere solo CSS. Se la libreria di componenti spedisce primitive pesanti di JavaScript (un dropdown che si apre con uno state React, un date picker legato a un runtime), non le si possono usare nelle pagine-documento senza rompere la regola del no-hydration. Per la stessa ragione abbiamo tolto Tailwind dalla produzione: i token sono CSS variables, i componenti sono classi CSS, il budget JS è zero per default.
• Due percorsi di render sono due superfici di bug. Un'animazione che funziona sulla home non per forza funziona su una pagina-documento. Il team deve ricordare da che lato della linea sta.
• I boundary di Suspense si rompono. Se un server component fa fetch senza un wrapper Suspense, la shell statica non si renderizza finché non arrivano i dati. Partial Prerendering funziona solo se ogni fetch dinamico è confinato.
• Cerca e filtro sulle pagine-documento sono complicati. Un indice blog con ricerca live ha bisogno di un client component. L'eccezione la accettiamo: la search è un client component, ma vive nella sua isola e non idrata il corpo dell'articolo.

Quando non farlo

Se il sito è una landing singola senza blog, senza case study, senza documentazione, non dividerlo. Il costo di mantenere due render path è più alto del guadagno.

Se il sito è l'app SaaS in sé (tutto dietro login), non dividerlo. Il sito intero è un'app. Il rendering statico di una dashboard loggata è un problema diverso con una soluzione diversa, e lì conta di più la scelta tra edge e Node runtime.

La divisione si guadagna il peso quando hai una o due pagine di conversione ad alto valore (home, landing chiave, pricing) e una coda lunga di pagine di contenuto che esistono per informare, posizionare, farsi citare. È la forma modale di un sito di marketing SaaS nel 2026.

La versione corta

Un prodotto, due target di render, una convenzione di routing che fa rispettare la linea. La home si guadagna di essere un'app perché lo merita. Il resto del sito resta un documento perché è quello che il visitatore vuole davvero, ed è quello che Google e i motori AI premiano.