Addio CMS: abbiamo rifatto host.it con Astro, e il marketing ora va da solo
Team Host.it 9 min di lettura
Il marketing corre da solo
Da CMS a sito statico con Astro
Per anni il nostro sito è stato quello che consigliavamo ai clienti: un CMS, un database, PHP e un pannello di amministrazione. Funzionava. Ma ogni modifica di una landing passava da un ticket, ogni plugin era una dipendenza da aggiornare e ogni componente dinamico aumentava la superficie da proteggere.
Il nuovo host.it è un’altra cosa: HTML statico, generato con Astro, servito dalla nostra CDN e pubblicato da una pipeline in cui il team marketing lavora senza aspettare uno sviluppatore. Qui raccontiamo l’architettura, il perché delle scelte e anche i suoi limiti, perché non è la risposta giusta per tutti i progetti.
Perché siamo usciti dal CMS
WordPress, Joomla e gli altri CMS hanno reso il Web accessibile a milioni di persone e continuano a essere strumenti adatti a molti progetti. Ma il nostro sito istituzionale aveva esigenze diverse: la maggior parte delle pagine cambia quando lo decide il marketing, non a ogni richiesta HTTP.
- Il 90% del sito non era dinamico. Pagine prodotto, listini e contenuti istituzionali non avevano bisogno di essere rigenerati dal server a ogni visita.
- La superficie di attacco non era proporzionata. Runtime PHP, database, pannello amministrativo e plugin richiedono aggiornamenti e controlli continui, anche quando il sito deve soltanto mostrare contenuti.
- Il collo di bottiglia era organizzativo. Per modificare una pagina servivano competenze distribuite tra copywriting, grafica, sviluppo e rilascio.
Cosa fa Astro, in termini tecnici
Astro è un framework moderno progettato per siti orientati ai contenuti. Durante la build trasforma componenti, dati e pagine in file HTML già pronti da distribuire. Quando un visitatore apre host.it, il server non deve interrogare un database né eseguire PHP per comporre la risposta.
Zero JavaScript per impostazione predefinita
Astro invia al browser HTML e CSS. Il JavaScript viene aggiunto soltanto ai componenti che devono essere davvero interattivi: il visitatore non scarica un’applicazione completa per leggere una pagina.
Architettura a isole
Un form, un configuratore o un widget possono diventare un’isola interattiva, caricata quando serve. Il resto della pagina rimane HTML statico. Questo riduce il codice eseguito nel browser e rende più semplice controllare prestazioni e comportamento.
Componenti e contenuti validati in fase di build
Pagine e componenti vengono controllati prima della pubblicazione. Se manca un dato necessario, un collegamento non rispetta lo schema o il progetto non compila, la pipeline si ferma: l’errore non viene scoperto dal cliente in produzione.
Il risultato: file statici pronti per la CDN
L’output finale è una cartella di file HTML, CSS, JavaScript e immagini. Non c’è un processo applicativo da avviare e non serve una sessione utente per mostrare una pagina. Il tempo di risposta dipende soprattutto dalla rete e dalla posizione del nodo CDN, non dal lavoro di un’applicazione a ogni visita.
Sicurezza by design, non sicurezza per slogan
Dire che un sito è «non vulnerabile» sarebbe tecnicamente scorretto: repository, pipeline CI/CD, account, dipendenze, DNS e CDN restano componenti da proteggere. Il vantaggio concreto è un altro: nel sito pubblico spariscono intere classi di vulnerabilità applicative tipiche di uno stack dinamico.
- Niente PHP in esecuzione. Non esiste un runtime pubblico attraverso cui eseguire codice lato server o caricare una webshell.
- Niente database per comporre le pagine. Non ci sono query esposte alla navigazione e quindi non c’è SQL injection sul contenuto statico.
- Niente pannello amministrativo pubblico. Non esiste una pagina di login del CMS da sottoporre a brute force o credential stuffing.
- Niente catena di plugin nel perimetro pubblico. Il visitatore non interagisce con estensioni server-side da mantenere e aggiornare continuamente.
- Contenuto pubblicato in modo controllato. Per modificare il sito bisogna passare dalla pipeline di build e deploy, protetta e tracciata.
CDN e funzionalità “online sempre”
Il nuovo sito è distribuito dalla nostra CDN: le pagine vengono replicate e servite dai nodi edge vicini agli utenti. Questo riduce latenza e carico sull’infrastruttura di origine.
C’è però un beneficio che va oltre la velocità. Con la funzionalità “online sempre”, la CDN può continuare a servire la copia statica del sito anche se il server di origine non è temporaneamente raggiungibile. Una manutenzione o un guasto dell’origine non devono trasformarsi automaticamente in un sito offline.
In questa architettura l’origine è indispensabile per pubblicare una nuova versione, ma non per generare ogni pagina richiesta. Il contenuto già distribuito rimane disponibile sulla rete CDN.
La pipeline AI: superpoteri al marketing
Il cambiamento più importante non è soltanto nell’infrastruttura. Prima, per pubblicare una nuova pagina prodotto, servivano interventi separati di copywriting, grafica, sviluppo frontend, revisione e deploy. Oggi il team marketing può gestire l’intero ciclo con una pipeline assistita dall’AI.
- Contenuti. Stesura e revisione dei testi con struttura, SEO, tono di voce e traduzioni gestiti nello stesso flusso.
- Grafica. Copertine e asset visivi prodotti nei formati richiesti dal design system.
- Layout. Le pagine vengono composte con componenti già approvati: l’AI usa il design system, non lo aggira.
- Test automatici. Build, validazioni e verifiche funzionali vengono eseguite prima della pubblicazione.
- Staging e produzione separati. Ogni modifica viene prima generata e verificata in staging, poi promossa in produzione.
Cosa serve per farlo bene, e quando non farlo
Passare a un sito statico non è gratis e non è la risposta universale. Per ottenere un risultato affidabile servono un design system solido, una pipeline CI/CD con ambienti separati, test automatici e una strategia precisa per le parti realmente dinamiche.
- Form e integrazioni. Vanno affidati a endpoint o servizi dedicati, con la stessa attenzione alla sicurezza di qualsiasi applicazione.
- Ricerca e strumenti interattivi. Possono vivere come isole, senza trasformare tutto il sito in un’applicazione JavaScript.
- Aree riservate e dati in tempo reale. Richiedono un backend o un servizio applicativo separato.
Per applicazioni con contenuti personalizzati per utente, e-commerce con prezzi e disponibilità in tempo reale o portali con aree riservate estese, un CMS o un’applicazione dinamica possono restare la scelta giusta. Continuiamo infatti a ospitarne e proteggerne migliaia: il punto non è eliminare il dinamico, ma usarlo solo dove crea valore.
Più veloce, più resiliente, più autonomo
Il nuovo host.it è più veloce, ma soprattutto è più difficile da compromettere, più resiliente e più facile da aggiornare. Prestazioni, sicurezza e autonomia del marketing derivano dalla stessa scelta: generare una volta, verificare e distribuire ovunque.
Se realizzate siti per i clienti e volete capire se questo modello ha senso per il vostro portfolio, parliamone. Per organizzare rilasci controllati potete approfondire il nostro servizio di staging e sviluppo.
In evidenza · Host.it
Datacenter e cloud in Italia
Torino, Pisa e servizi ridondati per continuità e sovranità dei dati.
Articoli correlati
Dal blog
Dall' archivio