Perché utilizzare un CMS headless?

Headless: perché affidarcisi?

Forse non dovrei dire “perché ci sviluppo sopra”, ma se ci pensi è meglio ascoltare anche il parere di uno che ha impiegato anni rompendosi la testa su questo tipo di servizi.
In qualità di sviluppatore, posso dire che è sicuramente il sistema più controllabile e con la miglior performance per gestire i contenuti. Che si tratti di un blog, di un magazine o di qualsiasi genere di contenuti.

Gli svantaggi.

Ce ne sono, ovviamente.
Il meno trascurabile è che ci si appoggia a una serie di servizi che possono essere chiusi o cadere in disuso. ⁠Va comunque detto che morto un provider ce ne sono tanti altri, e che se proprio non ci fosse via di uscita non è da escludere la possibilità di procurarsi autonomamente parte o tutta la pipeline. Un esempio valido viene fornito da Strapi.
Il costo potrebbe essere un punto negativo, ma anche questo aspetto è relativo. ⁠Se rapportiamo il piano di utilizzo gratuito di Contentful o di GraphCMS al costo di mantenere un WordPress un po’ decente, già i costi di gestione scendono. Ovviamente su progetti di alto profilo (solitamente pensati per grandi aziende) sono richieste maggiori attenzioni e più servizi. ⁠Se, come esempio, prendiamo questo sito (pittica.com), che sfrutta come back-end GraphCMS, codice e actions su GitHub, è ospitato da Firebase e sfrutta una CDN per un costo medio di 0€/mese. ⁠La questione costo direi sia contenuta. Certo c’è da contare una spesa complessiva di qualche euro all’anno per le parti in PHP per attivare le automazioni.
La difficoltà nel realizzare ambienti staging è recepita da alcuni come un ostacolo insormontabile. Anche su questo punto avrei qualche dubbio. Dipende dalla gestione della cosa. ⁠La soluzione che trovo più pratica è creare realmente due ambienti divisi (due progetti Netlify vanno benissimo) con lo stesso back-end, così da poter legare un ambiente a un branch (per esempio un master e un dev) e, in progettazione, utilizzare le variabili d’ambiente per includere o meno le bozze.
Il multilingua: più che un aspetto tecnico è un aspetto economico. I maggiori provider danno solitamente il limite di due lingue con i piani free. Per quanto riguarda l’aspetto RTL, è una cosa da affrontare in design.

I vantaggi.

La cosa più bella degli headless è che il contributore è obbligato a lavorare secondo progetto. Questo non ha prezzo. Capitano spesso richieste controproducenti lato content, comportamenti anti-SEO da parte degli editor e via così. ⁠Da sviluppatore, ti dico che è sempre una grana tremenda avere un sistema in cui chiunque possa mettere le mani e rischiare la stabilità di un intero lavoro. Con questa tipologia, si lavora secondo versione e progetto, per contenuti e per codice. ⁠”Fra l’idea e la realtà, fra il movimento e l’atto, cade l’ombra”, scriveva Eliot. Non aveva tutti i torti.
La parte legata ai costi è estremamente analizzabile. Saprai con precisione quanto consumi e come. Che sia un aspetto economico o tecnologico (estremamente legati al tempo del cloud), puoi analizzare sempre la performance.
Per chi, come me, vede i visualizzatori dei propri siti come dei piccoli Unni che consumano risorse, gli incubi sono finiti. ⁠Gatsby è la soluzione che consiglio sempre per sviluppare il front-end. Generando contenuti statici, gli unici aspetti da contare sono banda e spazio. ⁠Basta caricare il server con 100000 linee di codice per scrivere “Hello World”, si ritorna agli anni Novanta quando le pagine erano statiche e i problemi erano tutti legati alla connessione dell’utente. Eventuali aspetti dinamici si risolvono con un secondo back-end che fornisca le API. ⁠Questo darà uno slancio anche al fattore sicurezza. Quanti CMS dinamici tra i più diffusi vengono bucati? Tanti. In primis, perché si ha scarso controllo del codice. Nel caso di un sito statico c’è poco da bucare. Per approfondimenti sugli attacchi DDoS rimando a un dettagliato articolo di CMS Wire.
La ricerca: anche in questo caso si è obbligati a utilizzare una ricerca basata su API. ⁠Ci sono tantissimi provider che possono fornire una ricerca che è pura poesia. È un aspetto su cui mi sento sempre di impuntarmi: l’utente scrive male. ⁠Pensa a un signor Mario Rossi che sta cercando contenuti sul tuo sito mentre è in bus e sta percorrendo un tragitto pieno di buche (scenario abbastanza plausibile) e becca due caratteri ogni cinque. Algolia potrebbe risolvere questo problema. ⁠Ragiona un attimo sulla complessità della lingua italiana, quanta gente sbaglia un congiuntivo o un plurale; sembra una cosa ridicola ma ti garantisco che anche le migliori AI toppano su questo. Sono romagnolo e metto la Z anche in “aiuola”, so cosa dico. ⁠Una ricerca strutturata è un validissimo aiuto.
Qualsiasi soluzione headless è tua. Quando ti metterai al tavolo con il tuo fornitore, lui scaverà fra i tuoi bisogni e i tuoi desideri. ⁠Un consiglio (contro il mio interesse) è di scegliere bene e scegliere più fornitori. Finché parliamo del tuo sito aziendale, un fornitore solo può sopperire a molte necessità, ma su progetti complessi sarebbe meglio avere un team. ⁠Dividi i compiti di front da quelli di back. Questo ti darà continuità sul medio periodo e la possibilità di godere di una buona libertà sul lungo.
Un CMS si evolve con il tuo business. Purtroppo è la realtà, potresti dire che la tua azienda di oggi è la stessa di dieci anni fa? Ti sfido a farlo, e se riesci a provarlo creerò una soluzione per te gratuitamente. ⁠Questo non accade perché l’analisi di un’azienda porta alla luce sempre cambiamenti e, come i telomeri di una persona si allungano, anche le crepe nel business di un’azienda si allargano. ⁠Ci sono esempi di aziende che hanno mantenuto le loro perle invariate nelle decadi, ma di piccole dimensioni.

