Qual è il miglior Headless CMS? I vantaggi di Drupal

Conosci le potenzialità di un CMS decoupled? Capiamo di cosa si tratta, in quali occasioni conviene usarlo e quali sono le caratteristiche di Drupal headless, una delle soluzioni più mature sul mercato.

Cos’è un CMS headless?

Per capire cosa si intende con “headless CMS” conviene partire dal modello tradizionalmente adottato per costruire siti web, in cui la pagina web viene generata dal server. Concretamente: l’utente digita la URL nel browser, il server riceve la richiesta, genera una pagina HTML, la invia al browser e l’utente la visualizza.

Come cambia quando usiamo un CMS headless come può essere, ad esempio, Drupal headless? In questo caso la logica della pagina viene in gran parte costruita sul frontend e non più sul backend, il quale viene usato solo come fonte di dati. Il frontend disaccoppiato non gira però necessariamente solo nel browser dell’utente: oggi lo standard è servirlo tramite architetture SSR (Server-Side Rendering) o SSG (Static Site Generation) su Node.js o edge, con framework come Next.js e Nuxt, che pre-renderizzano l’HTML e lo consegnano già pronto, con benefici diretti su SEO e Core Web Vitals.

Nel caso del sito di un giornale online, per esempio, il backend è la fonte del contenuto, cioè degli articoli. Quando un utente apre la homepage del sito, la pagina che visualizza è un contenitore vuoto in cui il frontend, tramite una richiesta al server, carica il contenuto e lo mostra secondo le logiche che sono state impostate.

Di fatto usare un headless CMS significa separare il backend e il frontend: il CMS (backend) rimane “headless”, ossia senza la testa, dove la testa è il frontend, ora gestito da un’applicazione separata che può eseguire il rendering nel browser, su un runtime Node.js o su un nodo edge. Per questo motivo parliamo anche di CMS decoupled, cioè “disaccoppiato”, a indicare la divisione di una coppia (backend + frontend) tradizionalmente inseparabile.

Un CMS headless è un sistema di gestione dei contenuti solo backend: modella, archivia e pubblica i contenuti, ma non genera le pagine. Il frontend è un’applicazione separata che li recupera via API (REST, JSON:API o GraphQL) e li renderizza su qualsiasi canale, dal sito web all’app mobile, lato server, in build o nel browser.

Un CMS headless è un sistema di gestione dei contenuti solo backend costruito come repository di contenuti che rende il contenuto accessibile tramite API per la visualizzazione su qualsiasi dispositivo in ottica omnicanale.

CMS headless: quali esigenze soddisfano

La logica headless nasce per soddisfare alcune esigenze concrete sempre più sentite nel web moderno , da quelle estetiche a quelle di performance. Qualche esempio:

• Migliorare la UI arricchendo le pagine con animazioni, elementi dinamici e soluzioni grafiche d’impatto, il tutto senza rallentare eccessivamente il caricamento degli elementi, sfruttando le potenzialità oggi offerte dai framework frontend come Angular, React e Vue.

• Disaccoppiare le integrazioni con servizi esterni , oggi sempre più frequenti. Pensiamo a feed di contenuti da sorgenti di terze parti, come i social network, o al social login via Facebook o Google, per fare degli esempi intuitivi.

• Caricare la pagina progressivamente anziché tutta nello stesso momento. Tornando all’esempio del giornale online, è semplice immaginare quanto possa risultare pesante una homepage che deve caricare centinaia di articoli.

Costruire tutto lato server, come nel modello monolitico, diventa poco efficiente quando la web application ha logiche di frontend molto articolate: ogni interazione dell’utente richiede una nuova risposta completa dal server, con il carico di rendering che si accumula su un’unica macchina.

Il modello headless ribalta questa distribuzione del lavoro. Il server si occupa solo dei contenuti, mentre tutto ciò che serve all’utente per vedere la pagina viene costruito progressivamente nel browser, sfruttando la potenza di calcolo del device su cui la pagina viene aperta.

