Se hai un sito WordPress, probabilmente sai già come funziona: scrivi il contenuto nel backend, WordPress genera la pagina HTML e la serve all’utente. Contenuto e presentazione vivono nello stesso sistema, sullo stesso server, nello stesso codice.

Funziona? Sì, da vent’anni. Ma funziona bene? Dipende da cosa intendi per “bene”.

Negli ultimi tre anni ho migrato 12 siti da architetture monolitiche a architetture headless. Non per moda, non per sfoggio tecnico: perché in quei casi specifici i numeri raccontavano una storia chiara. In questo articolo condivido cosa ho imparato, con benchmark reali.

Cos’è un CMS headless (senza buzzword)

In un CMS tradizionale come WordPress, il sistema fa tutto: gestisce i contenuti, li impagina, genera l’HTML, lo serve al browser. È un blocco unico, un “monolite”.

In un’architettura headless, il CMS fa solo una cosa: gestire i contenuti. Li espone tramite API (REST o GraphQL) e un frontend separato li prende, li impagina e li mostra all’utente. Il CMS è la “testa” che pensa (i contenuti), il frontend è il “corpo” che mostra (la presentazione).

Perché separare? Perché ogni componente può essere ottimizzato indipendentemente. Il CMS può essere il migliore per la gestione contenuti. Il frontend può essere il più veloce per la visualizzazione. Non sei costretto a un compromesso dove un solo sistema deve fare tutto.

I benchmark di 12 migrazioni

Non parlo in astratto. Ecco i numeri medi che ho registrato sulle 12 migrazioni che ho completato, da WordPress monolitico a architettura headless con Astro o Next.js come frontend.

Tempo di caricamento (LCP): da 3.2 secondi a 0.8 secondi in media. In un caso particolarmente pesante, da 5.1 a 1.1 secondi.

Peso della pagina: da 2.8MB a 340KB in media. Meno JavaScript, meno CSS inutilizzato, immagini ottimizzate automaticamente dal build process.

Punteggio PageSpeed: da 45-65 a 90-100. Costantemente. Non un caso fortunato: un risultato sistematico.

TTFB (Time to First Byte): da 600ms a 50ms con pagine pre-generate su CDN. Il server non deve più “pensare” a ogni richiesta, la pagina è già pronta.

Uptime e sicurezza: zero attacchi riusciti sui siti headless. I siti statici serviti da CDN non hanno un server PHP esposto, non hanno un database raggiungibile, non hanno un pannello /wp-admin da attaccare con brute force.

Questi numeri non sono cherry-picking. Sono medie su progetti diversi: siti vetrina, blog con centinaia di articoli, piccoli e-commerce, portfolio di professionisti.

Quando NON usare l’architettura headless

E qui viene la parte onesta. L’headless non è la scelta giusta per tutti.

Se il budget è limitato e il sito è semplice. Un sito vetrina di 5 pagine per un professionista che vuole una presenza online? WordPress con un buon tema, hosting decente e qualche ottimizzazione è più che sufficiente. L’overhead di un’architettura headless non si giustifica.

Se chi gestisce i contenuti non è tecnico e vuole semplicità assoluta. WordPress ha un editor visuale che chiunque può usare. Con un headless CMS, l’esperienza di editing può essere meno intuitiva (anche se strumenti come Sanity e Storyblok hanno fatto passi enormi). Se il cliente è un freelancer o un piccolo studio che vuole aggiornare il sito in autonomia senza supporto, la semplicità di WordPress è un valore concreto.

Se hai bisogno di funzionalità WordPress specifiche. Plugin complessi, WooCommerce personalizzato, membership site con logiche articolate. L’ecosistema WordPress ha soluzioni pronte per quasi tutto. Ricostruirle in un’architettura headless richiede tempo e budget.

Se il sito deve essere online domani. L’architettura headless richiede più tempo di setup iniziale. Se hai fretta, WordPress ti porta online in giorni. L’headless richiede settimane.

Lo stack che consiglio

Quando l’headless è la scelta giusta, ecco lo stack con cui lavoro e che consiglio in base al contesto.

Per siti statici e blog (il caso più comune):

  • CMS: Sanity o Keystatic (per chi vuole tutto in Git)
  • Frontend: Astro. Velocissimo, genera HTML statico, supporta qualsiasi framework per le parti interattive
  • Hosting: Vercel o Cloudflare Pages. Deploy automatico, CDN globale, costo praticamente zero per siti di dimensioni normali

Per siti con parti dinamiche (e-commerce, dashboard):

  • CMS: Sanity o Strapi
  • Frontend: Next.js con App Router
  • Hosting: Vercel

Per chi vuole restare nell’ecosistema WordPress:

  • CMS: WordPress come headless CMS (usando WPGraphQL)
  • Frontend: Astro o Next.js
  • Hosting: WordPress su hosting gestito + frontend su Vercel

Quest’ultima opzione è spesso la migliore per chi ha già un sito WordPress con molti contenuti. Si mantiene il backend familiare ma si guadagnano tutte le performance di un frontend moderno.

Il processo di migrazione

Quando migro un sito, seguo un processo in fasi che minimizza il rischio.

Fase 1: Audit. Analizzo il sito attuale, mappo i contenuti, identifico le funzionalità, valuto se l’headless è la scelta giusta. A volte la conclusione è “no, ottimizziamo WordPress”. E va bene così.

Fase 2: Setup del CMS e migrazione contenuti. Configuro il nuovo CMS, definisco gli schemi dei contenuti, migro i testi e i media. Questa fase è spesso la più lunga e la meno divertente, ma è fondamentale.

Fase 3: Sviluppo frontend. Costruisco il nuovo frontend, componente per componente. Il cliente vede i progressi in tempo reale su un URL di preview.

Fase 4: Testing e redirect. Testo performance, accessibilità, SEO. Configuro tutti i redirect 301 dal vecchio al nuovo URL. Questo passaggio è critico: un errore nei redirect significa perdere il posizionamento SEO conquistato.

Fase 5: Go-live e monitoraggio. Lancio il nuovo sito, monitoro le metriche per le prime settimane, intervengo dove necessario.

Non è ideologia, sono numeri

Non sono un evangelista dell’headless. Sono un pragmatico che guarda i numeri. Se WordPress monolitico funziona per il tuo caso, usalo. Se l’headless porta vantaggi concreti e misurabili, migraci.

La scelta dell’architettura non è una questione di fede. È una questione di requisiti, budget, competenze disponibili e obiettivi. Il mio lavoro è aiutarti a capire quale architettura serve al tuo progetto, non vendere quella che piace a me.