Un piccolo confronto.

Per fare un paragone, metto a confronto sfruttando Lighthouse (presente in ogni browser Chrome) un sito di una nota casa automobilistica artigianale inglese e il sito pittica.com.
Mettendo i due siti a confronto, a cache vuota e in incognito, testando per mobile otteniamo questi risultati.

Nel primo caso abbiamo un WordPress, altamente ottimizzato, con un tema Jupiter e un tema child customizzato.

Nel secondo, un Gatsby, pieno di patacche grafiche e costruito sfruttando la libreria Bulma.
La cosa bella è che, originariamente, il backend di pittica.com era proprio WordPress.
Come ho fatto questo test io, puoi farlo anche tu, prendendo uno dei siti da Gatsby Showcase e fare qualche confronto.

Il mercato oggi.

Questo è il motivo per cui scrivo questo articolo e lo scrivo oggi.
Escludo l’headless commerce che è un’altra cosa; similare come concetto, ma richiede una progettualità diversa e dicendola tutta non tutte le aziende sono pronte a gestirlo. Anche se importanti player stanno offrendo soluzioni veramente rilevanti. Di questo parleremo in un altro articolo perché a mio avviso appartiene a un altro segmento del mercato. Giusto per non fare di tutta l’erba un fascio.
Comunque, in quest’ultimo periodo mi sono capitati sotto gli occhi molti articoli, tra cui una ricerca americana molto ben strutturata. Alcuni post parlavano di evoluzione del mercato, altri di confronti tra front-end in Ruby o sfruttando React. Per cui ho ben pensato di farci una ragionata e scrivere questo articolo.
Mentre una volta si poteva parlare di transizione, di passaggio su generatori statici a fronte di quelli dinamici, oggi direi che ci sia una scissione. Chi ha optato per qualcosa di headless non torna indietro, continua a ottimizzare il processo. Chi si è cementato su sistemi dinamici, a fatica passerà a qualcosa di diverso.
La differenza la faranno le start-up, le nuove aziende che devono nuotare veloci per crescere e che solitamente accettano loro malgrado i compromessi, ma accolgono positivamente le collaborazioni. ⁠Un’azienda nata oggi, il cui business è collegato ai contenuti digitali, tenterà di ottimizzare al massimo la performance e la metodologia di produzione.
Per avere un’istantanea del mercato odierno e capire anche quali siano i CMS maggiormente utilizzati, ho trovato utile spunto in un trend di builtwith.com da cui emerge che il più utilizzato dai siti più visitato è Sanity, mentre in Italia e nel resto del mondo viene impiegato soprattutto Strapi.

Parlando di percentuali…

Globalmente, il CMS più utilizzato rimane WordPress con un 43.04% di utilizzo. Il secondo è Wix con un 6.97%, mentre Netlify è al diciottesimo posto con un 0.59%.
Se invece ci rapportiamo ai 10000 top sites, troviamo al quindicesimo posto Netlify con un 2.57% e al sedicesimo Contentful con un 2.49%.
Dal 2017 al 2020, molti CMS headless hanno visto raddoppiare ogni anno il numeri di utenti. ⁠Va forse detto che nel 2021 il mercato si è un po’ saturato per effetto di quanto descritto in precedenza: chi doveva agire ha agito.

Per concludere.

Tentando di essere meno tecnico e markettinico possible, credo di averti spiegato a grandi linee a che punto siamo e di averti illustrato perché un CMS headless è la Pagani dei CMS: veloce, potente, unico.
Se il tuo core business ha una grossa componente rappresentata dalla comunicazione, ragionaci. ⁠Nel dubbio contattaci, potremmo avere qualcosa di adatto a te!