Headless CMS: perché separare contenuto e presentazione cambia tutto
Eugenio Miserocchi
Scrivo questi articoli per chiarire decisioni tecniche che impattano direttamente acquisizione, processi e margini. Se un tema ti riguarda, possiamo partire da qui invece che da una call generica.
Il 43% del web gira su WordPress. È un dato impressionante che nasconde un problema: la maggior parte di quei siti è lenta, vulnerabile e difficile da scalare. Non perché WordPress sia un cattivo prodotto, ma perché l'architettura monolitica ha limiti strutturali.
Un CMS monolitico gestisce tutto: contenuto, logica, rendering, database. Quando il traffico cresce, quando hai bisogno di un'app mobile, quando vuoi personalizzare l'esperienza utente — tutto diventa complicato perché tutto è accoppiato.
Cos'è l'architettura headless
Il principio è semplice: separa dove gestisci il contenuto (il 'corpo') da come lo presenti (la 'testa'). Il CMS diventa un repository di contenuti accessibile via API. Il frontend — che può essere un sito React, un'app mobile, un totem in negozio — consuma quei contenuti e li renderizza in modo indipendente.
Questo significa che puoi cambiare completamente il design del sito senza toccare il CMS. Puoi aggiungere un'app mobile che usa gli stessi contenuti. Puoi servire versioni diverse dello stesso contenuto a utenti diversi. Tutto senza duplicare dati.
Benchmark reali: WordPress vs Headless
Ho migrato 12 siti da WordPress monolitico a architettura headless nell'ultimo anno. I risultati medi:
Tempo di caricamento: da 3.2s a 0.8s (-75%). Il frontend statico generato in build time è intrinsecamente più veloce di una pagina generata ad ogni richiesta da PHP.
Punteggio Lighthouse: da 58 a 96 (+65%). Performance, accessibilità e best practice migliorano drasticamente quando il frontend è ottimizzato e il rendering è controllato.
Vulnerabilità di sicurezza: da una media di 4 plugin vulnerabili per sito a zero. Senza PHP esposto al web, la superficie di attacco si riduce praticamente a zero.
Costo hosting: da 30-50€/mese (hosting WordPress gestito) a 0-20€/mese (deploy statico su Vercel/Netlify + CMS cloud). Per siti con traffico moderato, l'hosting diventa quasi gratuito.
Quando NON usare headless
Essere onesti sui limiti è importante quanto evangelizzare i vantaggi:
Blog personale o sito vetrina semplice. Se hai 5 pagine statiche e un blog con 2 post al mese, WordPress con un buon tema è ancora la soluzione più pragmatica. L'architettura headless introduce complessità che non si giustifica per progetti semplici.
Team non tecnico senza supporto. L'editing experience di un CMS headless come Strapi o Sanity è diversa da WordPress. Se il cliente deve gestire i contenuti in autonomia e non ha competenze tecniche, serve formazione e un'interfaccia ben configurata.
Budget molto limitato. Un sito headless costa di più in fase di sviluppo iniziale. Il risparmio arriva nel tempo — manutenzione ridotta, hosting più economico, scalabilità senza refactoring — ma l'investimento iniziale è superiore.
Lo stack che raccomando
Per la maggior parte dei progetti business, il mio stack headless è: Sanity o Strapi come CMS (dipende dal progetto), Next.js per il frontend, deploy su Vercel con ISR (Incremental Static Regeneration) per il meglio di entrambi i mondi — velocità statica con contenuti sempre aggiornati.
Non è l'unica combinazione valida, ma è quella che bilancia meglio developer experience, performance e costo per il tipo di clienti con cui lavoro: PMI e professionisti che vogliono un sito veloce, sicuro e facile da aggiornare.
Vuoi applicare questo tema al tuo contesto?
Se l articolo tocca un problema che hai gia sul tavolo, scrivimi con obiettivo e contesto: parto piu volentieri da un problema concreto che da una call esplorativa.