Headless Drupal, uno dei migliori headless CMS

Drupal è storicamente molto adottato da siti content-driven per la sua flessibilità e per gli avanzati strumenti di gestione dei workflow di contenuti che offre (dei vantaggi di Drupal abbiamo parlato qui). Nella nostra esperienza sono proprio queste tipologie di siti web a trarre il più grande vantaggio da un’architettura headless.

Non sorprende quindi che Drupal, negli ultimi anni, abbia lavorato per creare uno dei migliori CMS headless ad oggi presenti sul mercato. Significativa, in questo senso, è l’iniziativa API-First, lanciata nel 2016 e con gli obiettivi principali ormai raggiunti (JSON:API è nel core dalla 8.7 del 2019 e resta nativo in Drupal 10 e 11), che ha coordinato lo sforzo di sviluppo per consentire a Drupal di essere un CMS completamente headless.

Possiamo considerare Drupal uno tra i più maturi CMS headless poiché include nel core la maggior parte delle funzionalità richieste per fare headless. In particolar modo parliamo di REST API e JSON:API.

Il grande vantaggio di Drupal headless sta proprio nel fatto di avere nel core questi moduli supportati dalla community e dai core maintainer. Moduli testati, stabili, con paradigmi standard ben documentati, e pronti per la produzione.

Unendo Drupal a un framework frontend javascript come Angular, React o Vue, è possibile massimizzare il vantaggio ottenuto: da un lato un potente backend , dall’altro un frontend ideale per creare una UI sofisticata e ricca di interazioni.

POTREBBE INTERESSARTI ANCHE: oggi il percorso di aggiornamento porta a Drupal 10 o Drupal 11, dove i moduli REST e JSON:API restano nel core e le API descritte in questo articolo funzionano senza modifiche. Per chi vuole ricostruire il tragitto, il nostro pezzo Drupal 9, perché e come fare l’upgrade documenta il passaggio dalla 8 alla 9, una versione uscita dal supporto il 1° novembre 2023. Se invece stai valutando Drupal come piattaforma per l’intera esperienza digitale, la Guida Drupal: da CMS a DXP mette in fila requisiti, architettura e roadmap di adozione.

Drupal headless con Next.js, Nuxt e Astro

Il frontend disaccoppiato che gira interamente nel browser è la versione del 2018 del modello headless. Oggi i progetti Drupal che seguiamo in produzione servono l’HTML già renderizzato tramite Next.js, Nuxt o Astro, e il browser interviene solo per l’interattività. Il caso più chiaro nella nostra esperienza è Il Giornale: un quotidiano nazionale con una homepage editoriale composta da centinaia di teaser, su cui Drupal fa da backend dei contenuti e il frontend disaccoppiato consegna al browser pagine già complete. Su una pagina di quel tipo, caricare i teaser via JSON:API lato client significa faticare a tenere la LCP sotto la soglia di 2,5 secondi che Google considera accettabile; la stessa pagina pre-renderizzata sul server o in build arriva invece con i metadati SEO già nel markup e senza flash di contenuto vuoto, che per una testata indicizzata su ogni notizia è la differenza tra comparire in Google News e non comparire.

Il progetto di riferimento è next-drupal, distribuito come pacchetto npm con lo stesso nome e affiancato sul lato Drupal dal modulo contrib “Next.js” (machine name next), entrambi mantenuti da Chapter Three: cercateli con questi nomi esatti su npm e su drupal.org, perché esistono fork e pacchetti omonimi non aggiornati. La coppia copre i tre punti su cui di solito naufraga un decoupled fatto in casa: il fetch tipizzato delle entità via JSON:API, la revalidation on-demand (al salvataggio di un nodo Drupal chiama un webhook di Next.js che invalida solo quella pagina, senza rebuild completo) e la preview per gli editor, che dall’interfaccia di Drupal vedono la bozza renderizzata dal frontend reale prima di pubblicarla. Il terzo punto è quello che convince le redazioni: senza preview il decoupled viene percepito come un passo indietro rispetto al Drupal monolitico.

