CDN: cos’è, come funziona e quando serve una Content Delivery Network

Una CDN (Content Delivery Network) è una rete distribuita di server che permette di consegnare contenuti web da nodi più vicini o più efficienti rispetto al server di origine. In pratica, invece di obbligare ogni visitatore a recuperare immagini, CSS, JavaScript o altri contenuti sempre dallo stesso server, una parte delle richieste può essere gestita dalla rete CDN.

Il vantaggio non consiste semplicemente nell’avere “copie del sito sparse per il mondo”. Il vero meccanismo combina edge server, caching, routing delle richieste e comunicazione con il server origin. Quando funziona bene, può ridurre la latenza, diminuire il lavoro dell’infrastruttura principale e rendere più efficiente la distribuzione dei contenuti.

Non significa però che ogni sito abbia bisogno della stessa configurazione. Una Content Delivery Network può essere molto utile per un ecommerce internazionale e produrre un vantaggio decisamente più modesto per un piccolo sito locale con pubblico concentrato vicino al data center.

In questa guida vedremo quindi cos’è una CDN, come funziona realmente, cosa può migliorare, cosa non risolve e come capire se serve davvero al tuo progetto.

Cos’è una CDN e cosa significa Content Delivery Network

CDN è l’acronimo di Content Delivery Network, cioè una rete progettata per distribuire contenuti attraverso un’infrastruttura geograficamente distribuita.

La definizione di CDN utilizzata da Cloudflare mette al centro proprio questo principio: avvicinare alla richiesta dell’utente una copia cache dei contenuti, evitando quando possibile di recuperarla ogni volta dal server origin.

Per capire cosa significa davvero bisogna però distinguere tre elementi: origin, edge e cache.

CDN in parole semplici

Immagina un sito ospitato su un server in Europa e visitato anche da utenti negli Stati Uniti, in Asia e in Australia.

Senza una rete di distribuzione, molte richieste devono raggiungere direttamente l’infrastruttura che ospita il sito. La distanza non è l’unico fattore che determina la velocità, ma aumenta il percorso di rete e può incidere sulla latenza.

Con una CDN, alcune risorse possono invece essere disponibili su nodi distribuiti più vicini alla rete dell’utente.

Se la risorsa richiesta è già disponibile nella cache del nodo, non è necessario recuperarla nuovamente dall’origine. È questo passaggio a produrre gran parte del vantaggio.

La CDN quindi non sostituisce il sito e non sostituisce necessariamente il server: introduce uno strato di distribuzione tra chi richiede il contenuto e l’infrastruttura che lo genera o lo conserva.

Origin server, edge server e Point of Presence: i componenti essenziali

L’origin server è il sistema da cui proviene la versione originale del contenuto. Può essere il server del tuo hosting, un’applicazione, uno storage o un’altra infrastruttura autorizzata a rispondere alle richieste.

Se vuoi approfondire il concetto di server, trovi una spiegazione completa nella nostra guida su cos’è un server e come funziona.

Gli edge server sono invece i server della rete di distribuzione che operano più vicino agli utenti dal punto di vista della rete. Più edge server possono essere raggruppati in punti di presenza, spesso indicati con l’acronimo PoP (Point of Presence).

Il flusso semplificato diventa quindi:

utente → rete CDN → edge → eventuale origin → risposta

Non bisogna però interpretare “edge più vicino” soltanto come distanza chilometrica. I provider possono scegliere il nodo sulla base di routing, topologia della rete, disponibilità, congestione e altre condizioni operative.

La funzione resta la stessa: evitare, quando possibile, che ogni richiesta compia inutilmente tutto il percorso fino all’origine.

Cosa cambia quando un sito usa una CDN

Senza caching distribuito, diecimila richieste della stessa immagine possono tradursi in moltissime richieste verso l’infrastruttura originaria.

Se quella risorsa viene memorizzata correttamente all’edge, molte delle richieste successive possono essere soddisfatte direttamente dalla rete.

Questo produce due conseguenze.

La prima riguarda l’utente: una parte dei dati deve percorrere un tragitto di rete più favorevole.

