Un sito non 'sta' in un unico posto. DNS, server di origine e CDN fanno mestieri diversi. Confonderli costa tempo e soldi.
Un sito non sta in un unico posto. Il nome che l'utente digita, il server che genera la pagina e i nodi che ne tengono una copia vicino al browser sono tre mestieri distinti. Se li tratti come sinonimi finisci a comprare la leva sbagliata: una CDN per un nameserver mal configurato, un piano hosting per un JavaScript che blocca il rendering, un cambio di provider per un record che punta ancora al vecchio IP.
In breve: il DNS traduce un nome in un indirizzo. L'origine è la fonte di verità, il posto in cui vive l'applicazione e i dati. La CDN è una cache in bordo rete, non un sostituto del server. Si interviene sullo strato che sta fallendo. Gli altri due, lasciati stare, non "compensano".
Cosa trovi in questo articolo
Tre strati, tre problemi
La mappa minima è questa. Un browser chiede un nome. Un risolutore DNS gli restituisce un indirizzo (o una catena di CNAME che alla fine diventa un indirizzo). Il browser apre una connessione verso quell'indirizzo. Se in mezzo c'è una CDN, l'indirizzo è spesso un nodo di bordo: se la risorsa è in cache e le regole lo permettono, la risposta parte da lì. Se non lo è, il nodo va a prenderla dall'origine e, se configurato così, la tiene.
Tre punti di rottura, tre diagnosi. Il nome non risolve, o risolve verso il posto sbagliato: è DNS. L'HTML arriva tardi, l'applicazione va in 502, il database non risponde: è origine. Gli statici sono lenti da certe geografie, l'origine è saturata di GET ripetute su CSS e immagini: lì una CDN ha qualcosa da dire. Il resto del discorso, "rinnovo il piano e vediamo", è rumore.
Questa suddivisione non è marketing di vendor. È il modello su cui è costruito il web da decenni: nomi e indirizzi da una parte, macchina che genera contenuto dall'altra, eventuale replica in cache come acceleratore. Chi vuole il quadro delle metriche che arrivano dopo, LCP e compagnia, lo trova nel pillar sulla performance del sito web. Qui si parla di dove vive il sito, non di quanto è usabile una volta arrivato.
DNS: chi risolve e chi è autorevole
Il Domain Name System associa nomi a dati, in genere indirizzi. Lo dicono senza poesia la RFC 1034 e la RFC 1035. Due ruoli da non confondere, perché si rompono in modo diverso.
Il nameserver autorevole è quello che "sa" per una zona: tiene i record A, AAAA, CNAME, MX, TXT, e risponde per quel dominio. Se sbagli un A, se scade una zona firmata, se il registrar punta ancora ai nameserver vecchi, il resto della catena può essere perfetto e il sito è comunque irraggiungibile, o raggiungibile nel posto sbagliato.
Il risolutore ricorsivo è quello che usa il client, di solito quello dell'ISP o un resolver pubblico. Parte dal root, scende ai TLD, arriva all'autorevole, tiene il risultato per il TTL. Non è "il tuo DNS" in senso di proprietà della zona. È la cache in cui vive la risposta dopo che l'hai pubblicata. Per questo una modifica non è istantanea: finché i resolver hanno in cache il record vecchio, una fetta di internet continua a parlare con l'IP di ieri. Il TTL lo decidi tu sulla zona. Non esiste un "tempo di propagazione universale" da scrivere su un ticket.
MDN tiene un glossario asciutto sul DNS. Vale la pena leggerlo prima di dare la colpa all'hosting per un CNAME rimasto appeso. Un controllo minimo, in caso di fermo: cosa risponde l'autorevole, cosa risponde un resolver pubblico, cosa ha in cache il tuo computer. Tre risposte diverse dicono già quale strato sta mentendo.
Origine: dove sta davvero il sito
L'origine è il server, o il gruppo di server, che genera o detiene la versione canonica di ciò che servi. Applicazione, database, file caricati dagli utenti, chiavi, log. La CDN può tenerne una copia. Non la sostituisce. Se l'origine è spenta, la cache di bordo tiene in vita solo ciò che aveva già, per il tempo che gli hai concesso, e solo per le risorse che avevi deciso di cachare. L'HTML dinamico, il carrello, l'area riservata: tornano all'origine, o falliscono.
Scegliere l'origine è una decisione di infrastruttura, non di listino. Giurisdizione dei dati, distanza dai tuoi utenti, chi ha accesso root, chi fa le patch, che rete hai davanti. Un'origine in UE non è "più veloce" in astratto. È più vicina a un pubblico europeo, e sta sotto un regime legale che magari ti serve. Un'origine lontana con una CDN ben fatta può servire gli statici in fretta e lasciare comunque lento il primo byte dell'HTML, se l'applicazione è pesante.
Quando valuti dove mettere l'origine, metti in tabella almeno: regione, isolamento (condiviso, VPS, dedicato), chi amministra, come esci il giorno in cui vuoi andartene. Tra le opzioni per un'origine in Italia o in Europa ci sono anche i servizi hosting di Servereasy. Non è l'unica strada, e non è un verdetto. È una riga della tabella, da pesare con SLA, rete e modello di gestione. Il confronto VPS contro dedicato sta in un pezzo a parte, VPS o server dedicato. Qui basta una regola: l'origine è un vincolo. Non un accessorio della CDN.
CDN: copia in bordo, non verità
Una Content Delivery Network è una rete di cache. Il browser parla con un nodo vicino, il nodo risponde se ha una copia valida, altrimenti va all'origine. MDN la definisce senza giri: una CDN distribuisce copie, non diventa il sistema di record.
Serve, e serve sul serio, quando il payload ripetibile è grande e il pubblico è sparso: immagini, CSS, JS, font, download. Serve meno, a volte per niente, quando il collo di bottiglia è il tempo di generazione dell'HTML, una query, un plugin che fa lavoro a ogni request. In quel caso stai distribuendo più in fretta un ritardo che nasce a monte. La cache HTTP, intestazioni, invalidazione, cosa si può tenere e cosa no, è un discorso proprio: lo trattiamo in cache HTTP.
Due dettagli che si dimenticano. Primo: una CDN mal configurata può cachare ciò che non doveva, pagine private, HTML con prezzi vecchi, risposte 301 sbagliate. Secondo: il "purge" non è magia istantanea su tutti i nodi in ogni istante, e comunque non ripara un'origine lenta. Se usi la CDN come toppa su un'applicazione che non regge, stai comprando tempo. Non architettura.
TTFB non è LCP
Il Time to First Byte misura quanto passa, dall'inizio della richiesta, al primo byte di risposta HTTP. È una metrica di rete e di origine. Il Largest Contentful Paint misura quando l'elemento più grande del viewport è dipinto. Sono cose diverse. web.dev le tiene distinte nei Web Vitals, e MDN descrive il protocollo sotto HTTP.
Un TTFB alto dice: la risoluzione DNS, il TLS, la coda, l'applicazione o il database stanno mangiando tempo prima ancora che il browser abbia qualcosa da dipingere. Un TTFB accettabile e un LCP alto dicono altro: il primo byte arriva, poi CSS, immagini, font o JavaScript tengono in ostaggio il contenuto principale. Mettere una CDN in mezzo aiuta il primo caso solo se il collo era distanza o ripetizione di statici. Non aiuta il secondo se l'hero pesa megabyte e arriva senza priorità.
La tentazione, in una riunione, è trattare "il sito è lento" come un unico ticket da assegnare all'hosting. Non lo è. Si misura, si vede quale strato parla, si interviene lì. Il cluster Infrastruttura serve a questo: nominare i pezzi. Non a vendere un upgrade.
Ha senso quando. Non serve quando
Ha senso fare questa mappa prima di ogni cambio di piano, prima di una migrazione, prima di accendere una CDN "perché la accendono tutti". In quei momenti stai decidendo vincoli: chi risolve il nome, dove stanno i dati, cosa può essere copiato in bordo. Se non li hai scritti, stai firmando alla cieca.
Non serve accendere tutti e tre i rubinetti per un sito locale, con poco traffico, HTML leggero e un'origine già vicina al pubblico. Un DNS pulito e un'origine decente bastano. La CDN diventa un pezzo da operare: cache key, bypass, purge, TLS, log. Costo di gestione, non solo costo di listino. Se non hai qualcuno che la capisce, può peggiorare un incidente invece di accorciarlo.
Ha senso una CDN quando servi asset ripetibili a un pubblico geografico ampio, o quando l'origine non deve vedere ogni GET su un JPEG. Ha senso cambiare origine quando l'applicazione è saturata, quando ti serve isolamento, quando la giurisdizione non torna. Ha senso toccare il DNS quando il nome non punta dove credi, quando i TTL ti tengono ostaggio di un cutover, quando i nameserver non sono dove pensi. Tre frasi diverse. Tre owner diversi, se il team è grande abbastanza da averli.
Errori da evitare
Dare la colpa all'hosting per un record sbagliato. Se l'A punta altrove, il server nuovo può essere impeccabile e restare invisibile.
Trattare la CDN come origine. I dati canonici, i backup, le chiavi, stanno a monte. La cache di bordo non è un disaster recovery.
Abbassare il TTL il giorno del cutover. Si abbassa prima, si aspetta che scada la cache vecchia, poi si sposta. Altrimenti una fetta di resolver continua a mentire per ore.
Comprare una CDN per sistemare l'LCP senza aver visto l'elemento LCP. Se il problema è un'immagine da due megabyte o un CSS che blocca, la rete non la rimpicciolisce.
Cachare HTML personalizzato "perché va più veloce". Va più veloce la pagina sbagliata. Prezzi, sessioni, header di autenticazione: o li escludi, o li disegni nella cache key. Terza via non c'è.
Misurare solo dal tuo ufficio. Il resolver del tuo ISP, la distanza dall'origine, la cache calda del tuo browser non sono internet.
In sintesi
DNS, origine e CDN non sono tre nomi per "l'hosting". Sono tre strati. Il primo risolve il nome, il secondo detiene la verità, il terzo eventualmente ne tiene una copia vicina all'utente. Si diagnostica quale sta fallendo, si interviene lì, e si lascia stare il resto. TTFB racconta l'andata verso il primo byte. LCP racconta quando l'utente vede il contenuto che conta. Confonderli produce spese inutili e ticket che non chiudono.
La formula è secca: mappa, misura, poi acquisto. Non il contrario.
Fonti
IETF, RFC 1034 (concetti e ruoli del DNS).
IETF, RFC 1035 (implementazione e tipi di record).
MDN, DNS.
MDN, CDN.
MDN, HTTP.
web.dev, Web Vitals.
web.dev, Largest Contentful Paint (LCP).
web.dev, Time to First Byte (TTFB).
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
