Perché Astro

Il modello: HTML prima, JavaScript dopo

Astro genera pagine statiche e, per default, non spedisce JavaScript. L’interattività è confinata nelle isole: componenti idratati solo dove serve.

Per un sito vetrina questo è quasi sempre il modello giusto:

• il contenuto è lo stesso per tutti (non serve renderizzare per utente);
• la SEO vuole HTML e contenuti reali, non un <div id="root"> vuoto;
• il tempo di caricamento percepito dipende da HTML, CSS e immagini, non dal framework.

Cosa usiamo di Astro

Funzione	Uso nel template
Output statico	tutto il sito è pre-renderizzato
Content Layer + loader custom	collezioni popolate da WordPress con Zod
Isole client:*	Preact solo per form, filtri, carousel, consenso, mappa
View Transitions	transizioni leggere tra pagine
Integrazioni	sitemap, icon (lucide/simple-icons), Preact
@fontsource	font self-hosted, nessuna chiamata a Google Fonts

Perché non Next.js, Nuxt o una SPA

Non è una questione di gusto: cambia cosa devi gestire.

• Hosting: una SPA/SSR richiede un runtime Node o un servizio che lo simuli. Qui basta spazio FTP o una CDN.
• SEO: con il rendering statico non devi dimostrare ai crawler che la pagina esiste.
• Superficie: niente route server, niente sessioni, niente API pubbliche da proteggere.
• Complessità: meno concetti da spiegare al prossimo sviluppatore.

Next.js sarebbe la scelta giusta per un’app con login, dati per utente, ISR e preview editoriali spinte. Non è questo il caso.

Perché un CMS headless e non un tema WordPress

Un tema classico è più veloce da avviare e più lento da difendere nel tempo:

• ogni funzionalità diventa un plugin (o codice PHP) dentro il sito pubblico;
• performance e accessibilità dipendono da ciò che il tema stampa;
• lo stile è intrappolato in PHP/CSS mescolati;
• il frontend non è testabile come un’applicazione moderna.

Con il CMS headless:

• WordPress resta un backoffice, isolato;
• il frontend è codice TypeScript testabile;
• il contratto dati è esplicito (schema Zod) e versionato;
• il sito pubblico è solo file statici.

Il prezzo: nessun page builder, preview assente, rebuild necessario. Documentato in Perché questo template.

Preact per le isole

Le isole sono piccole e senza dipendenze di stato globale. Preact offre le stesse API di React con un peso molto minore; il componente viene idratato solo quando serve.

<ContactForm client:visible />
<CookieBanner client:load />

• client:visible → idrata quando entra in viewport (form, filtri, carousel).
• client:load → idrata subito (banner cookie, che deve comparire senza scroll).

Se un componente non ha stato o eventi, non deve essere un’isola: resta Astro.

Tailwind 4 + token

Tailwind non è usato come “CMS di classi”: i colori passano da token semantici (bg-bg, text-fg, bg-accent). Questo permette di cambiare brand senza toccare i componenti. Dettagli in Design system.

Astro 7: due cose da sapere

1. La config deve essere un oggetto statico. La forma defineConfig(({ mode }) => ({ ... })) non viene invocata: le opzioni dentro la funzione vanno perse (compreso vite.plugins, quindi Tailwind smette di funzionare). Le env di config si leggono con loadEnv() fuori da defineConfig.
2. Node ≥ 22.23.4. La CI usa Node 24. Con Node 22.23.3 Astro si rifiuta di partire.

Quando NON usare questo stack

• Area riservata, login, ruoli e permessi.
• Ricerca full-text lato server o filtri su grandi dataset.
• Contenuti che devono cambiare senza rebuild.
• Applicazioni con stato condiviso e real-time.

In quei casi serve SSR (Astro con adapter o un altro framework), oppure un’altra scelta di prodotto. Non forzare il template.