La seconda riguarda il server: l’origin deve gestire meno richieste per le risorse che possono essere servite dalla cache.

Ed è proprio questa seconda conseguenza a spiegare perché una Content Delivery Network può essere utile anche quando il problema non è soltanto la distanza geografica.

Come funziona una CDN: cosa succede quando apri una pagina

La definizione “server distribuiti nel mondo” è corretta, ma da sola non spiega realmente cosa succede.

Il punto decisivo è capire quando risponde l’edge e quando la richiesta deve raggiungere l’origin.

Come la richiesta viene instradata verso un nodo edge

Quando configuri una CDN, il traffico destinato alle risorse interessate viene indirizzato verso l’infrastruttura del provider.

Il meccanismo preciso dipende dall’architettura scelta. Una configurazione può usare un hostname dedicato per gli asset, mentre molte piattaforme moderne funzionano come reverse proxy davanti al sito.

Anche il DNS entra spesso nella configurazione iniziale perché permette di far risolvere il dominio verso l’infrastruttura appropriata. DNS e CDN, però, non sono la stessa cosa: il primo risolve nomi e indirizzi, la seconda gestisce la distribuzione delle richieste e dei contenuti.

Una volta ricevuta la richiesta, la rete seleziona il percorso e il nodo che dovrà gestirla.

Da quel momento diventano fondamentali due possibili condizioni: cache HIT e cache MISS.

Cache HIT e cache MISS: quando risponde la CDN e quando interviene l’origin

Una cache HIT si verifica quando il nodo dispone già di una copia valida dell’oggetto richiesto e può servirla direttamente.

Una cache MISS significa invece che l’oggetto non è disponibile nella cache utilizzabile per quella richiesta. Il nodo deve quindi recuperarlo dall’origin o da un altro livello della rete.

La documentazione sul caching delle CDN di Cloudflare descrive esattamente questa dinamica: dopo una cache miss il contenuto può essere recuperato dall’origine, memorizzato e utilizzato per soddisfare richieste successive.

Questo dettaglio spiega anche perché un singolo test non è sempre sufficiente per valutare la CDN.

La prima richiesta verso un determinato nodo potrebbe produrre un MISS; quella successiva, sullo stesso oggetto e nelle condizioni corrette, potrebbe diventare un HIT.

È inoltre possibile che un contenuto non sia cacheabile, che una regola ne imponga il bypass o che la cache sia stata svuotata.

Per questo MISS non significa automaticamente “CDN rotta”.

TTL, scadenza e purge: come viene mantenuta aggiornata la cache

Una copia distribuita non può rimanere valida per sempre indipendentemente da ciò che succede sull’origin.

Serve quindi stabilire per quanto tempo l’oggetto possa essere considerato fresco.

Qui entra in gioco il TTL (Time To Live) e, più in generale, la politica di caching.

Le intestazioni HTTP permettono di controllare parte di questo comportamento. Per esempio, Cache-Control contiene direttive che possono essere interpretate da browser e cache condivise.

Se modifichi un file prima della sua naturale scadenza, puoi inoltre avere bisogno di invalidare la copia precedente. Questa operazione viene normalmente chiamata purge o invalidazione della cache.

Il problema pratico è facile da riconoscere: modifichi CSS, immagini o contenuti, ma alcuni visitatori continuano a vedere la vecchia versione.

Una buona configurazione deve quindi trovare un equilibrio:

• mantenere abbastanza a lungo in cache ciò che cambia raramente;
• aggiornare velocemente ciò che cambia spesso;
• evitare di distribuire versioni obsolete;
• non costringere l’origin a rigenerare inutilmente risorse immutate.

Per approfondire le differenze fra caching del browser, page cache e altri livelli, puoi leggere la nostra guida al caching in WordPress.

Contenuti statici, dinamici e full-page caching

Immagini, font, CSS e JavaScript sono esempi classici di risorse che si prestano alla distribuzione tramite CDN.

Ma fermarsi ai file statici sarebbe riduttivo.

