Cloudflare cache analytics: diagnosticare un'hit ratio basso
Il cache hit ratio è la metrica chiave per misurare l'efficacia della configurazione cache su Cloudflare. Rappresenta la percentuale di richieste servite direttamente dall'edge cache senza dover contattare il server origine. Un'hit ratio basso (sotto il 50%) indica che la maggior parte del traffico raggiunge l'origine, vanificando il vantaggio CDN. Vediamo come leggere le analytics e applicare le ottimizzazioni corrette.
Cache states e CF-Cache-Status
Cloudflare classifica ogni richiesta con un CF-Cache-Status nell'header response: HIT (servito da cache edge), MISS (non in cache, andato a origine), EXPIRED (era in cache ma TTL scaduto), BYPASS (skip esplicito), DYNAMIC (no cache per natura dinamica), REVALIDATED (304 verso origine), UPDATING (refresh asincrono). L'obiettivo è massimizzare HIT e minimizzare gli altri.
Procedura passo-passo
- Vai sul dashboard Cloudflare → Analytics & Logs → Performance → Cache.
- Verifica il Cache hit ratio attuale.
- Se sotto il 50%, identifica le top URL non cachate filtrando per Cache Status: MISS o DYNAMIC.
- Verifica cosa l'origine risponde per quegli URL con curl: header Cache-Control, Set-Cookie, Vary.
- Se Cache-Control è no-cache/private, l'origine vieta cache. Override con Page Rule "Cache Everything".
- Se Set-Cookie obbliga la cache a saltare, configura Cache Rule che ignora cookie non rilevanti.
- Se Vary include header dinamico (User-Agent), riduci il Vary o usa Custom Cache Keys.
- Attiva Tiered Cache da Caching → Tiered Cache.
- Applica Edge Cache TTL appropriato per ogni asset type.
- Monitora dopo 24h: il hit ratio dovrebbe salire al 70-90%.
Cause comuni di hit ratio basso
HTML non cachato by default: Cloudflare di default cachata solo asset statici. Per cachare HTML serve Page Rule "Cache Everything". Cookie su risposta: l'origine invia Set-Cookie e Cloudflare per default skip cache. Query string variabili: ogni URL con query string diversa è cache entry separata. Vary header aggressivo: l'origine invia Vary: User-Agent che frammenta la cache per ogni device. Origin cache-control: no-cache: WordPress di default invia questo header.
Tecniche per aumentare hit ratio
Le tecniche da applicare in ordine di priorità: 1) Page Rule "Cache Everything" per HTML pubblico, combinato con Bypass on Cookie per utenti loggati. 2) Configurazione Cache TTL esplicito (Edge 1 mese per asset, 2 ore per HTML). 3) Tiered Cache attivo (gratis). 4) Cache Reserve (paid) per assets long-tail. 5) Custom Cache Keys (Enterprise) per ignorare parametri tracking. 6) Polish + Auto Minify per ridurre peso. 7) APO per WordPress.
Errori comuni e come risolverli
- WordPress non cacha: invia Cache-Control: no-cache per visitor anonimo. Override con Page Rule.
- Query string analytics rompe cache: utm_* params trattati come URL diverso. Strip via Worker o Custom Cache Keys.
- Cookie session blocca cache: aggiungi Cache Rule che ignora i cookie non strictly necessary.
- Origine 5xx servita: errori non cachati ma riducono hit ratio. Configura Always Online o serve stale.
- Asset versionato confonde stats: hash nel filename causa cache key unici. Normale, è comportamento corretto.
Diagnosi via curl
Per debug specifico: curl -I https://tuosito.it/pagina. Osserva: cf-cache-status, cache-control, age (secondi in cache), set-cookie, vary. Ripeti subito: se prima MISS poi HIT, la cache funziona ma TTL forse troppo basso. Se sempre MISS, origin blocca caching. Se BYPASS, configurazione esplicita lo richiede. Se DYNAMIC, content tipo non default-cacheable.
Cache Reserve e Smart Tiered Cache
Su piano Business e Enterprise sono disponibili feature avanzate: Cache Reserve archivia asset in R2 fungendo da cache "ultima" che non scade mai. Perfect per long-tail di asset poco richiesti. Smart Tiered Cache: ottimizzazione ulteriore del routing tra tier per minimizzare carico origin. Custom Cache Keys: stripping di query parameters, normalizzazione URL, inclusione di header custom. Insieme portano hit ratio anche oltre il 95% su siti high-traffic.
Domande frequenti
D: Qual è un'hit ratio "buono"?
R: Dipende dal sito, ma 70-90% è normale per siti statici. 50-70% per siti dinamici.
D: Hit ratio include asset CSS/JS o solo HTML?
R: Include tutto. Spesso CSS/JS hanno hit ratio >95%.
D: Come escludere bot da analytics?
R: Le cache analytics aggregano tutto. Per filtraggio usa Logpush + analisi custom.
D: Posso aumentare hit ratio per API JSON?
R: Sì se le risposte sono cacheable (idempotent, no auth-specific). Aggiungi Page Rule Cache Everything.
Considerazioni operative finali
Quando applichi una configurazione di questo tipo in produzione è sempre buona norma seguire un'approccio incrementale: parti con un test su staging, monitora gli effetti per qualche giorno, poi estendi gradualmente al traffico live. La rete Cloudflare elabora ogni cambiamento in pochi secondi a livello globale, quindi le modifiche sono effettive quasi immediatamente, ma gli effetti collaterali su utenti reali possono richiedere ore o giorni per emergere. Annota nel runbook interno data, motivo e parametri di ogni modifica significativa. Una documentazione precisa accelera enormemente il troubleshooting futuro e facilita il passaggio di consegne tra membri del team.
Vale anche la pena ricordare che Cloudflare aggiorna frequentemente l'interfaccia del dashboard e le posizioni delle voci di menu. La logica e le funzionalità descritte in questa guida restano valide, ma il percorso esatto per raggiungere ogni opzione può variare leggermente nel tempo. In caso di difficoltà a trovare una specifica voce, utilizza la barra di ricerca interna del dashboard oppure consulta la documentazione ufficiale aggiornata. La community Cloudflare sul forum ufficiale e su Stack Overflow è inoltre molto attiva e offre spesso risposte rapide a problemi specifici di configurazione.
Per progetti complessi che coinvolgono più servizi Cloudflare contemporaneamente (CDN, Workers, WAF, Access, R2) conviene strutturare la configurazione come codice tramite Terraform o Pulumi. Questo permette versioning, code review, rollback atomici e deploy ripetibili tra environment. Per team con esigenze più semplici la gestione manuale via dashboard resta perfettamente valida, soprattutto se accompagnata da una checklist scritta delle impostazioni applicate. La scelta dell'approccio dipende dalle dimensioni del progetto e dal grado di automazione desiderato. L'importante è essere consistenti e mantenere tracciabilità delle modifiche effettuate.
Hai bisogno di aiuto?
Se vuoi configurare Cloudflare per il tuo sito con il team di G Tech Group, scrivici tramite il modulo di contatto.