Negli ultimi anni l’approccio «headless» è diventato una delle proposte più frequenti per chi vuole un sito WordPress più veloce: WordPress resta il sistema in cui i redattori scrivono e organizzano i contenuti, ma le pagine vengono generate da un’applicazione separata, costruita con un framework JavaScript moderno. La promessa è un sito velocissimo, sicuro e flessibile. La realtà è più sfumata: un sito headless può essere eccellente per le Core Web Vitals, oppure più lento del sito tradizionale che doveva sostituire, e comporta sempre costi che non compaiono nei preventivi iniziali.
In questo articolo vediamo come funziona un’architettura headless, da cosa dipendono davvero le sue prestazioni, quali sono i costi nascosti e quando conviene sceglierla.
Cosa significa headless
In un sito WordPress tradizionale, lo stesso sistema gestisce i contenuti e genera le pagine: il tema, con i suoi template, trasforma i dati del database in HTML. In un sito headless, letteralmente «senza testa», il tema non genera più le pagine pubbliche. WordPress espone i contenuti tramite un’interfaccia di programmazione, l’API REST inclusa nel nucleo o GraphQL tramite un plugin, e un’applicazione separata, il front-end, li richiede e costruisce le pagine. Il front-end è di solito realizzato con framework come Next.js, Nuxt, Astro o SvelteKit, e spesso ospitato su piattaforme specializzate diverse dall’hosting di WordPress.
Il termine indica un’architettura, non una garanzia di prestazioni. Due siti headless possono comportarsi in modo opposto a seconda di come e quando il front-end genera le pagine, e di quanto JavaScript invia al browser.
Come vengono generate le pagine
Il fattore che più determina le prestazioni di un sito headless è il momento in cui l’HTML viene prodotto. Le possibilità principali sono quattro.
- Generazione statica: tutte le pagine vengono prodotte in anticipo, durante la compilazione del sito, e pubblicate come file su una CDN. Il TTFB è minimo e costante, come per una pagina in cache. Il limite è il tempo di compilazione, che su siti con migliaia di pagine può diventare lungo, e l’aggiornamento dei contenuti, che richiede una nuova compilazione;
- rigenerazione incrementale: le pagine vengono generate e messe in cache, e rigenerate singolarmente quando il contenuto cambia, di solito su segnalazione di WordPress al momento della pubblicazione. Unisce la velocità dello statico con aggiornamenti rapidi, ed è la scelta più diffusa per i siti di contenuti;
- generazione sul server a ogni richiesta: il front-end costruisce la pagina quando arriva la richiesta, interrogando le API di WordPress. Il TTFB dipende dalla somma dei tempi del front-end e delle API, spesso con più chiamate in sequenza; senza una cache davanti, può essere peggiore di quello di un WordPress tradizionale con cache di pagina;
- generazione nel browser: il server invia un documento quasi vuoto e il JavaScript, una volta scaricato ed eseguito, richiede i contenuti e costruisce la pagina. È il caso peggiore per l’LCP e per l’indicizzazione, come discusso nell’articolo sulle single page application, e per un sito di contenuti non ha giustificazioni.
Un sito headless ben progettato genera in anticipo, o mette in cache, tutte le pagine pubbliche, e si comporta per il TTFB come un sito tradizionale con una buona cache di pagina e una CDN. Il vantaggio rispetto al tradizionale, su questo fronte, è spesso minore di quanto si pensi.
Il costo del JavaScript
Il secondo fattore è la quantità di JavaScript che arriva al browser. Molti framework, anche quando generano l’HTML sul server, inviano poi al browser il codice necessario a ricostruire l’intera pagina come applicazione interattiva, un processo chiamato idratazione. Su uno smartphone di fascia media l’idratazione di una pagina complessa può occupare il main thread per centinaia di millisecondi, con effetti sull’INP e sulla reattività nei primi secondi.
Per un sito di contenuti, dove la maggior parte della pagina è testo e immagini statiche, questo lavoro è in gran parte inutile. I framework più recenti affrontano il problema in modi diversi: alcuni inviano JavaScript solo per le parti interattive della pagina, lasciando il resto come HTML semplice, secondo il modello detto «a isole»; altri distinguono tra componenti eseguiti solo sul server e componenti che richiedono codice nel browser. La scelta del framework e il modo in cui viene usato contano più della scelta dell’architettura headless in sé. Le tecniche viste nell’articolo sul code splitting sono essenziali.
C’è un effetto positivo: dopo il primo caricamento, la navigazione tra le pagine di un sito headless può essere molto rapida, perché il front-end scarica solo i dati della pagina successiva. Va però ricordato che queste navigazioni interne, dette «soft», non sono misurate come caricamenti di pagina separati dalle Core Web Vitals, come discusso nell’articolo sul futuro delle metriche. Lo stesso risultato si ottiene in un sito tradizionale con le speculation rules, senza cambiare architettura.
I costi nascosti
Il passaggio a un’architettura headless ha costi che vanno oltre lo sviluppo iniziale, e che spesso emergono solo dopo il lancio.
- Due sistemi da mantenere: WordPress con i suoi aggiornamenti e plugin, e il front-end con il suo framework, le sue dipendenze e il suo hosting. Servono competenze diverse, e il costo di manutenzione cresce;
- i plugin del front-end non funzionano più: tutto ciò che un plugin fa sul sito pubblico, come i dati strutturati di un plugin SEO, i moduli di contatto, le gallerie, i codici brevi, i blocchi con stili e script propri, i costruttori di pagine, deve essere reimplementato nel front-end;
- l’anteprima: vedere un articolo in bozza così come apparirà sul sito richiede un meccanismo apposito, e per i redattori è spesso l’aspetto più frustrante;
- i blocchi: il contenuto creato con l’editor a blocchi deve essere reso dal front-end, blocco per blocco, con i relativi stili. I blocchi dei plugin e quelli personalizzati richiedono lavoro aggiuntivo;
- le immagini: le dimensioni generate da WordPress e gli attributi
srcsetvanno gestiti dal front-end, spesso con componenti dedicati del framework o una CDN per immagini; - la cache e l’invalidazione: quando un contenuto cambia, vanno rigenerate non solo la pagina dell’articolo ma anche gli archivi, la home, le pagine correlate, i feed. Una logica di invalidazione sbagliata mostra contenuti vecchi;
- funzioni dinamiche: ricerca, commenti, aree riservate, carrello richiedono soluzioni specifiche.
Sicurezza e scalabilità
Due argomenti ricorrono spesso a favore dell’architettura headless. Il primo è la sicurezza: se il sito pubblico è fatto di pagine statiche servite da una CDN, WordPress può restare su un indirizzo separato, non esposto ai visitatori, e la superficie di attacco si riduce. Il secondo è la scalabilità: un picco di traffico viene assorbito dalla CDN, e WordPress riceve solo le richieste del front-end quando deve rigenerare le pagine. Sono vantaggi reali, ma anche un sito tradizionale ben configurato, con cache di pagina, CDN e un firewall applicativo, assorbe bene i picchi di traffico e riduce i rischi. La differenza si sente soprattutto nei siti con traffico molto alto o con requisiti di sicurezza particolari.
Misurare un sito headless
La misura delle prestazioni di un sito headless richiede qualche attenzione in più. I test di laboratorio sulla prima visita mostrano bene il costo dell’idratazione e del JavaScript, mentre non vedono la velocità delle navigazioni interne. I dati reali del Chrome UX Report misurano i caricamenti completi delle pagine, e attribuiscono le metriche delle navigazioni interne alla pagina di ingresso. Un sistema di monitoraggio degli utenti reali compatibile con le applicazioni a pagina singola permette di osservare entrambe le cose. Conviene anche tenere sotto controllo il tempo di risposta delle API di WordPress, che nei siti con generazione sul server entra direttamente nel TTFB.
Quando ha senso
L’architettura headless ha senso in alcuni casi precisi. Quando gli stessi contenuti devono alimentare più canali, come un sito, un’applicazione mobile e altri servizi. Quando l’interfaccia è molto interattiva, più vicina a un’applicazione che a un sito di contenuti. Quando l’organizzazione ha un gruppo di sviluppo front-end stabile, che conosce il framework e può mantenerlo nel tempo. Quando si vuole separare nettamente l’amministrazione dei contenuti dal sito pubblico, per ragioni di sicurezza o di scalabilità.
Ha meno senso quando l’obiettivo principale è migliorare le Core Web Vitals di un sito di contenuti o di un sito aziendale. Un tema WordPress leggero, come un buon tema a blocchi, con cache di pagina, CDN, immagini ottimizzate e pochi script di terze parti, raggiunge valori eccellenti con una frazione dei costi e senza rinunciare all’ecosistema dei plugin. In molti casi i problemi di prestazioni di un sito WordPress non dipendono dall’architettura, ma da un tema pesante, da troppi plugin o da script esterni: problemi che un sito headless risolve solo perché costringe a ricominciare da zero, e che possono ripresentarsi appena si aggiungono di nuovo gli stessi script.
Valutare il passaggio
Prima di decidere, conviene misurare dove si trova oggi il tempo nel sito attuale: TTFB, peso del JavaScript, script di terze parti, dimensione delle immagini. Se i problemi principali sono script di marketing e immagini, cambieranno poco con un front-end diverso. Se si procede, il passaggio va trattato come una migrazione, con misure prima e dopo, obiettivi espliciti sulle Core Web Vitals e un budget di JavaScript fissato fin dall’inizio. Il confronto tra costi e benefici, come discusso nell’articolo sul ritorno economico della velocità, deve includere anche i costi di manutenzione dei due sistemi negli anni successivi.
Un esempio concreto
Un’azienda con un sito di un centinaio di pagine valuta il passaggio a un front-end headless per migliorare le Core Web Vitals, segnalate come scarse da smartphone. L’analisi mostra che il TTFB è già buono grazie alla cache di pagina, mentre l’LCP è rallentato da un’immagine principale non ottimizzata e l’INP da un costruttore di pagine e da cinque script di marketing. Un front-end headless avrebbe richiesto di reimplementare moduli, dati strutturati e pagine costruite con il costruttore, senza intervenire sugli script di marketing, che sarebbero stati reinseriti. L’azienda sceglie invece di passare a un tema a blocchi leggero, ottimizzare le immagini e ridurre gli script esterni: le Core Web Vitals rientrano nelle soglie buone in poche settimane, a un costo molto inferiore. Un anno dopo, quando lancia un’applicazione mobile che deve mostrare gli stessi contenuti, usa l’API REST di WordPress per alimentarla, senza cambiare il sito.
In sintesi
Un sito WordPress headless separa la gestione dei contenuti dalla generazione delle pagine. Le sue prestazioni dipendono da due scelte: quando viene generato l’HTML, dove la generazione anticipata o la rigenerazione incrementale danno i risultati migliori e la generazione nel browser i peggiori, e quanto JavaScript arriva al browser, dove i framework che inviano codice solo per le parti interattive fanno la differenza. I costi nascosti sono importanti: due sistemi da mantenere, plugin da reimplementare, anteprima, blocchi, immagini, invalidazione della cache. È una scelta sensata per contenuti multicanale, interfacce molto interattive e organizzazioni con un gruppo di sviluppo stabile; per migliorare le Core Web Vitals di un sito di contenuti, un tema leggero con cache e pochi script raggiunge spesso lo stesso risultato con molto meno.