Piattaforme come Amazon CloudFront documentano esplicitamente la distribuzione di contenuti sia statici sia dinamici. La vera domanda non è quindi soltanto “statico o dinamico?”, ma quale risposta può essere condivisa, per quanto tempo e con quali condizioni.

Una pagina editoriale uguale per tutti può, in determinate architetture, essere cacheata interamente all’edge.

Un carrello ecommerce contenente i prodotti del singolo cliente è tutt’altra cosa.

Lo stesso vale per:

• area personale;
• pagina account;
• checkout;
• dashboard;
• contenuti personalizzati;
• sessioni autenticate;
• risposte API dipendenti dall’utente.

Mettere indiscriminatamente in cache tutto ciò che passa dalla rete non è un’ottimizzazione. È un errore di configurazione.

A cosa serve una CDN e quali vantaggi può offrire davvero

Una Content Delivery Network può intervenire su più problemi contemporaneamente, ma il beneficio reale dipende dal collo di bottiglia che stai cercando di risolvere.

Se il tuo server impiega diversi secondi per generare una pagina non cacheabile a causa di un database lento, aggiungere nodi nel mondo non elimina quella causa.

Se invece servi grandi quantità di risorse cacheabili a utenti geograficamente distribuiti, lo scenario cambia parecchio.

Riduzione della latenza e del carico sul server origin

La latenza è il ritardo che si accumula mentre dati e richieste viaggiano attraverso la rete.

Una rete edge può ridurre una parte di questo percorso. Quando la cache risponde direttamente, inoltre, elimina la necessità di interrogare l’origin per quella specifica risorsa.

Il risultato può essere:

• meno richieste all’infrastruttura principale;
• minore utilizzo della banda dell’origin;
• tempi di risposta più prevedibili;
• distribuzione più efficiente delle risorse cacheabili.

Questo non significa che l’hosting diventi irrilevante.

Quando la cache non può rispondere, la qualità dell’origin torna immediatamente importante.

Picchi di traffico, disponibilità e scalabilità

Supponiamo che una pagina riceva improvvisamente molto traffico.

Se migliaia di richieste devono raggiungere PHP, database e storage dell’origin, l’infrastruttura deve essere dimensionata per gestirle.

Se una grande parte delle richieste viene invece soddisfatta dalla cache distribuita, il carico che raggiunge il backend può diminuire sensibilmente.

È uno dei motivi per cui le reti di distribuzione possono diventare particolarmente interessanti per:

• magazine;
• portali;
• ecommerce;
• campagne con picchi di traffico;
• download;
• immagini e video;
• software e file pubblici;
• siti con pubblico internazionale.

Non è però corretto promettere che una CDN impedisca qualsiasi downtime. L’affidabilità finale dipende dalla rete, dalla configurazione, dall’origin e dai servizi utilizzati.

Sicurezza, DDoS e WAF: cosa dipende dalla CDN e cosa dal provider

Qui serve una distinzione che spesso viene persa.

CDN non significa automaticamente WAF, protezione DDoS, bot management o sicurezza applicativa.

Sono funzionalità diverse che molti provider hanno integrato nella stessa piattaforma.

Una rete che opera come reverse proxy si trova in una posizione utile per filtrare il traffico prima che arrivi all’origin. Il provider può quindi aggiungere protezione DDoS, Web Application Firewall, rate limiting e sistemi anti-bot.

Ma queste capacità dipendono dal servizio e dal piano utilizzato.

Cloudflare, per esempio, integra CDN, DNS, reverse proxy e diversi livelli di sicurezza. Se vuoi approfondire quella piattaforma nello specifico, trovi la nostra guida su cos’è Cloudflare e come funziona.

La regola utile è questa:

la distribuzione dei contenuti è una funzione della CDN; le funzioni di sicurezza vanno verificate separatamente.

CDN e SEO: cosa può migliorare e cosa non cambia automaticamente

Una Content Delivery Network non è un interruttore SEO.

Può intervenire su condizioni tecniche che influenzano l’esperienza della pagina, soprattutto quando riduce la latenza, migliora il tempo di risposta o permette di consegnare più rapidamente una risorsa critica.

Da qui a sostenere che “attivare una CDN aumenta il ranking” c’è però un salto logico che non va fatto.

