Cos’è un CDN e il tuo sito ne ha bisogno?

Un CDN (content delivery network) è una rete di server distribuiti in molte località che conserva copie dei file del tuo sito e li consegna ai visitatori da un server vicino a loro, invece di inoltrare ogni richiesta al tuo hosting. La maggior parte dei siti pubblici con visitatori in più regioni, o con picchi di traffico, ne trae vantaggio. Da solo, però, un CDN non sistema codice lento o pagine pesanti, quindi conviene capire bene cosa fa prima di attivarne uno.

Come funziona un CDN

Senza CDN ogni visitatore parla direttamente con il tuo server di origine, la macchina presso il tuo provider di hosting su cui vive il sito. Se quel server si trova a Francoforte e il visitatore a Sydney, ogni richiesta fa il giro del mondo andata e ritorno. Se arrivano mille persone nello stesso momento, l'origine deve rispondere a tutte.

Con un CDN, invece, i visitatori vengono indirizzati a un server edge. L'edge si trova tra il visitatore e la tua origine e lavora più o meno così:

1. Un visitatore richiede una pagina o un file.
2. Il DNS lo manda a un server edge vicino.
3. Se l'edge ha già una copia aggiornata, risponde subito. È un cache hit.
4. Se non ce l'ha, l'edge recupera il file dalla tua origine, lo consegna e ne tiene una copia per il visitatore successivo. È un cache miss.

La prima richiesta di un file non è più veloce di prima. Tutte le richieste successive dello stesso file, da parte di chiunque si trovi vicino a quell'edge, possono essere servite senza toccare minimamente la tua origine. È da qui che arrivano sia la velocità sia il sollievo per il tuo server.

Cosa mette in cache un CDN (e cosa no)

Un CDN decide cosa conservare in base agli header di risposta della tua origine, soprattutto Cache-Control, più le eventuali regole che configuri tu. Il riferimento MDN su Cache-Control (in inglese) è il posto migliore per consultare direttive come max-age, s-maxage, private e no-store.

Si può mettere in cache

• Immagini, CSS, JavaScript e web font
• Pagine HTML pubbliche uguali per tutti i visitatori: articoli del blog, landing page, pagine di categoria e di prodotto nella maggior parte dei negozi online
• File da scaricare, come i PDF

Deve saltare la cache

• Carrello, checkout e pagine di pagamento
• Aree account e tutto ciò che vedono gli utenti loggati
• Pagine che contengono dati personali, token dei moduli o prezzi per singolo cliente
• Aree di amministrazione come /wp-admin

Fare bene questa distinzione conta più di qualsiasi altra impostazione del CDN. Un CDN che mette in cache una pagina da utente loggato può mostrare i dati di un cliente a un altro. I CMS e i sistemi e-commerce ben fatti segnano queste risposte come private o impostano cookie che il CDN interpreta come segnale per saltare la cache. Se gestisci un negozio online, la guida su come velocizzare WooCommerce spiega quali pagine vanno in quale gruppo.

Cosa migliora un CDN

Time to First Byte

Quando una pagina arriva dalla cache dell'edge, il visitatore riceve il primo byte senza aspettare PHP, una query al database o un hosting lento. Lo vedi nel TTFB, per cui web.dev consiglia come riferimento indicativo 0,8 secondi o meno. La nostra guida su come ridurre il TTFB tratta gli interventi lato server che completano un CDN.

Distanza e latenza

Ogni scambio tra browser e server costa tempo, e la distanza fisica lo allunga. Servire le risposte da un edge vicino accorcia ogni scambio, e il risparmio si somma tra lookup DNS, handshake TLS e le tante richieste che una pagina fa.

Carico sull'origine

I cache hit non arrivano mai al tuo server. Durante l'invio di una newsletter, una promozione o una menzione sui social, il tuo hosting deve rispondere solo ai cache miss e alle richieste dinamiche, quindi è molto meno probabile che rallenti nei momenti di picco.

Sicurezza e disponibilità

Dato che tutto il traffico passa dall'edge, molti CDN filtrano lì anche gli attacchi, gestiscono il TLS e continuano a servire le pagine in cache mentre l'origine è brevemente irraggiungibile. Quanto di tutto questo ottieni dipende dal fornitore e dal piano.

Cosa un CDN non può risolvere

Un CDN è un livello di distribuzione. Fa arrivare più in fretta le pagine buone, ma non può rendere leggera una pagina pesante.

• Pagine dinamiche lente. Checkout, ricerca e pagine per utenti loggati vengono generate da zero ogni volta. Se sono lente, la causa è l'applicazione, il database o l'hosting.
• Front-end pesanti. Un'immagine hero da 4 MB o una pila di script di terze parti restano 4 MB e devono comunque essere eseguiti nel browser. Questo si vede in LCP e INP, non nel TTFB.
• Spostamenti del layout. Il CLS dipende da come è costruita la pagina, per esempio immagini senza dimensioni o banner che si caricano in ritardo.
• Una cache configurata male. Se la tua origine invia no-store su tutto, o se ogni pagina imposta un cookie di sessione, il CDN salterà la cache e guadagnerai poco.

