Siti headless e architetture moderne: cosa sono e a chi servono

Immaginate una cucina senza sala. I cuochi preparano i piatti, ma nessun cameriere li porta ai tavoli, perché i tavoli non ci sono: le portate escono dal passavivande e vanno dove serve — al banco dell’asporto, al rider delle consegne, al chiosco in piazza. La cucina fa una cosa sola, e la fa per tutti. I siti headless e le architetture moderne che li accompagnano funzionano esattamente così: il contenuto vive in un posto, le vetrine che lo mostrano vivono altrove. E possono essere tante.

Il termine inglese significa “senza testa”, che riferito a un sito suona vagamente sinistro. In realtà descrive un divorzio tecnico piuttosto sensato: da una parte il magazzino dei contenuti — testi, foto, schede prodotto, prezzi — dall’altra l’interfaccia che il visitatore vede e tocca. Due sistemi separati che si parlano attraverso un canale standardizzato, il passavivande della metafora.

La trattoria e la cucina centralizzata

Il sito tradizionale è una trattoria: cucina e sala nello stesso edificio, stesso proprietario, stesso sistema. Quando pubblichi un articolo o cambi una foto, il gestionale dei contenuti prepara il piatto e lo serve al tavolo, cioè lo impagina e lo mostra al visitatore. Tutto in casa, tutto integrato. È il modello su cui si regge la stragrande maggioranza del web, ed è il motivo per cui chi valuta quale CMS scegliere per il sito aziendale di solito ragiona proprio in questi termini: un unico sistema che fa tutto.

L’architettura headless smonta la trattoria. La cucina diventa una cucina centralizzata: produce contenuti e basta, senza sapere né curarsi di dove finiranno. Le sale — il sito, l’app, il totem in negozio — sono locali indipendenti, ciascuno arredato a modo suo, che ordinano i piatti alla stessa cucina. Se domani apri una sala nuova, la cucina non cambia di una virgola: continua a sfornare gli stessi contenuti, e la sala nuova li impiatta come preferisce.

Tra i due estremi esiste anche la via di mezzo, il cosiddetto approccio “decoupled”: la trattoria tiene la sua sala, ma apre anche il passavivande verso l’esterno. Il gestionale continua a servire il sito come ha sempre fatto, e intanto mette i contenuti a disposizione di altri canali.

Un contenuto, tutte le vetrine

I vantaggi veri sono tre, e conviene guardarli senza occhiali rosa.

Il primo è la coerenza multicanale. Una catena di negozi con sito, app di fidelizzazione e totem alle casse ha lo stesso problema tre volte: la scheda del prodotto, il prezzo, la promozione del momento. Con l’architettura headless la scheda si scrive una volta sola, nella cucina, e arriva identica su tutti i canali. Niente più prezzo aggiornato sul sito e vecchio sul totem, niente tripla fatica redazionale.

Il secondo è la velocità. La vetrina, liberata dal peso del gestionale, può essere costruita come una serie di pagine leggerissime, in gran parte già pronte prima ancora che il visitatore le chieda — piatti al passe, per restare in cucina. Su connessioni mobili mediocri la differenza si sente, e la velocità di caricamento è uno dei fattori che i motori di ricerca premiano.

Il terzo è la sicurezza. Nel sito tradizionale la porta d’ingresso dell’amministrazione sta nello stesso edificio della sala: chi trova la porta può provare a forzarla. Nell’architettura headless la cucina sta in un altro isolato, spesso nemmeno raggiungibile dall’esterno. La superficie esposta agli attacchi si riduce parecchio.

Il conto, voce per voce

Ora il rovescio, che nelle presentazioni commerciali tende a sparire.

Primo: serve uno sviluppatore. Non una volta, per sempre. Nella trattoria tradizionale cambi un menù, un colore, la disposizione dei tavoli con qualche clic; nel modello headless ogni modifica alla sala passa da chi l’ha costruita. Il bottone da spostare, il banner da aggiungere, la pagina promozionale del weekend: tutto diventa un piccolo progetto con un preventivo.

Secondo: chi scrive perde l’anteprima comoda. Nel gestionale tradizionale l’editor vede la pagina più o meno come apparirà; nella cucina headless compila campi — titolo, testo, immagine — senza vedere il piatto impiattato. Esistono rimedi, ma raramente eguagliano la naturalezza del “quello che vedi è quello che pubblichi”. Per una redazione che pubblica ogni giorno, è un attrito quotidiano.

Terzo: i sistemi da mantenere diventano due, con due bollette. La cucina da una parte, la vetrina dall’altra, più il lavoro di chi le tiene collegate. Il costo iniziale è sensibilmente più alto di un sito tradizionale ben fatto, e anche la manutenzione ordinaria pesa di più.

A chi serve davvero, e a chi no

La domanda giusta non è “l’headless è meglio?”, ma “quante sale devo servire?”.

Se la risposta è più di una — sito, app, totem, marketplace, magari un catalogo che alimenta anche la rete vendita — la cucina centralizzata comincia a ripagarsi. Lo stesso vale per chi pubblica volumi industriali di contenuti su più proprietà, o per l’e-commerce che vive su molti punti di contatto contemporaneamente. In questi scenari la duplicazione manuale costa più dell’architettura che la elimina.

Se invece la risposta è “una”: un sito vetrina, un blog, un modulo di contatto, magari un piccolo negozio online — e per la maggior parte delle piccole e medie imprese la risposta è questa — il gestionale tradizionale resta la scelta giusta. Non è un ripiego: è lo strumento proporzionato al problema. Piattaforme mature come quella analizzata in WordPress per le aziende: punti di forza e limiti offrono autonomia redazionale, costi prevedibili e un ecosistema sterminato. Rinunciarci per inseguire un’architettura di moda significa pagare i costi delle catene multicanale senza averne i ricavi.

Dirlo è semplice onestà: il fornitore che propone l’headless a un ristorante con trenta coperti sta vendendo una cucina centralizzata a chi ha una sala sola.

La tecnologia migliore non è la più moderna: è quella che sparisce sotto il lavoro di tutti i giorni. Una trattoria ben gestita batte una cucina industriale usata a un decimo della capacità — e il pranzo, alla fine, si giudica al tavolo.

Domande frequenti

Cosa significa “headless” applicato a un sito?

Significa che il sistema di gestione dei contenuti non ha una “testa”, cioè un’interfaccia pubblica propria: si limita a conservare e distribuire i contenuti, mentre la parte visibile del sito è costruita separatamente e li richiede attraverso un canale standardizzato.

Un sito headless è più veloce di uno tradizionale?

In genere sì, perché la vetrina è alleggerita e molte pagine vengono preparate in anticipo. Ma un sito tradizionale ben ottimizzato può essere comunque molto rapido: la velocità dipende più dalla qualità del lavoro che dall’architettura in sé.

Quanto costa un’architettura headless rispetto a un CMS tradizionale?

Di più, su entrambi i fronti: la costruzione iniziale richiede sviluppo su misura e la manutenzione riguarda due sistemi anziché uno. Ogni modifica grafica, inoltre, passa da uno sviluppatore invece che da qualche clic in autonomia.

La mia PMI ha bisogno di un sito headless?

Quasi certamente no, se il vostro unico canale è il sito web. L’headless si ripaga quando gli stessi contenuti devono alimentare più canali — app, totem, marketplace — o volumi editoriali molto alti. Per un sito vetrina con blog, un CMS tradizionale resta la scelta più sensata.

Scegliere l’architettura proporzionata ai propri obiettivi, senza mode e senza sprechi, è il tipo di consulenza che trovate in Publilia.