Quando una CDN può aiutare LCP e TTFB

Il Time To First Byte (TTFB) misura il tempo che trascorre prima che il browser inizi a ricevere la risposta.

Non è uno dei Core Web Vitals, ma può incidere sul processo che porta al caricamento del contenuto principale.

La documentazione di web.dev sull’ottimizzazione del Largest Contentful Paint evidenzia infatti che un TTFB elevato rende più difficile ottenere un buon LCP.

Una CDN può aiutare quando:

• la risorsa LCP viene servita dall’edge;
• il documento HTML può essere cacheato in modo appropriato;
• utenti lontani dall’origin soffrono di maggiore latenza;
• l’origin è alleggerito da una quantità rilevante di richieste cacheabili.

Ma il TTFB può dipendere anche da applicazione, database, hosting, redirect e altre condizioni.

Se vuoi approfondire questa metrica, abbiamo una guida dedicata al TTFB e alle cause che possono renderlo elevato.

Perché INP e CLS non migliorano automaticamente con una CDN

I tre Core Web Vitals sono LCP, INP e CLS. Google li descrive rispettivamente come metriche legate a caricamento, responsività delle interazioni e stabilità visuale. (documentazione ufficiale)

La CDN può avere un rapporto abbastanza intuitivo con il caricamento: se una risorsa critica arriva prima, può contribuire a migliorare la catena che determina LCP.

Per INP il problema centrale è invece la capacità della pagina di rispondere alle interazioni. JavaScript pesante, long task e lavoro sul main thread possono produrre un INP scarso anche quando gli asset sono stati scaricati molto velocemente.

Per CLS entrano in gioco soprattutto movimenti imprevisti del layout: immagini senza dimensioni riservate, banner che appaiono improvvisamente, font, embed o elementi inseriti dinamicamente.

Una CDN può rendere più efficiente il caricamento delle relative risorse. Non corregge automaticamente la logica che causa INP o CLS.

È una differenza importante perché permette di scegliere l’intervento in funzione del problema invece di applicare la stessa soluzione a tutte le metriche.

Core Web Vitals e ranking: la relazione corretta secondo Google

Google afferma che i Core Web Vitals vengono utilizzati dai propri sistemi di ranking, insieme ad altri aspetti della page experience. Allo stesso tempo specifica che ottenere buoni risultati nei report Core Web Vitals non garantisce automaticamente buone posizioni nei risultati di ricerca. (Google Search Central)

La relazione corretta è quindi:

CDN ben configurata → possibile miglioramento di specifiche condizioni di performance → possibile miglioramento dell’esperienza → nessuna garanzia automatica di ranking.

È molto meno spettacolare di “la CDN spinge la SEO”, ma è tecnicamente più utile.

Se un sito è lento perché l’immagine principale pesa diversi megabyte, JavaScript blocca il main thread e il database impiega troppo a generare la pagina, la rete di distribuzione rappresenta soltanto uno dei possibili interventi.

CDN vs hosting, cache e reverse proxy: quali sono le differenze

Molti dubbi nascono perché questi termini vengono usati insieme.

In realtà descrivono funzioni differenti.

Tecnologia	Funzione principale	Dove agisce
Hosting	ospita applicazione, file e dati	infrastruttura origin
Cache server	conserva risposte già generate	server/origin
Cache browser	conserva risorse sul dispositivo	client
CDN	distribuisce contenuti attraverso una rete edge	rete distribuita
Reverse proxy	riceve richieste prima dell’origin e le inoltra/gestisce	davanti all’origin
DNS	risolve i nomi di dominio	sistema di risoluzione

La stessa piattaforma può naturalmente svolgere più funzioni contemporaneamente.

CDN vs hosting: perché uno non sostituisce l’altra

L’hosting fornisce l’ambiente in cui vivono applicazione, file, database e processi che permettono al sito di funzionare.

La rete CDN distribuisce invece determinate richieste e contenuti.

Anche quando utilizzi full-page caching all’edge, hai comunque bisogno di un’origine o di un’infrastruttura dalla quale il contenuto viene prodotto e aggiornato.

