Da una SPA React ad Astro: quando e perché migrare

I siti web aziendali basati su applicazioni React a pagina singola erano una scelta architetturale ragionevole nel 2018. React era il framework front-end dominante, i bundler miglioravano rapidamente e i vantaggi per gli sviluppatori rispetto agli approcci con rendering lato server sembravano significativi. A distanza di diversi anni, molti di quegli stessi siti ottengono risultati deludenti sulle metriche che incidono davvero sui risultati aziendali: Core Web Vitals, posizionamento nei motori di ricerca e tempo necessario per mostrare i primi contenuti significativi agli utenti con connessioni limitate.

La migrazione da una SPA React ad Astro non è una sostituzione integrale del framework. Significa riconsiderare il ruolo di JavaScript in un sito di marketing o aziendale e chiedersi se l’ipotesi di partenza — che ogni pagina abbia bisogno di un runtime completo lato client — sia mai stata corretta per questo tipo di applicazione.

Perché le SPA React penalizzano le prestazioni dei siti aziendali

Le prestazioni di una SPA React derivano dal suo modello di rendering. Quando un utente richiede una pagina, il server restituisce una struttura HTML minima con riferimenti ai bundle JavaScript. Il browser scarica i bundle, analizza ed esegue il JavaScript, esegue il rendering dell’albero dei componenti e infine mostra il contenuto. Su connessioni veloci con risorse già in cache, questo processo può essere impercettibile. Sulle reti mobili o alla prima visita, quando non ci sono risorse in cache, il ritardo tra la richiesta e la comparsa di contenuti significativi si misura in secondi.

I Core Web Vitals di Google rendono misurabili questi ritardi. Il Largest Contentful Paint misura quando viene visualizzato l’elemento visibile più grande: per una SPA React che carica una sezione introduttiva o i contenuti visibili senza scorrere, questo avviene di solito dopo il completamento dell’esecuzione JavaScript. Anche il First Contentful Paint, una metrica di supporto che non rientra nei tre Core Web Vitals (LCP, INP e CLS), subisce un ritardo. In pratica, le SPA React che servono principalmente contenuti statici di marketing registrano regolarmente valori LCP nelle fasce «da migliorare» o «scadente», non perché i contenuti siano pesanti, ma perché il percorso di rendering è inutilmente complesso.

Le implicazioni SEO aggravano il problema delle prestazioni. I crawler dei motori di ricerca hanno migliorato notevolmente la capacità di eseguire il rendering JavaScript, ma l’HTML prerenderizzato resta più affidabile per l’indicizzazione. Il budget di scansione limita quanto un crawler può elaborare a ogni visita; le pagine che richiedono l’esecuzione JavaScript per mostrare i contenuti vengono trattate diversamente da quelle in cui i contenuti sono subito disponibili nella risposta HTML. Per un sito aziendale in cui la visibilità organica è direttamente correlata alla generazione di contatti commerciali, questa distinzione conta.

Cosa cambia con Astro

L’output predefinito di Astro è HTML statico (il rendering lato server su richiesta è disponibile, ma va attivato esplicitamente). In fase di compilazione, le pagine vengono generate come file che un server web può servire direttamente, senza eseguire JavaScript per mostrare i contenuti. Chi richiede la homepage riceve un documento HTML completo, con testo, dati strutturati e metadati già presenti: il browser lo visualizza immediatamente.

I miglioramenti delle prestazioni derivanti da questo cambiamento architetturale sono facili da misurare. L’LCP migliora perché l’elemento di contenuto più grande è presente nella risposta HTML iniziale, anziché essere inserito dopo l’esecuzione JavaScript. L’FCP migliora per lo stesso motivo. L’interattività migliora perché i contenuti statici non richiedono una fase di idratazione in cui il browser ricollega i gestori degli eventi al markup generato dal server; vengono idratate solo le isole descritte di seguito. Per le pagine senza elementi interattivi — comuni nei contenuti informativi aziendali — il JavaScript inviato al browser si avvicina a zero.

In realtà, però, la maggior parte dei siti web aziendali non è puramente statica. I siti contengono moduli di contatto, menu di navigazione a tendina ed elementi interattivi che richiedono un’effettiva elaborazione lato client. È qui che entra in gioco l’architettura a isole di Astro.

L’architettura a isole nella pratica

Un’isola Astro è un componente che richiede JavaScript lato client, circondato da HTML interamente statico. Anziché inviare un runtime React completo per idratare un’intera pagina, Astro invia JavaScript solo per i componenti che ne hanno davvero bisogno. Un modulo di contatto diventa un’isola. Un menu di navigazione a tendina diventa un’isola. I contenuti circostanti — titoli, testo, immagini, piè di pagina — rimangono HTML statico.

Questo ribalta l’ipotesi di partenza di una SPA React. In una SPA React, la domanda è «di quali parti di questa pagina possiamo evitare il rendering?» e la risposta è di solito nessuna, perché l’intera pipeline di rendering passa attraverso React. In Astro, la domanda è «quali parti di questa pagina hanno davvero bisogno di JavaScript?» e, per un tipico sito aziendale, la risposta riguarda solo una piccola parte dei contenuti complessivi.

L’architettura supporta React, Preact, Vue, Svelte e Solid, tra gli altri, come framework per le isole. Migrare non richiede di riscrivere i componenti React esistenti. Gli elementi interattivi realizzati in React continuano a funzionare come isole Astro, con lo stesso codice, mentre la struttura circostante della pagina diventa statica. Questa compatibilità rende possibili migrazioni parziali: i componenti React che gestiscono l’interattività effettiva vengono mantenuti, mentre i contenuti di marketing che li circondano smettono di sostenere l’intero carico della SPA.

Quando ha senso usare Astro

