Quando si deve realizzare un sito web, una delle prime decisioni riguarda la tecnologia con cui verranno gestiti i contenuti.
Le possibilità sono molte, ma semplificando possiamo ricondurle a tre approcci:
- utilizzare un CMS come WordPress;
- realizzare un sito statico;
- sviluppare un sistema proprietario per la gestione dei contenuti.
A prima vista possono sembrare semplicemente tre modi diversi per ottenere lo stesso risultato. In realtà cambiano profondamente il modo in cui il sito viene aggiornato, mantenuto ed evoluto nel tempo.
La scelta non riguarda quindi soltanto lo sviluppo iniziale. Riguarda soprattutto cosa dovrà diventare il sito nei prossimi anni.
Che cos’è un sito statico
Un sito statico è composto principalmente da file HTML, CSS, JavaScript e risorse come immagini e font.
Quando un visitatore apre una pagina, il server restituisce un file già pronto. Non è necessariamente necessario interrogare un database o generare la pagina al momento della richiesta.
È un modello molto semplice ed efficiente.
Un sito statico può essere realizzato direttamente scrivendo i file oppure attraverso uno Static Site Generator, che prende contenuti e template e genera automaticamente le pagine finali. Un esempio noto è Jekyll, utilizzabile anche con GitHub Pages.
Questa architettura può essere particolarmente adatta a siti piccoli o che cambiano raramente.
Per esempio:
- una landing page;
- il sito di presentazione di un prodotto;
- una documentazione tecnica;
- un portfolio;
- un piccolo sito aziendale con poche pagine.
Il vantaggio principale è la semplicità.
Ci sono pochi componenti in movimento e le pagine possono essere distribuite molto facilmente anche attraverso una CDN.
Ma proprio questa semplicità può diventare un limite quando il sito deve essere aggiornato frequentemente.
Se non esiste un sistema editoriale dedicato, aggiungere una pagina può significare modificare un file, utilizzare Git, avviare un processo di build e distribuire nuovamente il sito.
Per uno sviluppatore può essere perfettamente normale. Per chi si occupa di marketing o comunicazione può esserlo molto meno.
Cosa cambia con WordPress
WordPress introduce un livello completamente diverso: la gestione dei contenuti viene separata dalla gestione tecnica dei file del sito.
Un redattore può accedere all’area amministrativa, creare una pagina, modificare un articolo, caricare immagini e pubblicare contenuti senza intervenire direttamente sul codice.
La documentazione WordPress dedica infatti sezioni specifiche alla dashboard, alla pubblicazione e alla gestione dei media.
Il contenuto viene memorizzato e organizzato dal CMS, mentre il tema si occupa della presentazione.
Questo rende WordPress particolarmente interessante quando il sito non è qualcosa che viene semplicemente “costruito”, ma uno strumento che viene utilizzato continuamente.
Pensiamo, per esempio, a:
- un blog;
- un sito aziendale aggiornato frequentemente;
- una testata o una sezione editoriale;
- un ecommerce;
- un’area riservata;
- un portale con diversi tipi di contenuto.
WordPress permette inoltre di definire utenti con ruoli differenti, installare plugin e integrare servizi esterni.
La sua REST API consente anche ad applicazioni esterne di leggere o modificare contenuti tramite JSON. WordPress può quindi essere utilizzato non soltanto come CMS tradizionale, ma anche come backend per applicazioni o frontend sviluppati separatamente.
Questo significa che adottare WordPress non obbliga necessariamente a utilizzare sempre l’architettura più tradizionale.
Può diventare anche la componente di gestione dei contenuti di sistemi più complessi.
Il vero vantaggio di un CMS: chi può modificare il sito
Una delle differenze più importanti tra un sito statico e un CMS non è tecnica.
È organizzativa.
Immaginiamo un’azienda che debba modificare il testo della pagina “Servizi”.
Con un sito statico potrebbe essere necessario:
- modificare il file sorgente;
- verificare la modifica;
- ricostruire il sito;
- distribuirlo nuovamente.
In WordPress, normalmente, un utente autorizzato apre la pagina, modifica il testo e salva.
Questo cambia radicalmente il costo delle piccole modifiche.
Non perché WordPress renda ogni operazione gratuita, ma perché consente di spostare molte attività dalla fase di sviluppo alla normale gestione editoriale.
Più un sito viene aggiornato, più questa differenza può diventare rilevante.
Dove un sito statico può essere migliore
Questo non significa che WordPress sia sempre la scelta migliore.
Per un sito di cinque pagine che cambia una volta ogni due anni, installare e mantenere un CMS potrebbe rappresentare una complessità non necessaria.
Un sito statico può avere vantaggi importanti:
Infrastruttura molto semplice
Se il sito deve soltanto distribuire file, i requisiti del server possono essere estremamente ridotti.
Prestazioni
Le pagine possono essere generate in anticipo e distribuite direttamente, evitando parte del lavoro che un’applicazione dinamica deve svolgere durante una richiesta.
Manutenzione applicativa ridotta
Un sito puramente statico non deve mantenere un’applicazione CMS, il relativo database e un ecosistema di estensioni.
Superficie tecnica più piccola
Riducendo i componenti eseguiti lato server si riducono anche molte delle aree che devono essere aggiornate e controllate.
Il prezzo da pagare è spesso una minore flessibilità editoriale.
Dove WordPress diventa più interessante
WordPress tende invece a diventare più interessante quando il sito deve evolvere.
Un progetto può iniziare con cinque pagine e successivamente richiedere:
- una sezione news;
- landing page;
- moduli;
- utenti;
- aree riservate;
- multilingua;
- ecommerce;
- integrazioni con servizi esterni;
- nuovi tipi di contenuto.
WordPress dispone di API, temi, plugin e strumenti dedicati proprio all’estensione del sistema. La documentazione ufficiale mette a disposizione riferimenti per plugin, temi, API, WP-CLI e amministrazione avanzata.
Naturalmente maggiore flessibilità significa anche maggiore responsabilità.
Un’installazione WordPress deve essere mantenuta.
Core, plugin e temi devono essere aggiornati e il sito deve essere monitorato, sottoposto a backup e mantenuto compatibile con l’ambiente server.
E una soluzione proprietaria?
Esiste poi una terza possibilità: sviluppare un CMS specificamente per il progetto.
In questo caso l’azienda può commissionare un sistema nel quale ogni funzione viene costruita intorno alle proprie esigenze.
Può essere una soluzione perfettamente razionale.
Per esempio, se un’organizzazione possiede un workflow molto particolare, un modello dati insolito o deve integrare profondamente diversi sistemi interni, un’applicazione dedicata può offrire un livello di personalizzazione difficile da ottenere con un prodotto generalista.
Il problema è che il software proprietario deve essere progettato, sviluppato e mantenuto.
Funzioni che in un CMS maturo sono già disponibili devono essere sviluppate internamente o dal fornitore.
Pensiamo soltanto ad alcune funzionalità apparentemente banali:
- login;
- recupero password;
- gestione degli utenti;
- permessi;
- editor dei contenuti;
- media library;
- revisioni;
- API;
- ricerca;
- gestione degli errori;
- aggiornamenti.
Quando si realizza un CMS proprietario queste componenti non scompaiono. Semplicemente diventano responsabilità del progetto.
Il costo iniziale è solo una parte del problema
Confrontare queste soluzioni guardando soltanto il prezzo iniziale può essere fuorviante.
È più utile ragionare sul costo totale di gestione nel tempo.
Tra le voci da considerare troviamo:
- sviluppo iniziale;
- hosting;
- manutenzione;
- aggiornamenti;
- backup;
- sicurezza;
- nuove funzionalità;
- assistenza;
- competenze necessarie;
- eventuale migrazione futura.
Un sito statico può avere costi infrastrutturali molto contenuti ma richiedere l’intervento di uno sviluppatore per modifiche che in un CMS sarebbero editoriali.
WordPress può richiedere una manutenzione applicativa maggiore, ma permette spesso al proprietario del sito di svolgere autonomamente molte attività quotidiane.
Un CMS proprietario può adattarsi perfettamente all’organizzazione, ma ogni evoluzione futura dipende dal codice sviluppato e dalle competenze necessarie per mantenerlo.
La domanda giusta quindi non è:
“Qual è la soluzione che costa meno oggi?”
ma:
“Quanto ci costerà utilizzare, modificare e mantenere questa soluzione per i prossimi cinque anni?”
Anche la portabilità ha un valore
Esiste poi un costo difficile da vedere all’inizio di un progetto: quello necessario per cambiare piattaforma.
Prima di scegliere qualsiasi CMS conviene chiedersi:
- posso esportare facilmente i contenuti?
- in quale formato sono memorizzati?
- altri sviluppatori possono lavorare sul sistema?
- esiste documentazione?
- esiste un ecosistema di competenze?
- cosa succede se il fornitore cambia?
- quanto sarebbe complessa una futura migrazione?
WordPress, per esempio, espone tramite REST API risorse come post, pagine, media, utenti, categorie e tassonomie.
Questo non significa che una migrazione sia sempre semplice, ma rende molto chiaro un principio generale:
i contenuti dovrebbero appartenere al proprietario del sito, non alla tecnologia utilizzata per pubblicarli.
Una soluzione ibrida è possibile
Le tre possibilità non devono necessariamente essere considerate compartimenti separati.
Un’architettura può combinare più approcci.
WordPress, per esempio, può essere utilizzato soltanto per la gestione dei contenuti mentre il frontend viene realizzato con un’altra tecnologia.
La REST API di WordPress è progettata proprio per consentire ad applicazioni differenti di interagire con i contenuti del CMS.
In questo scenario i redattori continuano a lavorare con WordPress mentre la parte pubblica del sito può essere sviluppata indipendentemente.
È il principio alla base di molte architetture definite “headless”.
Anche i siti statici possono utilizzare servizi esterni e API, quindi la distinzione tra sito statico e applicazione dinamica oggi è meno netta di quanto possa sembrare.
Quale soluzione scegliere?
Non esiste una risposta valida per ogni progetto.
Un sito statico può essere una scelta eccellente quando:
- i contenuti cambiano raramente;
- il progetto è semplice;
- chi lo gestisce dispone delle competenze tecniche necessarie;
- non servono workflow editoriali complessi.
WordPress può essere particolarmente adatto quando:
- i contenuti vengono aggiornati frequentemente;
- devono lavorare più persone;
- il sito deve evolvere nel tempo;
- servono funzionalità aggiuntive;
- si vuole separare la gestione editoriale dallo sviluppo.
Un CMS proprietario può invece avere senso quando:
- i processi da gestire sono molto specifici;
- il CMS è parte di un’applicazione più ampia;
- le funzionalità richieste sono difficili da ottenere con piattaforme esistenti;
- esiste un budget adeguato anche per manutenzione ed evoluzione.
Pensare al sito come a un sistema, non come a un progetto una tantum
La tecnologia con cui viene realizzato un sito conta.
Ma conta ancora di più capire come verrà utilizzato dopo la pubblicazione.
Realizzare un sito è soltanto il primo passo.
Negli anni successivi qualcuno dovrà aggiornarlo, correggerlo, aggiungere contenuti, adeguarlo alle nuove esigenze e risolvere eventuali problemi.
Per questo la scelta tra WordPress, sito statico e CMS proprietario dovrebbe partire meno dalla domanda:
“Con cosa possiamo costruire questo sito?”
e molto di più da:
“Con cosa vogliamo gestirlo nei prossimi anni?”
È spesso questa seconda domanda a determinare il vero costo — e il vero valore — della piattaforma scelta.