Ecco perché la domanda “hosting o CDN?” parte da un presupposto sbagliato.

Nella maggior parte degli scenari la relazione è:

hosting + eventuale cache + CDN

non:

hosting oppure CDN.

Un hosting migliore può essere la scelta più efficace se il problema è il backend. Una rete edge può invece essere particolarmente utile quando pesano distanza, distribuzione geografica, traffico sugli asset o carico sull’origin.

CDN vs cache del browser, server e plugin WordPress

La parola “cache” descrive un principio: riutilizzare una risorsa o una risposta già disponibile invece di ricrearla o riscaricarla inutilmente.

Ma il punto in cui la memorizzi cambia.

La cache del browser vive sul dispositivo dell’utente.
La page cache può vivere sull’hosting.
L’object cache può evitare di ripetere determinate operazioni sul backend.
La CDN cache vive all’interno della rete distribuita.

Questi livelli possono lavorare insieme.

Per esempio, una pagina WordPress può essere generata una volta, memorizzata nella page cache, distribuita tramite edge e infine accompagnata da asset che il browser conserva localmente.

Capire i livelli è molto più utile che chiedersi quale singolo “plugin velocità” risolva tutto.

DNS e reverse proxy: dove entrano nel funzionamento di una CDN

Un reverse proxy riceve le richieste destinate all’origin prima che vi arrivino.

Questo consente di eseguire operazioni come:

• cache;
• routing;
• terminazione TLS;
• filtraggio;
• bilanciamento;
• modifica di request e response.

Molte piattaforme CDN moderne adottano questa architettura, ma non ogni implementazione è identica.

Il DNS viene invece utilizzato per stabilire verso quale infrastruttura risolve un hostname. Cambiare nameserver o record DNS può quindi essere parte dell’attivazione di alcuni servizi, ma il DNS da solo non distribuisce i contenuti e non costituisce una CDN.

Quando conviene usare una CDN e quando può essere superflua

La domanda utile non è “le CDN sono buone?”, ma:

quale problema deve risolvere la rete nel mio caso?

Partendo da qui si evita di attivare un altro livello infrastrutturale senza sapere cosa dovrebbe migliorare.

Siti internazionali, ecommerce, media e picchi di traffico

Il caso più evidente è un sito con visitatori distribuiti in paesi differenti.

Se il tuo pubblico è globale e l’origin si trova in una sola area geografica, la rete edge può ridurre l’impatto della distanza su molte richieste.

Altri scenari interessanti sono:

• cataloghi con molte immagini;
• ecommerce con traffico elevato;
• portali editoriali;
• streaming e contenuti media;
• file da scaricare;
• applicazioni con asset pesanti;
• campagne che producono picchi improvvisi.

Un ecommerce richiede però una configurazione più attenta di un blog statico. Le pagine prodotto possono essere abbastanza cacheabili; carrello, account e checkout richiedono invece regole compatibili con sessioni e contenuti personalizzati.

Siti locali e pubblico vicino al server: quando il vantaggio può essere ridotto

Immagina un sito vetrina rivolto quasi esclusivamente a utenti italiani, ospitato su un’infrastruttura performante vicina al proprio pubblico, con poche pagine e asset già ottimizzati.

Una CDN può ancora fornire altri servizi o migliorare alcuni aspetti tecnici, ma il puro vantaggio geografico può essere molto più contenuto rispetto a quello di un progetto internazionale.

In uno scenario del genere conviene misurare prima di aggiungere complessità.

Potrebbero avere priorità maggiore:

• ottimizzazione delle immagini;
• riduzione del JavaScript;
• caching server-side;
• database;
• qualità dell’hosting;
• eliminazione di richieste esterne lente;
• ottimizzazione del critical rendering path.

Una rete di distribuzione non è inutile per definizione. Semplicemente, il ritorno dell’intervento deve essere confrontato con gli altri colli di bottiglia.

Login, carrello, checkout e contenuti personalizzati: cosa non va messo in cache alla cieca

Il caching diventa più delicato quando la risposta dipende dall’utente.

