CDN e WordPress: Cloudflare vs CDN del hosting, quale scegliere e perché configurarla male è peggio di non averla

Se il tuo sito WordPress serve visitatori da una sola area geografica — diciamo tutta Italia — e il tuo hosting è in un data center a Milano, la CDN è un'ottimizzazione marginale. I contenuti statici partono già da vicino agli utenti. Ma se il tuo traffico viene anche da fuori — clienti all'estero, turisti che prenotano, portali che vengono linkati da pubblicazioni internazionali — ogni richiesta da New York o Tokyo attraversa mezzo mondo per arrivare al tuo server, e il TTFB ne risente. Lì la CDN non è un'ottimizzazione: è una necessità.

Il problema è che quasi tutti parlano di "la CDN" come fosse una cosa sola. Non lo è. Ci sono due approcci molto diversi: la CDN integrata nel tuo hosting gestito, e una CDN indipendente come Cloudflare. Non fanno esattamente la stessa cosa, non si configurano nello stesso modo, e non hanno gli stessi limiti. Scegliere quella sbagliata — o configurarla male — può degradare le prestazioni invece di migliorarle.

CDN del hosting gestito: il comfort della semplicità

La maggior parte degli hosting WordPress gestiti di qualità offre una CDN integrata. Il funzionamento è semplice: i tuoi asset statici (CSS, JavaScript, immagini, font) vengono copiati su server edge distribuiti geograficamente, e i visitatori li scaricano dal server più vicino invece che dall'origine. Non devi configurare nulla — l'hosting gestisce i DNS, la cache, l'invalidazione. Quando aggiorni un contenuto, l'hosting svuota la cache automaticamente.

Il vantaggio è la semplicità: zero configurazione, zero DNS da gestire, zero rischi di servire contenuti stale. Lo svantaggio è il controllo: non puoi personalizzare le regole di cache, non puoi attivare funzioni avanzate come il WAF edge, e la copertura geografica dipende dai data center del tuo provider. Per la maggior parte dei siti italiani con traffico prevalent europeo, la CDN del hosting gestito è sufficiente.

Cloudflare自主: il controllo totale, la complessità totale

Cloudflare è un caso diverso. Non è solo una CDN — è un reverse proxy che si mette davanti al tuo sito. I DNS del tuo dominio puntano a Cloudflare, che poi inoltra le richieste al tuo server originario. Questo significa che Cloudflare può cachare non solo gli asset statici, ma anche le pagine HTML intere (page cache a livello edge), filtrare il traffico malevolo con il WAF, e applicare regole di cache personalizzate per URL, parametro o header.

Il vantaggio è il controllo: puoi cachare tutto, ottimizzare tutto, proteggere tutto da un unico pannello. Lo svantaggio è la complessità — e qui è dove vediamo i disastri. Una regola di cache Cloudflare mal configurata può servire una versione HTML vecchia del checkout a metà dei visitatori. Un WAF con regole troppo aggressive può bloccare i webhook di pagamento. Un redirect mal fatto può creare un loop infinito. Cloudflare è potente, ma la potenza senza competenza è un rischio.

La regola d'oro: non cachare le pagine dinamiche all'edge

L'errore più costoso che vediamo con Cloudflare è la page cache aggressiva su tutto il dominio. Cloudflare permette di cachare l'HTML delle pagine, non solo gli asset statici — e questo può dare un TTFB quasi zero. Ma se cachate anche le pagine dinamiche (carrello, checkout, account, pagine con contenuti personalizzati), servite a un utente il carrello di un altro. La regola operativa è semplice: cachare all'edge solo le pagine che sono identiche per tutti i visitatori.

La configurazione corretta su Cloudflare passa per le Page Rules o i Cache Rules:

# Cloudflare Cache Rules — escludi le pagine dinamiche

# Regola 1: NON cachare le pagine dinamiche di WooCommerce
URL pattern: *example.com/checkout*
URL pattern: *example.com/carrello*
URL pattern: *example.com/il-mio-account*
Cache eligibility: Bypass cache

# Regola 2: NON cachare le richieste con cookie di sessione
URL pattern: *example.com/*
If: Cookie contains "wordpress_logged_in" or "woocommerce_*"
Cache eligibility: Bypass cache

# Regola 3: Cacha tutto il resto (pagine statiche, blog, landing)
URL pattern: *example.com/*
Cache eligibility: Eligible for cache
Edge TTL: 4 ore
Browser TTL: 4 ore

Quando servono entrambe

Ci sono casi in cui la CDN del hosting e Cloudflare non si escludono — si completano. Il caso tipico è un WooCommerce con traffico internazionale: la CDN del hosting gestisce gli asset statici (semplice, automatica, zero configurazione), e Cloudflare gestisce il WAF edge, la page cache delle pagine statiche e la protezione bot. In questo scenario, Cloudflare non cachare gli asset (li lascia alla CDN del hosting) ma cachare le pagine HTML statiche e filtra il traffico malevolo.

La configurazione richiede attenzione ai DNS: se usi Cloudflare come proxy, i DNS del dominio puntano a Cloudflare, che poi inoltra al tuo hosting. Questo significa che il tuo hosting vede le richieste arrivare dagli IP di Cloudflare, non dai reali IP dei visitatori — e alcuni plugin di sicurezza o di analytics possono confondersi. La soluzione è far passare gli header X-Forwarded-For correttamente, cosa che un hosting WordPress gestito di qualità fa di default.

I segnali che la CDN è configurata male

Tre sintomi ricorrenti. Primo: dopo un aggiornamento, il sito mostra contenuti vecchi per ore — la CDN non si invalida. Secondo: il carrello mostra prodotti sbagliati o di altri utenti — la page cache edge sta servendo HTML dinamico. Terzo: il TTFB è bassissimo ma le conversioni calano — gli utenti vedono una versione cachata del checkout con prezzi o disponibilità sbagliate.

Il test più semplice: apri il tuo sito in modalità incognito (per evitare i cookie di sessione), fai un aggiornamento in admin, e ricarica. Se vedi ancora la versione vecchia, la CDN sta servendo stale. Su un sito gestito bene, l'invalidazione è automatica al salvataggio; su Cloudflare自主, devi configurarla o svuotare manualmente.

# Svuota la cache Cloudflare via API (richiede API token)
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything":true}'

# Oppure svuota solo URL specifici (consigliato in produzione):
# --data '{"files":["https://example.com/pagina-aggiornata"]}'

Una CDN ben configurata abbassa il TTFB per gli utenti lontani, riduce il carico sul server originario, e aggiunge un livello di sicurezza. Una CDN mal configurata serve contenuti sbagliati, rompe il checkout, e crea problemi che emergono ore o giorni dopo. La differenza non è lo strumento — è la competenza con cui lo configuri.