La prima rotta — WordPress headless, perché ho separato il CMS dal sito

Ogni sito che costruisco parte da una domanda, prima ancora di aprire l’editor: dove vive il contenuto, e come ci arriva. È da questa domanda che ho scoperto WordPress headless.

Stavo lavorando al sito di un cliente — una piccola azienda siciliana, buoni contenuti, buona storia da raccontare — e la pagina ci metteva quasi cinque secondi a caricarsi. Cinque secondi. Nel 2023. Ho guardato lo schermo e ho pensato: questo non è un problema di hosting. Questo è un problema di architettura.

Da lì è cominciata una rotta nuova.

Per anni ho costruito siti con WordPress nel modo classico: tema, plugin, tutto insieme, tutto nello stesso posto. WordPress gestisce i contenuti, WordPress genera le pagine, WordPress le serve al browser. Un sistema compatto, collaudato, che funziona.

Il problema è che “funziona” non sempre significa “funziona bene”.

Pensa a una barca con motore, cabina e coperta tutti stipati in sette metri. Galleggia. Parte. Ma è pesante, lenta, e ogni volta che aggiungi qualcosa rischi di destabilizzare tutto il resto.

L’architettura headless separa le cose. Mette i contenuti da una parte — nel CMS, in questo caso WordPress — e il sito visibile agli utenti dall’altra, in un frontend moderno costruito con tecnologie pensate apposta per essere veloci. Nel mio caso: Next.js, un framework che ho scelto perché mi permette di costruire pagine che si caricano quasi istantaneamente e che Google ama per questo.

CMS sta per Content Management System — il sistema che usi per scrivere, modificare e organizzare i contenuti. WordPress, in questa configurazione, smette di essere il sito e diventa solo il magazzino. Un magazzino potente, con un’interfaccia che conosco bene e che i miei clienti riescono a usare senza assistenza.

Il “testa” separata dal “corpo”, in inglese: headless, appunto. Il CMS non ha più una faccia — quella la costruisco io, dal principio, con gli strumenti che voglio.

La domanda che mi faccio spesso, e che immagino ti stia facendo anche tu, è: vale la pena?

La risposta onesta è: dipende da cosa stai costruendo.

Per un sito vetrina da cinque pagine aggiornato due volte l’anno, probabilmente no. Ma per un sito aziendale con un blog attivo, una sezione portfolio dinamica, integrazioni con strumenti esterni, e la necessità di performare bene sui motori di ricerca? Sì. La complessità in più in fase di sviluppo si ripaga nel tempo.

Quando ho rifatto il sito di Digitalstudiolab con questa architettura, la differenza l’ho vista subito. Le pagine caricate prima. La struttura era più pulita. E soprattutto: potevo intervenire sul frontend senza toccare i contenuti, e viceversa. Due ambienti separati, due responsabilità separate. Meno rischi, più controllo.

Per un cliente tipo — un imprenditore che pubblica articoli, aggiorna i servizi, carica nuove foto — non cambia quasi nulla. Continua ad accedere alla sua area WordPress, scrive, salva. Quello che succede dopo, la trasformazione del contenuto in una pagina veloce e ben costruita, è roba mia. Lui non la vede. Sente solo che il sito funziona.

E alla fine, è questo che conta.

Separare il CMS dal frontend non è una scelta tecnica astratta. È una scelta di responsabilità: decidi consapevolmente come vuoi che le informazioni viaggino, chi le gestisce e dove arrivano.

Ho imparato che l’architettura non si sceglie per fare i fighi. Si sceglie perché risolve un problema reale.

Il problema reale, in quel momento, era un sito che ci metteva cinque secondi a caricarsi.

Nel prossimo capitolo ti racconto come i contenuti di WordPress arrivano effettivamente al sito — senza che i due sistemi si tocchino mai direttamente.

Quella scelta ha cambiato il modo in cui lavoro. E credo possa cambiare anche il tuo sito.

To be continued…..