Su Nuxt la strada più solida è il modulo Drupal “Custom Elements” abbinato a nuxtjs-drupal-ce: ogni entità viene esposta come componente serializzato, la logica di layout si sposta su Vue e Layout Builder resta utilizzabile dagli editor. Astro, invece, è la scelta quando la maggior parte delle pagine è statica e solo alcune (ricerca, area riservata, commenti) richiedono rendering a richiesta. Dalla versione 5, rilasciata a dicembre 2024, non serve più impostare una modalità ibrida a livello di progetto: il sito nasce statico e, con un adapter installato, basta disattivare il prerendering sulle singole rotte che devono rispondere a richiesta. Le “isole” completano il quadro limitando il JavaScript spedito al browser ai soli componenti interattivi, con effetti diretti su INP.

In tutti e tre i casi il backend resta lo stesso Drupal 10 o 11 con JSON:API nel core: cambiare framework frontend, o affiancarne un secondo per un canale diverso, non richiede di toccare il modello dei contenuti.

REST API e JSON:API

Drupal include nel core due modi per esporre i contenuti in modalità headless: il modulo REST API, configurabile risorsa per risorsa e più flessibile nel formato, e JSON:API, che segue una specifica standard e pubblica automaticamente tutte le entità con filtri, ordinamenti e relazioni già pronti. Il primo conviene quando servono endpoint su misura; il secondo quando si vuole un’API completa senza scrivere configurazione.

Il modulo RESTful è una componente nativa e consolidata del core: introdotto con la serie Drupal 8 (a partire dalla 8.2, nel 2016), è rimasto nel core senza interruzioni fino a Drupal 10 e Drupal 11 e non richiede alcuna estensione contrib per l’uso in produzione. Esso consente una facile interazione con tutte le entità standard disponibili in Drupal (nodi, utenti, tassonomie, commenti). Accanto ai due moduli core, il modulo GraphQL, distribuito come progetto contrib, è oggi la terza opzione più diffusa per i frontend moderni basati su React, Next.js o Vue, ma va installato e mantenuto separatamente.

Il modulo JSON:API è entrato nel core con Drupal 8.7, nel 2019, ed è rimasto nel core in Drupal 9, 10 e 11: oggi è una funzionalità nativa e consolidata, non più una novità. È concettualmente molto simile a REST API, ma pensato specificamente per il modello headless.

La differenza concettuale tra REST API eJSON:API è che la prima dà una risposta puntuale a una richiesta puntuale, mentre la seconda è pensata per descrivere l’intera pagina. Nel contesto headless, questa impostazione è l’ideale : il frontend può chiedere la descrizione dell’intera pagina al backend, piuttosto che chiedere ogni singolo componente della pagina (come accade con REST API).

Per un confronto più approfondito vi consigliamo di leggere la documentazione.

GraphQL in Drupal: la terza via

Chi arriva da React o Next.js spesso chiede GraphQL prima ancora di sapere cosa sia JSON:API. In Drupal la risposta è il modulo contrib GraphQL, che dalla versione 4 ha cambiato filosofia: la 3.x esponeva automaticamente tutto il modello dei contenuti, la 4.x e le release successive chiedono di scrivere lo schema a mano, con i data producer che mappano ogni campo. È più lavoro all’inizio, ma il frontend riceve un contratto tipizzato, stabile e privo di campi interni che non deve conoscere; con la code generation si ottengono i tipi TypeScript direttamente dallo schema, e una query dichiara in un’unica richiesta il nodo, l’autore, i tag e le immagini con le dimensioni volute. Chi non vuole scrivere lo schema può appoggiarsi a GraphQL Compose, che lo genera dalla configurazione delle entità.