Immagina che due clienti abbiano carrelli differenti. Se una cache condivisa distribuisse senza controllo la stessa risposta personalizzata a entrambi, avremmo un problema molto più grave di qualche millisecondo risparmiato.

Per questo le configurazioni ecommerce e applicative devono considerare:

• cookie;
• autenticazione;
• sessioni;
• query string;
• URL esclusi;
• API;
• header;
• regole di bypass;
• durata della cache.

Più il sito è dinamico, meno ha senso impostare regole aggressive senza comprendere cosa viene effettivamente memorizzato.

Come verificare se una CDN sta funzionando davvero

Attivare il servizio non conclude il lavoro.

Devi verificare almeno tre aspetti:

1. il traffico sta passando dove dovrebbe;
2. le risorse previste vengono realmente servite dalla cache;
3. le prestazioni degli utenti migliorano nello scenario che ti interessa.

Cache HIT/MISS e header HTTP

Gli header HTTP sono uno dei primi posti in cui guardare.

I provider possono aggiungere intestazioni proprie per indicare lo stato della cache. Il nome cambia da piattaforma a piattaforma, quindi è necessario consultare la documentazione del servizio utilizzato.

Esistono anche header standard utili all’analisi. Cache-Control descrive le direttive di caching; Age, quando presente, indica da quanto tempo un oggetto si trova in una cache proxy.

Puoi controllare gli header anche da terminale:

curl -I https://example.com/percorso/file.css

Oppure usare la scheda Network degli strumenti per sviluppatori del browser.

Il punto non è cercare ossessivamente la parola HIT su ogni richiesta. Devi prima sapere quali risorse dovrebbero essere cacheate.

TTFB e test da località differenti

Un test eseguito soltanto dalla tua connessione racconta una parte della storia.

Se hai implementato una rete di distribuzione per servire utenti in più continenti, il confronto più utile consiste nel misurare il sito da regioni differenti.

Guarda soprattutto:

• TTFB;
• tempo di download delle risorse;
• cache status;
• numero di richieste all’origin;
• differenze fra prima richiesta e successive.

Se il pubblico è quasi completamente italiano, invece, misurare venti località internazionali può essere molto meno utile di un’analisi precisa degli utenti reali.

Dati reali degli utenti e Core Web Vitals

I test di laboratorio permettono di diagnosticare il comportamento di una pagina in condizioni controllate.

I dati sul campo mostrano invece ciò che sperimentano gli utenti reali.

Per valutare un intervento infrastrutturale conviene quindi evitare il classico errore:

prima PageSpeed 62 → dopo PageSpeed 91 → problema risolto.

Un singolo punteggio non ti dice se il cambiamento ha migliorato realmente gli utenti, quali metriche sono cambiate e se l’effetto si mantiene nel tempo.

Confronta i dati prima e dopo l’intervento e separa, quando possibile:

• dispositivo;
• area geografica;
• tipo di pagina;
• utenti anonimi e autenticati;
• risposte cacheate e non cacheate.

Altrimenti rischi di attribuire alla CDN miglioramenti prodotti da altre modifiche eseguite nello stesso momento.

Errori comuni: cache vecchia, regole sbagliate e origin ancora sovraccarico

Una CDN può risultare attiva senza produrre il beneficio atteso.

Fra le cause più comuni trovi:

Cache hit ratio molto basso.
Molte richieste continuano a raggiungere l’origin perché gli oggetti non vengono memorizzati, scadono troppo presto o le chiavi di cache frammentano inutilmente le copie.

TTL troppo breve.
Il nodo deve aggiornare frequentemente risorse che cambiano raramente.

TTL troppo lungo senza corretta invalidazione.
Gli utenti continuano a ricevere contenuti vecchi dopo un aggiornamento.

Query string o cookie gestiti male.
Il sistema crea molte varianti dello stesso contenuto o evita la cache quando potrebbe usarla.

Caching troppo aggressivo.
Pagine personalizzate finiscono dove non dovrebbero.

Origin lento.
Quando si verifica un MISS, il backend resta il collo di bottiglia.