La migrazione ad Astro è particolarmente indicata quando ricorrono queste condizioni: la maggior parte dei contenuti è statica o viene aggiornata raramente; la visibilità nei motori di ricerca è un canale di acquisizione primario; il sito raggiunge utenti con condizioni di rete diverse; le funzionalità interattive sono concentrate in componenti specifici anziché diffuse in tutte le pagine.

I siti informativi aziendali — pagine dei servizi, pagine «Chi siamo», articoli del blog, casi studio — corrispondono bene a questo profilo. I contenuti vengono creati una volta e serviti molte volte. Il valore di ogni pagina sta nella capacità di far arrivare i contenuti a utenti e motori di ricerca in modo efficiente, non nel comportamento dinamico lato client. Una SPA React è una soluzione eccessivamente complessa per questo caso d’uso, con un costo reale in termini di prestazioni.

Astro è meno adatto quando l’applicazione presenta una complessità effettiva: interfacce con autenticazione e dati personalizzati, aggiornamenti in tempo reale, sessioni utente con uno stato articolato o interfacce ricche di elementi interattivi in cui la maggior parte richiede un’elaborazione lato client. Sono caratteristiche delle applicazioni, non dei siti web. Nella pratica la distinzione tra sito e applicazione è spesso sfumata, ma è la prospettiva corretta per valutare la migrazione.

Un indicatore pratico: se la tua SPA React usa più di due o tre componenti interattivi su una stessa pagina e questi sono strettamente collegati tramite uno stato condiviso, probabilmente stai sviluppando un’applicazione per cui il modello a componenti di React resta la scelta giusta. Se le pagine contengono soprattutto contenuti e uno o due elementi interattivi isolati, il modello a isole è più adatto sul piano architetturale.

Passaggi pratici per la migrazione

Una migrazione completa da una SPA React ad Astro procede per fasi, anziché con un unico passaggio al nuovo sistema. L’obiettivo di ogni fase è ottenere una versione distribuibile che migliori la precedente, evitando una riscrittura prolungata che accumuli rischi.

La prima fase è l’analisi e la classificazione. Esamina ogni tipo di pagina e classifica gli elementi interattivi presenti. Moduli di contatto, iscrizioni alla newsletter, menu di navigazione con funzionalità JavaScript e filtri interattivi sono candidati a diventare isole. Le sezioni prive di interattività — sezioni introduttive, elenchi di funzionalità, corpi degli articoli del blog, pagine del team — possono invece passare al rendering statico.

La seconda fase è la configurazione dell’infrastruttura. I progetti Astro richiedono la configurazione degli strumenti di build, del routing i18n se il sito è multilingue e la scelta dell’ambiente di distribuzione. L’output statico di Astro si integra facilmente con qualsiasi infrastruttura di hosting statico. Il processo di build produce file che il server distribuisce senza logica applicativa, semplificando notevolmente sia la distribuzione sia la configurazione della cache.

La terza fase è la migrazione dei contenuti. Il modello a componenti di Astro è sufficientemente vicino a quello di React da permettere di trasferire molti componenti con modifiche minime. Il cambiamento principale è che i componenti Astro (file .astro) gestiscono il rendering statico, mentre quelli React sono riservati alle isole interattive. La separazione può essere introdotta gradualmente: i componenti React esistenti funzionano come isole fin dal primo giorno e la struttura circostante viene spostata progressivamente nei template Astro.

La quarta fase è la validazione. I valori dei Core Web Vitals vanno misurati prima e dopo la migrazione in condizioni comparabili: simulazione di rete mobile e cache vuota. L’LCP di solito migliora sensibilmente nel passaggio da una SPA React con rendering lato client all’output statico di Astro, a parità di contenuti, ma l’entità del miglioramento dipende dal punto di partenza e va misurata anziché data per scontata. L’impatto SEO richiede in genere diverse settimane per emergere nei dati di ricerca, mentre i crawler reindicizzano le pagine aggiornate.

I compromessi da considerare

Astro introduce alcuni compromessi. La fase di build è più articolata rispetto alla distribuzione di una SPA lato client: con l’output statico, le modifiche ai contenuti richiedono una nuova build e una nuova distribuzione, anziché un aggiornamento diretto del database subito visibile sulla pagina. Per i team abituati ai flussi di lavoro dei CMS, in cui i redattori pubblicano e vedono le modifiche in pochi secondi, occorre attivare una build a ogni aggiornamento dei contenuti oppure accettare un breve ritardo nella distribuzione.

Sviluppare funzionalità interattive complesse richiede una progettazione più attenta. Lo stato condiviso tra più componenti di una pagina, o mantenuto durante la navigazione tra pagine, richiede una gestione esplicita che una SPA React fornisce automaticamente tramite il contesto dei componenti e il routing lato client. Astro supporta le transizioni tra viste e può condividere lo stato tra isole tramite le API standard del browser, ma questi schemi richiedono una progettazione più consapevole rispetto a un unico contesto applicativo React.

Sono costi reali, non preoccupazioni teoriche. Anche il valore della migrazione è reale: le prestazioni del rendering statico non rappresentano un miglioramento marginale. La decisione di migrare va però basata su una valutazione onesta di vantaggi e costi, non sull’ipotesi che il rendering lato server sia superiore in ogni contesto.

Astro rappresenta un ritorno a un’impostazione predefinita più semplice: inviare HTML al browser e aggiungere JavaScript solo dove le funzionalità lo richiedono. Per i siti aziendali il cui scopo principale è comunicare chiaramente i contenuti e raggiungere gli utenti in modo efficiente, è un punto di partenza più appropriato di un runtime completo lato client che deve ricreare il DOM a ogni caricamento di pagina. L’architettura rispecchia ciò che il sito fa davvero, anziché le impostazioni predefinite del framework.