Decidete cosa deve consegnare la CDN
Iniziate con un inventario. Separate asset versionati come immagini, fogli di stile, script, font e download da HTML, API, pagine account, checkout e amministrazione. Le CDN spesso popolano una cache on demand: la prima richiesta può raggiungere l'origin, mentre le richieste successive corrispondenti possono essere servite all'edge. Un edge vicino e un cache hit sono benefici diversi.
Annotate l'host, l'applicazione, il bucket di storage o il load balancer che fornisce ogni percorso; deve rispondere a un cache miss.
Iniziate con gli asset identici per ogni visitatore che possono rimanere disponibili in sicurezza fino alla scadenza dichiarata.
Non condividete dashboard personalizzate, pagine legate alla sessione o dati cliente a meno che un ingegnere qualificato non abbia progettato e testato la separazione.
Impostate la policy di cache dal comportamento del contenuto
Le intestazioni di risposta HTTP esprimono il comportamento di cache. Cache-Control dice se una risposta può essere memorizzata e per quanto tempo rimane fresh; un time to live, o TTL, è quel periodo di freschezza. Un browser è una cache privata, mentre una CDN è di solito condivisa. Usate intestazioni esplicite. Lo standard HTTP consente di impostare s-maxage per separare la durata delle cache condivise da max-age.
Pubblicate una nuova URL quando il contenuto cambia, ad esempio un nome file con content-hash, poi date alla versione immutabile una lunga durata documentata.
Scegliete una durata breve o un comportamento di validazione basato sul costo di contenuti stale; non riutilizzate una regola per asset per prezzi, inventario o stato account.
Usate private per risposte destinate a un singolo utente. Un cookie da solo non rende una risposta sicura per una cache condivisa.
Fate dell'invalidation l'eccezione, non il piano di rilascio
L'invalidation, o purging, ordina a una CDN gestita di eliminare oggetti memorizzati selezionati prima della scadenza normale. Usatela per correzioni, non per ogni deploy. Confermate che l'origin stia già restituendo la sostituzione prima di effettuare il purge; altrimenti un refill può preservare la risposta errata. Le cache dei browser sono fuori dal controllo del purge della CDN, quindi il versionamento delle URL rimane affidabile per file che cambiano.
Preferite un percorso specifico, un gruppo di release o un tag di cache supportato dal provider rispetto a un purge dell'intero sito; miss ampi possono caricare improvvisamente l'origin.
Un purge distribuito potrebbe non raggiungere ogni edge contemporaneamente. Controllate le semantics di completamento del provider e testate un URL rappresentativo.
Registrate la vecchia e la nuova URL, la regola di cache, l'ambito del purge, il risultato atteso e il passo di inversione.
Tenete l'origin dietro lo strato di delivery
L'accesso diretto all'origin può bypassare il caching della CDN e i controlli edge. Restringetelo in modo che la CDN, e solo i percorsi intesi, possano raggiungerlo. A seconda dello stack, usate controllo di accesso cloud-origin, regole di firewall con intervalli di egress CDN documentati, networking privato, richieste origin firmate o mutual TLS (mTLS), dove entrambe le parti si autenticano con certificati.
Da una posizione di test autorizzata, confermate che l'origin rifiuta richieste pubbliche mentre il nome host CDN funziona.
Limitate health check, strumenti di deploy e accessi interni per identità e rete anziché con una regola pubblica ampia.
L'autenticazione all'origin differisce per CDN e origin. Usate le linee guida attuali del provider e una revisione di sicurezza.
Trattate TLS come due connessioni
HTTPS all'edge protegge la connessione visitatore→CDN, ma la connessione CDN→origin necessita anch'essa protezione. Richiedete cifratura su entrambe le tratte, validate il certificato dell'origin per la modalità CDN e assegnate la proprietà dell'hostname e del rinnovo. OWASP raccomanda TLS 1.3 come default e consente TLS 1.2 per compatibilità; dice che TLS 1.0 e 1.1 dovrebbero essere disabilitati. Ottenete una revisione qualificata per dati regolamentati, flussi di pagamento o compatibilità client insolita.
Elencate i proprietari dei certificati edge e origin, le rotte di rinnovo e la risposta a un guasto.
Testate i redirect HTTP→HTTPS, canonical-host e i deep-link per loop o percorsi persi.
La cifratura non rende una risposta sicura da mettere in cache; impostate regole di cache separate per pagine autenticate, personali e adiacenti al pagamento.
Testate il percorso reale di delivery prima di cambiare il traffico
Iniziate su un hostname di staging o un percorso di produzione ristretto, poi testate il nome host della CDN, non solo l'origin. Chrome DevTools Network mostra stato della richiesta, dominio, timing, dimensione e intestazioni. Testate un hard reload con cache vuota per approssimare una prima visita, poi una visita ripetuta per ispezionarne il riuso. Confrontate intestazioni e contenuto attesi, non solo una pagina che sembra più veloce. Ripetete da regioni rappresentative quando il pubblico è distribuito.
Ispezionate Cache-Control e le intestazioni provider cache-status. Confermate che gli asset pubblici vengono riutilizzati e che le pagine sensibili non sono inaspettatamente condivise.
Eseguite un miss, la correzione di contenuto stale, un errore dell'origin e il rollback di un asset o di una rotta prima di un lancio esteso.
Salvate URL testati, acquisizioni delle intestazioni, versione della route-rule e tempi before-and-after con il registro del cambiamento.
Scegliete una CDN in base alle esigenze operative, poi dimostatela
Non scegliete una CDN solo per il numero di point-of-presence o una generica affermazione di velocità. Le prestazioni variano con geografia, orario, distribuzione del traffico, routing e ratio di hit della cache. Confrontate i candidati su rotte, asset e regioni rappresentative. Chiedete se ciascuno supporta i controlli di cache necessari, l'invalidation mirata, la restrizione dell'origin, il workflow dei certificati, i log, i ruoli di accesso, i prezzi, il supporto e il processo di modifica.
Usate intestazioni di cache identiche, comportamento dell'origin e pagine uguali per i candidati; registrate separatamente risultati di prima-visita e visita-ripetuta.
Revisionate costi di richiesta, trasferimento, invalidation, logging e supporto, più un picco di cache-miss. Prezzi e controlli variano per piano.
Richiedete configurazione esportabile, least privilege, rollback testato e proprietà chiara prima di coprire rotte critiche.