Due sistemi di cache che non lavorano bene insieme.
Plugin, hosting, reverse proxy e CDN possono avere regole differenti e rendere più difficile capire da quale livello provenga una risposta.

La diagnosi deve quindi partire dalla richiesta e seguire l’intero percorso. Non dalla dashboard del provider.

Come scegliere una CDN in base al proprio sito

Non esiste una rete migliore in assoluto.

Esiste quella compatibile con pubblico, contenuti, infrastruttura, competenze e budget.

Copertura geografica e pubblico reale

Una rete enorme sulla carta non è automaticamente quella migliore per il tuo sito.

Devi confrontare la presenza del provider con le aree in cui si trovano realmente i tuoi utenti.

Se il 95% del traffico arriva dall’Italia, il criterio sarà diverso rispetto a un SaaS utilizzato contemporaneamente in Europa, Stati Uniti e Asia.

Parti quindi dai dati di Analytics e Search Console, non dalla mappa marketing con il maggior numero di punti.

Regole di cache, contenuti dinamici e capacità di controllo

Per un sito prevalentemente statico possono essere sufficienti regole semplici.

Un ecommerce, una membership o un’applicazione richiedono controlli più granulari.

Valuta:

• regole per URL e path;
• gestione cookie;
• query string;
• purge;
• TTL;
• caching HTML;
• API;
• immagini;
• log;
• analytics della cache;
• possibilità di bypass.

Più è complessa l’applicazione, più conta la qualità degli strumenti di controllo rispetto alla semplice quantità di PoP.

Sicurezza, supporto e modello di costo

Molte piattaforme hanno trasformato la CDN in un componente di un’offerta edge più ampia.

Puoi quindi trovare nella stessa infrastruttura:

• protezione DDoS;
• WAF;
• DNS;
• gestione bot;
• image optimization;
• edge computing;
• streaming;
• storage.

Sono funzioni utili, ma rendono anche il confronto meno immediato.

Chiediti quali utilizzerai davvero.

Controlla inoltre il modello di costo: traffico, richieste, regioni, funzionalità premium, egress dall’origin e supporto possono incidere in modo diverso sul conto finale.

Se il tuo scenario è WordPress e vuoi confrontare servizi specifici, abbiamo separato questo intento nella guida alle Content Delivery Network per WordPress.

CDN gestita o edge platform più configurabile?

Per molti siti il valore principale sta nella semplicità.

Se hosting e provider gestiscono automaticamente cache, purge e integrazione, puoi ottenere un buon risultato senza costruire un’infrastruttura complessa.

Progetti più avanzati possono invece richiedere:

• configurazioni personalizzate;
• log dettagliati;
• funzioni eseguite all’edge;
• integrazioni API;
• regole di routing;
• controllo granulare della cache.

La soluzione più potente è utile soltanto se hai un problema che richiede quella potenza e le competenze per gestirla.

Per questo la scelta dovrebbe arrivare dopo la diagnosi, non prima.

Conclusione

Una CDN è utile quando riesce a spostare lavoro e contenuti dall’origin verso una rete distribuita nel punto in cui questo produce un vantaggio reale.

Per un sito internazionale, un ecommerce, un portale ricco di media o un progetto sottoposto a picchi di traffico, il beneficio può essere importante. Per un sito locale già veloce, con pubblico vicino al data center e poche risorse, il guadagno potrebbe essere molto più piccolo.

La cosa da ricordare è che una Content Delivery Network non sostituisce un buon hosting, non corregge un backend lento e non migliora automaticamente tutti i Core Web Vitals. È un livello dell’architettura e funziona bene quando viene configurato in relazione agli altri.

Prima di scegliere un provider, misura quindi origine del traffico, TTFB, risorse cacheabili, HIT/MISS e carico sull’origin. Dopo l’attivazione, misura di nuovo nelle stesse condizioni.

È questo confronto a dirti se la CDN sta davvero facendo il suo lavoro.

Se invece il problema è più ampio e non è chiaro se il collo di bottiglia sia hosting, frontend, cache, database o infrastruttura, un’analisi di ottimizzazione del sito permette di intervenire sulla causa invece di aggiungere strumenti alla cieca.