Le piattaforme di hosting statico hanno cambiato il modo di pubblicare i siti: colleghi un repository, indichi il comando di build e la cartella di output, e a ogni commit il sito viene ricostruito e distribuito su una rete di server nel mondo. Dietro questa semplicità ci sono però alcuni concetti che conviene conoscere, perché da essi dipendono il comportamento degli URL, la sicurezza dei segreti e la velocità degli aggiornamenti.
Cosa fa davvero un CDN
Un CDN (Content Delivery Network) è un insieme di server distribuiti in molte località. Quando un utente richiede una pagina, risponde il nodo più vicino, che ha una copia dei file. Per un sito statico, il CDN è spesso l'hosting stesso: i file vengono caricati direttamente sulla rete di distribuzione al momento della pubblicazione.
Il vantaggio non è solo la velocità. Un CDN assorbe i picchi di traffico, termina le connessioni HTTPS vicino all'utente e può applicare regole (header, redirect, compressione) senza che tu debba gestire un server.
Il flusso di pubblicazione
Build riproducibili
La piattaforma esegue la build in un ambiente pulito a ogni pubblicazione. Questo significa che tutto ciò che serve deve essere dichiarato nel progetto: versione del linguaggio o di Node, dipendenze bloccate in un file di lock, comando di build esplicito. Se il sito "funziona sul mio computer" ma non sulla piattaforma, quasi sempre manca una di queste informazioni.
Deploy atomici
La maggior parte delle piattaforme pubblica in modo atomico: la nuova versione viene caricata per intero e solo alla fine il traffico passa da quella vecchia a quella nuova, in un colpo solo. Non esiste un momento in cui il sito è mezzo vecchio e mezzo nuovo. Inoltre, le versioni precedenti restano disponibili e tornare indietro richiede un clic.
Anteprime
Per ogni ramo o richiesta di modifica la piattaforma può creare un indirizzo di anteprima separato. È lo strumento ideale per far verificare una modifica prima di pubblicarla. Ricorda però che le anteprime sono pubbliche se qualcuno conosce l'indirizzo: non dovrebbero contenere dati riservati e non dovrebbero essere indicizzate. Molte piattaforme aggiungono automaticamente un header X-Robots-Tag: noindex sugli indirizzi di anteprima, ma verificalo.
Redirect e rewrite
Le regole di instradamento si scrivono in un file di configurazione della piattaforma. La sintassi varia, ma i concetti sono comuni:
- Redirect: il browser riceve un codice 301 o 302 e cambia indirizzo. Serve per URL spostati o rinominati.
- Rewrite: il server serve un file diverso mantenendo l'URL richiesto. Serve, per esempio, alle applicazioni a pagina singola, dove tutte le rotte devono restituire
index.html.
Un esempio in stile file di configurazione:
/vecchio-articolo /nuovo-articolo 301
/blog/* /articoli/:splat 301
/app/* /app/index.html 200
L'ultima riga è un rewrite (codice 200). Attenzione: un rewrite "prendi tutto" verso index.html fa sì che anche gli URL inesistenti rispondano con 200. Se il sito non è un'applicazione a pagina singola, preferisci restituire una vera pagina 404.
La pagina 404
Quasi tutte le piattaforme servono automaticamente un file 404.html dalla radice del sito, con il codice di stato corretto. Crealo: è la pagina che vedono gli utenti che seguono link rotti, e conviene che offra una ricerca o i link principali.
Header personalizzati
Header di sicurezza e di cache si configurano nello stesso file o in un file dedicato, associandoli a percorsi:
/*
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
/assets/*
Cache-Control: public, max-age=31536000, immutable
Dopo ogni modifica controlla le risposte reali: un errore di sintassi nel file di configurazione spesso viene ignorato senza avvisi.
Variabili d'ambiente e segreti
Qui si nasconde l'errore più pericoloso. Le piattaforme permettono di definire variabili d'ambiente per la build, e molti framework rendono disponibili nel codice del browser le variabili con un certo prefisso. Tutto ciò che finisce nel JavaScript inviato al browser è pubblico: chiunque può leggerlo negli strumenti per sviluppatori.
- Le chiavi pensate per il browser (chiavi pubbliche di servizi, identificativi di analytics) possono stare nel bundle, purché limitate lato servizio, per esempio ai tuoi domini.
- Le chiavi segrete (accesso a database, API a pagamento, token amministrativi) non devono mai finire nel bundle. Vanno usate solo in funzioni lato server.
- Non salvare segreti nel repository, nemmeno in rami privati: la cronologia di Git li conserva.
Funzioni serverless ed edge
Quando un sito statico ha bisogno di un po' di logica (inviare un form, chiamare un'API con una chiave segreta, verificare un token), le piattaforme offrono piccole funzioni eseguite su richiesta. Le funzioni serverless girano in genere in una regione; le funzioni edge girano sui nodi del CDN, vicino all'utente, con limiti più stretti su durata e risorse.
Trattale come qualunque codice lato server: valida l'input, gestisci gli errori, limita la frequenza delle richieste e non restituire mai dettagli interni nei messaggi di errore.
Invalidare la cache del CDN
Con i deploy atomici, la piattaforma di solito invalida automaticamente la cache dei file modificati. Se invece usi un CDN separato davanti a un'origine, potresti dover avviare manualmente lo svuotamento (purge) dopo una pubblicazione. La strategia più robusta resta quella dei nomi di file con hash per gli asset e di una cache breve o validata per l'HTML: così l'invalidazione diventa quasi superflua.
In sintesi
- Un CDN serve i file dal nodo più vicino all'utente e assorbe i picchi di traffico.
- Rendi la build riproducibile e sfrutta deploy atomici e anteprime, che non vanno indicizzate.
- Distingui redirect e rewrite e servi una vera pagina 404 con il codice corretto.
- Tutto ciò che finisce nel JavaScript del browser è pubblico: i segreti vanno solo nelle funzioni lato server.
- Tratta le funzioni serverless ed edge come codice di backend a tutti gli effetti.