Il prezzo si paga sul caching. JSON:API risponde a GET con URL distinti, quindi page cache, cache tag e CDN funzionano senza configurazione; GraphQL viaggia in POST su un endpoint unico e per farlo passare da Varnish o da un edge cache servono persisted query o una cache applicativa dedicata. Per questo nei nostri progetti il default resta JSON:API, e passiamo a GraphQL quando il frontend deve comporre dati da più entità in una sola chiamata e il team è già attrezzato con Apollo o urql.

Quali sono i vantaggi di un CMS headless?

Migliori performance

Un sito che riceve milioni di richieste al giorno non regge se ogni visita costringe il server a interrogare il database e comporre la pagina da zero. Disaccoppiando backend e frontend, il vantaggio non sta nel spostare il calcolo sul browser dell’utente, ma nel generare le pagine una volta sola e servirle già pronte: con SSG o ISR il frontend produce HTML statico, che viene distribuito e cacheato sui nodi di una CDN. Il CMS risponde solo quando il contenuto cambia, non a ogni visita. Il server viene quindi “sgravato” perché smette di essere sul percorso della richiesta, e la risposta arriva dal nodo edge più vicino con un HTML completo e indicizzabile fin dal primo byte. Ciò si traduce in tempi di caricamento più bassi per l’utente e in una migliore user experience.

Il miglioramento delle performance non è utile solamente in ottica utente ma anche in ottica SEO: pensiamo alla LCP (Largest Contentful Paint), la metrica che misura il tempo di caricamento dell’elemento più grande visibile above-the-fold e che, insieme a CLS e INP (subentrata a FID nel marzo 2024), compone i Core Web Vitals, segnali di ranking per Google dal rollout del Page Experience Update a giugno 2021¹. Il pattern di rendering scelto incide direttamente su questi valori, come mostra la tabella più avanti: se i primi elementi della pagina arrivano tardi, la LCP peggiora e con lei il posizionamento.

Gestire frontend multipli

Numerose aziende hanno la necessità di gestire più di un frontend per dare vita a una strategia omnichannel : uno o più siti web, applicazioni mobile, web app, widget, smartwatch, PlayStation, ecc. Ci troviamo di fronte a frontend diversi che però hanno dei contenuti in comune, gestibili dallo stesso backend grazie a un CMS headless.

Il risparmio di tempi e costi è facilmente intuibile e riguarda tanto lo sviluppo (un backend al posto di svariati backend) e la gestione dei contenuti, più rapida e semplice poiché centralizzata.

Integrazioni con terze parti via frontend

Abbiamo detto che i CMS headless nascono anche per rispondere alla necessità di integrarsi facilmente con terze parti tramite API. Con un CMS decoupled per fare queste integrazioni può non essere necessario che sia il server a comunicare con il servizio esterno : il browser può occuparsene direttamente, via JavaScript, sgravando il server da questa responsabilità.

La facilità e velocità di integrazione apre le porte a diverse opportunità a livello di user experience: dai feed con post di Instagram o Twitter, al social login, alle integrazioni con advertising, analytics, embedding di contenuti. Anche i login alle aree riservate di applicazioni Cloud Native oggi dovrebbero rispettare standard come OAuth 2.0, che ancora una volta ci permettono di integrare il frontend senza necessariamente ri-deployare il backend.

Migliore time-to-market

Scegliere un CMS headless consente di parallelizzare le lavorazioni backend e frontend , impiegando tutto il team nello stesso lasso di tempo.

Lo sviluppo di un sito complesso secondo l’approccio tradizionale richiede che le prime fasi di lavoro si focalizzino sul backend. Durante questo periodo gli sviluppatori frontend non possono lavorare al progetto, e inoltre non è possibile avere un output “visibile” da validare. Si tratta di una inefficienza che con il modello headless viene risolta:il frontend può iniziare a lavorare sullo stile della pagina dando per scontato che, quando il backend sarà pronto, passerà i dati richiesti secondo lo standard concordato.

