Quando un sito è lento, la prima reazione di molti è quasi un riflesso: “mettiamo Cloudflare”. Si cambiano i nameserver, si attiva il proxy, e ci si aspetta che le pagine diventino istantanee. A volte qualcosa migliora, spesso molto meno del previsto, e il TTFB delle pagine resta esattamente quello di prima. Il motivo, nella maggior parte dei casi, è una confusione di fondo tra due funzioni diverse: la CDN, che distribuisce i file statici, e la Full Page Cache, che conserva le pagine HTML già pronte.
Cloudflare è uno strumento eccellente e lo usiamo spesso. Ma non è una panacea, e per farlo lavorare davvero sulle performance bisogna sapere che cosa fa di base, che cosa non fa e che cosa serve configurare. Vediamolo con ordine.
Che cos’è davvero Cloudflare
Cloudflare è una rete globale che si interpone tra i visitatori e il server del sito, l’origine. Quando il proxy è attivo, ogni richiesta arriva prima a uno dei suoi nodi, distribuiti in centinaia di città, e solo se necessario prosegue verso l’origine. Su questa posizione privilegiata Cloudflare costruisce molti servizi: DNS, certificati TLS, protezione dagli attacchi DDoS, firewall applicativo, gestione dei bot, supporto a HTTP/3 e, naturalmente, una CDN per i contenuti statici.
Molti di questi servizi funzionano bene fin dal primo giorno e da soli giustificano l’adozione di Cloudflare, soprattutto sul fronte della sicurezza. Il problema nasce quando si dà per scontato che, essendo “una CDN”, Cloudflare velocizzi automaticamente tutto il sito, pagine comprese.
CDN e Full Page Cache: la confusione più diffusa
Una CDN conserva copie dei file statici, come fogli di stile, script, immagini e font, nei nodi vicini agli utenti. Sono file uguali per tutti e cambiano raramente: servirli da un nodo a pochi chilometri invece che dal server d’origine riduce la latenza e alleggerisce l’infrastruttura.
La Full Page Cache conserva invece il documento HTML della pagina, cioè il risultato del lavoro di PHP e del database. È ciò che determina il TTFB, il tempo che il browser attende prima di poter iniziare a costruire la pagina, ed è quindi la base di LCP. Senza una cache dell’HTML ogni visita costringe l’origine a generare di nuovo la pagina, anche se tutte le immagini arrivano velocissime dalla CDN.
Le due funzioni possono stare nello stesso posto, sul nodo di Cloudflare, oppure in posti diversi, con la CDN in periferia e la Full Page Cache sull’origine, per esempio con Varnish. Ma restano due cose diverse, e attivarne una non significa avere anche l’altra.
Di base, l’HTML non viene messo in cache
Con la configurazione predefinita, Cloudflare mette in cache i file in base alla loro estensione: immagini, fogli di stile, JavaScript, font, documenti come PDF e pochi altri formati. Le pagine HTML non fanno parte dell’elenco. Ogni richiesta di una pagina attraversa quindi il nodo senza fermarsi e raggiunge l’origine, esattamente come se Cloudflare non ci fosse, con in più il passaggio intermedio.
È una scelta prudente e corretta: l’HTML può contenere informazioni personali, come il nome di un utente collegato o il contenuto di un carrello, e metterlo in cache senza criterio sarebbe pericoloso. Ma significa che, se il problema del sito è un’origine lenta, attivare Cloudflare non lo risolve.
Come verificarlo in un minuto
Cloudflare aggiunge a ogni risposta l’intestazione cf-cache-status, che indica se la risorsa è stata servita dalla cache. Basta una richiesta da riga di comando:
curl -sI https://www.iltuosito.it/ | grep -i cf-cache-status
cf-cache-status: DYNAMIC
curl -sI https://www.iltuosito.it/wp-content/themes/tema/style.css | grep -i cf-cache-status
cf-cache-status: HIT| Valore | Significato |
|---|---|
| HIT | Servita dalla cache del nodo |
| MISS | Idonea alla cache, ma non ancora presente: richiesta all’origine |
| DYNAMIC | Non idonea alla cache: è il caso dell’HTML con le impostazioni predefinite |
| BYPASS | Cache esclusa da una regola o dalle intestazioni dell’origine |
| EXPIRED, REVALIDATED | Copia scaduta, scaricata di nuovo o riconvalidata con l’origine |
Se le pagine rispondono con DYNAMIC, Cloudflare sta facendo da CDN e da scudo, ma non da cache delle pagine.
Perché mettere in cache l’HTML non è banale
Una cache dell’HTML ben fatta richiede sempre tre elementi. Il primo è una regola che stabilisca che cosa mettere in cache. Il secondo è un insieme di esclusioni per ciò che non deve mai finire in cache: area di amministrazione, login, carrello, checkout, area clienti, e in generale le visite di utenti riconosciuti tramite cookie. Il terzo, il più delicato, è un meccanismo di invalidazione: quando si aggiorna un articolo o cambia un prezzo, la copia in cache deve essere eliminata, altrimenti i visitatori vedranno contenuti superati.
Un errore nel secondo punto è grave: la pagina vista da un amministratore, con la barra di modifica, o da un cliente con il suo carrello, potrebbe essere servita al visitatore successivo. Un errore nel terzo punto è più subdolo: prezzi, disponibilità o notizie non aggiornati per ore.
Le regole di cache
Per mettere in cache l’HTML si usano le regole di cache di Cloudflare, che hanno sostituito le vecchie Page Rules e la loro impostazione “Cache Everything”. Una regola può rendere l’HTML idoneo alla cache, stabilire per quanto tempo conservarlo sui nodi e definire le condizioni di esclusione, per percorso o per cookie. Alcune funzioni avanzate, come l’esclusione in base ai cookie, sono state a lungo riservate ai piani superiori: prima di progettare la configurazione conviene verificare che cosa include il proprio piano.
C’è un dettaglio importante per chi arriva dalle Page Rules: lì si applicava solo la prima regola corrispondente, mentre le regole di cache vengono valutate tutte, in ordine, e quelle successive possono sovrascrivere le precedenti. Le esclusioni vanno quindi in fondo. Una configurazione minima per WordPress e WooCommerce ha questa forma:
# Regola 1: rendi idoneo alla cache l’HTML del sito
(http.host eq "www.iltuosito.it")
→ Idoneo alla cache · TTL sui nodi: 2 ore
# Regola 2 (dopo la prima): escludi aree dinamiche e utenti riconosciuti
(starts_with(http.request.uri.path, "/wp-admin")
or http.request.uri.path eq "/wp-login.php"
or starts_with(http.request.uri.path, "/carrello")
or starts_with(http.request.uri.path, "/checkout")
or starts_with(http.request.uri.path, "/mio-account")
or http.cookie contains "wordpress_logged_in"
or http.cookie contains "woocommerce_items_in_cart")
→ Bypass della cacheÈ un punto di partenza, non una configurazione universale. Ogni sito ha i propri percorsi dinamici, le proprie API, i plugin che impostano cookie e le pagine che cambiano spesso: vanno individuati uno per uno e verificati con l’intestazione cf-cache-status.
APO: la cache dell’HTML pensata per WordPress
Per i siti WordPress Cloudflare offre una soluzione già pronta: APO, Automatic Platform Optimization. È un componente aggiuntivo a pagamento sul piano gratuito e incluso nei piani superiori, che si attiva tramite il plugin ufficiale di Cloudflare per WordPress. APO mette in cache le pagine HTML sulla rete di Cloudflare, esclude automaticamente le visite con i cookie tipici di WordPress e WooCommerce, come quelli degli utenti collegati o del carrello, e soprattutto gestisce l’invalidazione: quando si pubblica o si modifica un contenuto, il plugin comunica a Cloudflare quali pagine eliminare.
Per un blog o un sito editoriale su WordPress, APO è spesso il modo più semplice per ottenere una vera cache dell’HTML sui nodi, con un TTFB basso per i visitatori di tutto il mondo. Ma non è magia nemmeno lui: funziona solo con WordPress, dipende dal plugin per l’invalidazione, e va verificato con attenzione quando il sito mostra contenuti diversi per lingua, valuta, area geografica o dispositivo, o quando altri plugin di cache lavorano in parallelo.
Le insidie che nessuno racconta
- I nonce di WordPress. Molti moduli e richieste AJAX includono nell’HTML un codice di sicurezza con validità limitata, di norma alcune ore. Se una pagina resta in cache più a lungo, quel codice scade e moduli di contatto, ricerche o pulsanti smettono di funzionare per chi riceve la copia vecchia. Il TTL dell’HTML va scelto anche in base a questo.
- Siti con poco traffico. Ogni nodo ha la propria cache. Se un sito riceve poche visite, molte pagine non sono in cache nel nodo da cui arriva l’utente e la richiesta prosegue comunque verso l’origine, con un passaggio in più. La cache a livelli di Cloudflare riduce il problema, ma non lo elimina.
- Lo svuotamento totale. Il pulsante che elimina tutta la cache è comodo, ma costringe ogni nodo a ricostruirla da zero, con un picco di richieste verso l’origine proprio nel momento sbagliato. Meglio eliminare solo gli URL interessati, a mano o tramite plugin.
- Il debug. Con più nodi e più livelli di cache, due utenti possono vedere versioni diverse della stessa pagina. Senza un metodo e senza leggere le intestazioni di risposta, individuare la causa di un problema diventa lungo e costoso.
Cloudflare e cache all’origine: livelli che si completano
La domanda giusta non è “Cloudflare o Varnish?”, ma quale compito affidare a ciascun livello. La cache del browser evita di scaricare di nuovo ciò che l’utente ha già. La CDN serve i file statici da vicino e, se configurata, anche l’HTML. La Full Page Cache all’origine, con Varnish come riferimento per i progetti più esigenti, rende veloce ogni richiesta che il nodo non riesce a servire da solo. L’object cache e un’applicazione ben ottimizzata rendono rapido anche ciò che non può essere messo in cache, come il carrello o l’area clienti.
In questa architettura Cloudflare è prezioso, ma è uno dei livelli. Un’origine lenta resta lenta per tutte le richieste che la cache periferica non intercetta: utenti collegati, carrelli, pagine appena aggiornate, nodi con la cache ancora vuota. Ed è proprio lì che si decidono le conversioni di un e-commerce.
Le altre funzioni “miracolose”
Cloudflare offre anche ottimizzazioni che promettono miglioramenti con un clic, come la compressione delle immagini o Rocket Loader, che rinvia il caricamento del JavaScript. Possono essere utili, ma vanno trattate come qualsiasi altra ottimizzazione automatica: attivate una alla volta e misurate. Rinviare il JavaScript, in particolare, può migliorare i test di laboratorio e peggiorare la reattività reale, per le stesse ragioni che abbiamo descritto parlando del delay del JavaScript al primo clic.
Come capire che cosa serve al tuo sito
- Misura il TTFB delle pagine principali e controlla
cf-cache-status: se l’HTML èDYNAMICe il TTFB è alto, il problema è l’origine o l’assenza di cache delle pagine. - Valuta quanto del traffico è anonimo: più è alto, più una cache dell’HTML, sui nodi o all’origine, avrà effetto.
- Elenca le parti dinamiche del sito, i cookie che le identificano e la frequenza con cui cambiano i contenuti: sono gli ingredienti delle esclusioni e dei tempi di scadenza.
- Scegli dove mettere la cache dell’HTML: regole di Cloudflare, APO per WordPress, Varnish all’origine o una combinazione, in base al pubblico, al traffico e al budget.
- Verifica il risultato sui dati degli utenti reali, non solo con un test: il TTFB e l’LCP al 75° percentile sono il giudice finale.
In sintesi
Cloudflare non è la panacea di tutti i mali, ma è un ottimo strumento quando si sa che cosa gli si sta chiedendo. Di base è una CDN e uno scudo: serve da vicino i file statici e protegge il sito, ma lascia passare l’HTML verso l’origine. Per accelerare le pagine serve una cache dell’HTML, che può essere configurata sui nodi con le regole di cache o con APO per WordPress, oppure all’origine con una Full Page Cache come Varnish, idealmente in combinazione.
Confondere la CDN con la Full Page Cache porta a credere di aver risolto un problema che è ancora lì. Distinguerle permette invece di costruire un’architettura in cui ogni livello fa la sua parte, e in cui anche le richieste che nessuna cache può servire, come quelle degli utenti che stanno per acquistare, restano veloci.
