Cos'è un CMS headless, e quando ne hai davvero bisogno?
Un CMS headless separa il contenuto dalla presentazione — e per un sito vetrina di cinque pagine è lo strumento sbagliato. Ecco quando conviene davvero.
Un CMS headless memorizza i tuoi contenuti e li consegna su un'API. Non renderizza
pagine. Non c'è tema, template né front end — quella parte la costruisci tu.
Questa è tutta la definizione. Tutto il resto in questo articolo riguarda se
questo sia un buon compromesso per te, e gran parte della risposta onesta è "dipende da
quanti front end hai".
In un CMS tradizionale — WordPress, Drupal, la maggior parte di ciò che hai usato — l'archiviazione
dei contenuti e il rendering delle pagine vivono nello stesso sistema. Scrivi un post, il CMS
lo mette in un database, e lo stesso CMS lo trasforma in HTML usando un tema.
Comodo, e inseparabile.
"Headless" significa rimuovere la metà del rendering. Ciò che resta è:
un posto per definire i tipi di contenuto e i loro campi
un editor per le persone che scrivono
un'API che restituisce contenuto strutturato — JSON, non HTML
Il compromesso è netto. Perdi il sito web gratuito. Guadagni contenuti che non hanno
la forma di una pagina web, e possono quindi essere usati da cose che non sono pagine
web.
Vedrai entrambe le parole. In senso stretto, un CMS decoupled fornisce comunque uno strato di
rendering che puoi scegliere di usare; uno headless non ne ha nessuno. In pratica le persone le usano
in modo intercambiabile, e la distinzione cambia raramente una decisione.
La domanda che vale la pena porsi su qualsiasi prodotto è più semplice: può renderizzare una
pagina? Se sì, andare headless con esso significa eseguire un renderer e poi
ignorarne l'output.
Hai più di un front end. Un sito web, un'app iOS, un chiosco, un partner
che vuole un feed. In un CMS tradizionale il secondo consumatore è un problema di scraping.
In uno headless è un secondo client API.
Hai più di un progetto. Un'agenzia con dieci clienti, un gruppo con
cinque brand, un SaaS in cui ogni cliente ha bisogno dei propri contenuti. È qui che
i modelli di prezzo cominciano a divergere nettamente — alcuni prodotti fatturano per progetto,
per dataset o per spazio, e il terzo progetto è dove lo scopri.
Il tuo contenuto non ha la forma di una pagina. Un catalogo di prodotti, un sito di documentazione, un
changelog, una bacheca di annunci di lavoro. Se stai combattendo il modello "post" con campi
personalizzati, stai già pagando la tassa senza il beneficio.
La localizzazione è reale. Non "abbiamo tradotto il menù" — contenuto davvero parallelo
in più lingue, con stati di pubblicazione diversi per lingua.
I CMS tradizionali lo fanno con i plugin. Quelli headless lo trattano come una proprietà
a livello di campo.
Le prestazioni del front end sono un numero di business. Il disaccoppiamento ti permette di servire
output pre-renderizzato e memorizzabile nella cache invece di calcolare una pagina per richiesta. Non è
automatico, ma diventa possibile.
Questa è la sezione che la maggior parte degli articoli dei fornitori salta, perché stanno vendendo.
Un sito, una lingua, un team, nessuno sviluppatore. Un CMS headless sposta il
lavoro di rendering su di te. Se nessuno farà quel lavoro, hai pagato per una
sottrazione. Usa WordPress, o un site builder, e spendi i soldi sui contenuti.
Un sito vetrina di cinque pagine. L'API, il passo di build, la pipeline di deploy e
il repo del front end sono tutti overhead a fronte di cinque pagine che cambiano due volte
all'anno.
Il tuo team modifica con un'anteprima visuale e non ci rinuncerà. Alcuni prodotti
headless hanno un'eccellente anteprima dal vivo; molti non ne hanno nessuna. Se "voglio vedere la pagina
mentre digito" è irrinunciabile, mettilo in cima ai tuoi criteri e lascia che
elimini i candidati per tempo.
Hai bisogno di un ecosistema di plugin. Prenotazioni, form, membership, e-commerce — se
il tuo sito dipende da moduli pronti all'uso, headless significa scriverli. Quella
è una voce di budget, non un dettaglio.
Un test utile: conta i tuoi front end e conta i tuoi progetti. Se entrambi sono uno,
la risposta onesta è di solito "non ancora".
Una volta deciso che ne hai bisogno, il modello che decide la tua fattura è come
il fornitore fa pagare le letture.
La maggior parte dei prodotti headless ospitati conta qualcosa che il traffico dei visitatori muove: chiamate
API, banda, richieste CDN o una quota di utilizzo combinata. La conseguenza è
facile da enunciare e facile da mancare: un lancio di successo è indistinguibile da
un incidente di fatturazione. Nulla dei tuoi contenuti o del tuo lavoro è cambiato — solo
il numero di sconosciuti che li leggono.
C'è un'alternativa architetturale, e vale la pena capirla qualunque
prodotto tu scelga: servire il contenuto pubblicato come file immutabili pre-compilati da
una cache, invece di calcolare una risposta per richiesta.
È così che funziona corpusctl. Premere pubblica esegue una build: il contenuto viene
validato, renderizzato e scritto in un file indirizzato tramite hash nell'object storage,
poi il manifest viene aggiornato. Il client del lettore risolve lo slug in uno
shard del manifest localmente, poi recupera quell'indirizzo dalla cache edge nginx.
Poiché l'indirizzo è un hash del contenuto, lo stesso indirizzo non può mai restituire
contenuti diversi — quindi può essere memorizzato in cache per trenta giorni senza alcuna strategia
di invalidazione. La pubblicazione scrive un nuovo indirizzo.
Due richieste HTTP, entrambe dalla cache. Nessuna raggiunge l'API. Nessuna raggiunge
il database. Non c'è un contatore per chiamata perché non c'è alcuna chiamata.
Non devi scegliere corpusctl per usare questo come criterio. Chiedi a qualsiasi fornitore:
cosa succede alla mia fattura se questo post va dieci volte meglio del previsto?
WordPress headless è un vero CMS headless? Funzionalmente sì — l'API REST
e WPGraphQL espongono i contenuti. Architetturalmente è un retrofit: mantieni il
meccanismo di rendering delle pagine e poi ne scarti l'output.
Fa male alla SEO? Non intrinsecamente. I tre modi comuni in cui i team perdono traffico
in una migrazione sono il rendering solo sul client, la perdita dei tag canonical durante
la ricompilazione e il servire da un'origine lenta invece che da una cache.
È più costoso? Di solito più costoso in tempo di ingegneria all'inizio,
e più economico nel caso specifico in cui stavi per costruire tre siti web.
Cosa costa davvero l'"open source" in un CMS headless
Open source raramente significa gratuito da eseguire. Licenze, upsell cloud e il costo verificato di sei CMS headless popolari — con i numeri dalle loro stesse pagine.