Se il tuo problema è uno di questi, la soluzione va cercata nella pagina o nell'applicazione. Un CDN resta utile in parallelo, ma non ne prende il posto. La guida sui Core Web Vitals spiega quale metrica indica quale causa.

Il tuo sito ha bisogno di un CDN?

Di solito un CDN conviene se vale almeno uno di questi punti:

• I tuoi visitatori arrivano da più di un paese o continente.
• Il TTFB delle pagine pubbliche è alto, soprattutto lontano dal tuo hosting.
• Il server fa fatica o rallenta durante i picchi di traffico.
• Usi un CMS o un negozio online in cui la maggior parte delle visite finisce su pagine uguali per tutti.
• Vuoi che protezione DDoS e HTTPS siano gestiti davanti al tuo hosting.

Conta meno se il sito è puramente locale, molto piccolo, già servito da un hosting statico veloce vicino al tuo pubblico, oppure quasi interamente personalizzato (per esempio uno strumento interno dietro login). In questi casi un hosting migliore o un'ottimizzazione dell'applicazione possono portare più di un CDN.

Come verificare che funzioni

Prima di attivare qualsiasi cosa, misura. Analizza alcune pagine pubbliche con corewebvitals.page e annota l'LCP e le altre metriche, più i dati degli utenti reali se Google ne ha abbastanza. La guida su come misurare la velocità di un sito spiega come impostare un confronto prima e dopo corretto.

Quando il CDN è attivo, controlla gli header di risposta di una pagina che ti aspetti in cache. Richiedila due volte:

curl -sI https://www.example.com/ | grep -i -E 'cache|age'

La prima richiesta spesso è un miss. La seconda dovrebbe mostrare un hit nell'header di cache del fornitore e un'età che aumenta. Se ogni richiesta resta un miss o un bypass, controlla Cache-Control e Set-Cookie nella risposta dell'origine. Poi ripeti le misurazioni da più località e confronta i risultati.

Come ti aiuta fast.site

fast.site si mette davanti al tuo hosting attuale, quindi mantieni il tuo provider e il tuo CMS. Aggiungi il dominio nella dashboard, sposti i tuoi nameserver su fast.site e verifichi. La propagazione viene controllata automaticamente e da quel momento fast.site gestisce il DNS del dominio.

La cache è affidata a Fast Edge Cache™. In caso di miss, l'edge recupera la pagina dalla tua origine e ne conserva una copia; in caso di hit, risponde senza contattare il tuo server. La scadenza segue gli header Cache-Control della tua origine o le tue regole, mentre carrello, checkout e sessioni degli utenti loggati saltano la cache. L'header di risposta fs-cache mostra HIT, MISS o BYPASS, così puoi controllare ogni pagina da solo. Puoi svuotare la cache per URL dalla dashboard o tramite API, e un cache warmer tiene pronte le pagine importanti.

GeoDNS indirizza i visitatori all'edge funzionante più vicino in Nord America, Europa, Asia-Pacifico o Sud America, a seconda del tuo piano. Ogni dominio ha inoltre il rilevamento automatico degli attacchi DDoS di livello 7 e certificati SSL gratuiti con rinnovo automatico. Trovi i dettagli nella documentazione sulla cache e nella pagina delle funzionalità.

Misura il tuo sito prima e dopo. Puoi iniziare con una prova gratuita di 7 giorni, senza carta di credito. Confronta i piani nella pagina dei prezzi.

Domande frequenti

Un CDN sostituisce l'hosting?

No. Il sito continua a vivere sul tuo hosting, che resta l'origine. Il CDN si mette davanti e serve copie in cache, ma tutto ciò che è dinamico, come il checkout, viene ancora generato dal tuo server.

Un CDN aiuta la SEO?

Indirettamente può aiutare. Google usa segnali di esperienza sulla pagina come i Core Web Vitals, e un CDN può migliorare i tempi di caricamento, soprattutto il TTFB e di conseguenza spesso l'LCP. Non garantisce posizionamenti migliori, perché contenuti e pertinenza contano molto di più.

Un CDN può rallentare il sito?

Sì, se è configurato male. Se il CDN salta quasi ogni richiesta, ognuna fa un passaggio in più dall'edge alla tua origine. Controlla gli header di cache dopo la configurazione e assicurati che le pagine pubbliche generino davvero degli hit.

Mi serve un CDN se i visitatori sono tutti in Italia?

Per la distanza non necessariamente, ma spesso sì per il carico e la protezione. Se il tuo hosting è vicino al pubblico e regge bene i picchi, il guadagno è minore. Se i picchi di traffico rallentano il server, la cache sull'edge aiuta comunque.

Un CDN può rompere il negozio online o le pagine di login?

No, se le pagine dinamiche saltano la cache. Carrello, checkout e account non devono mai essere messi in cache per tutti. Dopo la configurazione prova questi percorsi, da loggato e non, e verifica che l'header di cache mostri un bypass.