Le ore di lavoro complessive restano le stesse dello sviluppo tradizionale: quello che cambia è la loro distribuzione nel tempo. Concentrando le attività in parallelo, si riduce il time-to-market e si anticipano le milestone intermedie di verifica e validazione dell’output, così che eventuali correzioni arrivino quando costano ancora poco.

Facilità e velocità di modifica

Il disaccoppiamento tra backend e frontend è una prima iterazione dell’ottica Cloud Native che prevede la suddivisione del progetto in numerosi microservizi indipendenti tra loro. Sappiamo che la presenza di tanti servizi separati, contrapposta a un unico monolite, facilita l’implementazione di modifiche puntuali sui singoli servizi senza avere ripercussioni sulle altre parti dell’applicazione.

Ebbene, con un CMS headless siamo in presenza di una logica simile: se c’è bisogno di un intervento specifico sul frontend, non occorre andare ad apportare modifiche nel backend ma basterà deployare la modifica nel frontend.

I vantaggi di questa possibilità si riscontrano a livello di:

• costo e user experience : modifiche puntuali e più veloci;

• uptime : non ci saranno tempi di downtime legati al mantenimento o all’aggiornamento del sito.

Resilienza e aggiornamenti

In un sito non headless, cosa succede se interviene un nuovo standard per Drupal o per PHP? Spesso questa evenienza comporta la necessità di rifare il sito : un grande costo ma potenzialmente anche un periodo di offline.

Anche questa difficoltà può essere ridotta grazie al disaccoppiamento. In molti casi avere un CMS headless può consentire di modificare solo un pezzo dell’infrastruttura mentre il resto rimane regolarmente attivo. Lavorando con degli standard (REST API e JSON:API), cambiando versione di Drupal o versione di PHP possiamo essere ragionevolmente sicuri che lo standard sia rispettato e che il frontend continuerà a funzionare.

Diventa così possibile reagire alle problematiche e ai cambiamenti del mercato più rapidamente.

Sfide ed esigenze di headless

L’adozione di un CMS headless, come qualsiasi tecnologia, non è esente da sfide.

Questo approccio aumenta la complessità dell’applicazione, perché richiede di creare e mantenere due applicazioni distinte: il backend che genera i contenuti e il frontend che li legge. In termini tecnici significa due deploy, due pipeline, il doppio dei test ed eventualmente il doppio dei container. Aumentando la complessità, aumenta anche il rischio che alcune componenti siano soggette a errori.

Un’altra considerazione da fare, che non è necessariamente uno svantaggio, è cheil team di sviluppo dev’essere multidisciplinare ; deve includere quindi sia sviluppatori backend sia sviluppatori frontend. Per aziende organizzate diversamente questo può comportare un investimento in nuove figure specializzate.

Alla mia azienda conviene scegliere headless?

Per concludere, la scelta di un CMS headless è raccomandata per siti content-driven poiché permette di gestire grandi quantità di contenuti da un solo backend e senza danneggiare la user experience. In questo senso Drupal headless rappresenta una delle soluzioni più mature ed efficienti per disaccoppiare backend e frontend grazie a degli standard sicuri e testati, disponibili nei moduli in core.

Nel caso invece di unsito vetrina poco aggiornato o di una semplice landing page creata per promuovere un prodotto, l’approccio headless ha sicuramente meno senso e un CMS tradizionale potrebbe essere la scelta più giusta.

Se la scelta cade sull’headless, il modo in cui il frontend produce l’HTML pesa su indicizzazione e Core Web Vitals quanto la scelta del CMS: il rendering interamente nel browser è solo uno dei quattro pattern disponibili, e nei progetti che portiamo in produzione è quasi sempre quello da evitare per le pagine pubbliche. Se state valutando questo passaggio, la nostra Guida Drupal: da CMS a DXP mette a confronto architetture, costi e requisiti organizzativi; per un’analisi del vostro caso specifico, il punto di partenza è la pagina dei nostri servizi Drupal.

Note e fonti