Cloudflare Analytics: capire visitatori, richieste e percentuale di cache

Come leggere insieme i quattro numeri di Cloudflare

Prendiamo un esempio generico: alcune centinaia di visitatori unici, alcune migliaia di richieste, decine di megabyte forniti e una percentuale di cache a una cifra. Sono segnali utili, ma non indicano quante persone abbiano letto una pagina. Cloudflare osserva il traffico HTTP che attraversa la sua rete per i record DNS proxy, quindi misura un livello infrastrutturale precedente rispetto agli strumenti caricati nel browser. Il dato include richieste che possono provenire da utenti, crawler, bot, controlli automatici o servizi esterni.

I visitatori unici approssimano le sorgenti del traffico; le richieste contano le singole operazioni HTTP; i dati forniti sommano il volume delle risposte; la percentuale in cache indica quanta attività è stata servita dall’edge secondo la vista scelta. Verifica sempre periodo, hostname, filtri e se il grafico riguarda richieste oppure dati.

Visitatori unici: indirizzi IP, non persone identificate

Perché un visitatore unico non equivale a un lettore

Cloudflare spiega che identifica una visita quando rileva un indirizzo IP univoco associato a una richiesta. È una stima tecnica, non un conteggio di esseri umani, utenti autenticati o sessioni. Più persone dietro una rete aziendale, domestica o mobile possono condividere un IP; una sola persona può invece apparire più volte quando cambia rete o indirizzo. Anche crawler e richieste parziali possono contribuire senza generare una pagina vista completa.

Il numero è comunque prezioso per leggere tendenze, anomalie e distribuzione del traffico, purché il confronto usi sempre la stessa finestra e gli stessi filtri. Un aumento improvviso può indicare interesse reale, scansioni automatiche, campagne, anteprime social o traffico ostile. Per capire quale ipotesi è plausibile, segmenta per percorso, paese, user agent, stato di sicurezza e codice HTTP; non dedurre acquisizione commerciale dal solo totale degli IP.

Perché le richieste sono molte più dei visitatori

Una richiesta è una singola operazione HTTP. Il caricamento di una pagina può richiedere HTML, fogli di stile, JavaScript, immagini, font, chiamate API e redirect, quindi produce più richieste. Quando poche centinaia di IP generano alcune migliaia di richieste, il rapporto ottenuto non è una metrica di engagement: asset già presenti nel browser, bot che scaricano un solo file, errori, prefetch e architettura del sito cambiano radicalmente il risultato.

Dati trasferiti, cache ratio e stati della cache

Il volume indicato rappresenta il volume HTTP trasferito nelle risposte osservate da Cloudflare, non la dimensione del sito e neppure il traffico fatturato necessariamente da Vercel. Dividendo valori arrotondati si otterrebbe una media indicativa per richiesta, ma la media mescola risposte HTML, immagini, errori e risposte senza corpo. È più utile filtrare per tipo di contenuto e URL, poi cercare gli oggetti pesanti e frequenti che raggiungono l’origine.

Request hit ratio e byte hit ratio rispondono a domande diverse

La quota di richieste servite dalla cache misura quante operazioni evitano l’origine; la quota di dati serviti dalla cache misura quanti byte vengono consegnati dall’edge. Un sito può avere poche richieste in cache ma risparmiare molto traffico se le immagini pesanti sono cacheate. Può anche mostrare il contrario se molti piccoli asset sono HIT mentre grandi risposte restano dinamiche. In Cache Analytics, inoltre, una risposta revalidata può risultare servita dall’origine nella vista richieste ma da Cloudflare nella vista dati, perché l’origine viene consultata mentre il corpo resta in cache.

Lo stato HIT indica in genere una risposta disponibile in cache; MISS richiede il recupero dall’origine; BYPASS riflette una regola o un segnale che evita la cache; DYNAMIC indica contenuto non considerato idoneo; REVALIDATED comporta un controllo di freschezza. La distribuzione per stato, path e content type distingue HTML dinamico legittimo, asset configurati male e richieste non riutilizzabili.

Separare traffico umano, bot e minacce

La documentazione di Zone Analytics chiarisce che, nel pannello HTTP Traffic del piano gratuito, compaiono richieste legittime insieme a crawler e minacce. Cloudflare lavora all’edge e vede anche client che non eseguono JavaScript. Questo spiega perché i suoi visitatori unici possono superare utenti e sessioni registrati da strumenti browser-based. Un motore di ricerca, un monitor di uptime, un link preview o una scansione può generare traffico reale per l’infrastruttura senza rappresentare un potenziale cliente.

Per stimare le persone interessate, combina segnali: pagine HTML riuscite, referer, percorsi visitati, sorgenti note, eventi di conversione e filtri bot disponibili. Controlla anche picchi di risposte 403, 404 e 5xx, metodi insoliti e paesi inattesi. Non eliminare automaticamente tutto il traffico automatico: i crawler dei motori sono importanti per la SEO e i monitor sono utili. L’obiettivo è attribuire ogni metrica alla domanda corretta, non forzare tutti i pannelli a mostrare lo stesso numero.

Cloudflare, Web Analytics, GA4 e PostHog non misurano la stessa cosa

Zone Analytics descrive il traffico HTTP visto dalla rete. Cloudflare Web Analytics aggiunge una prospettiva lato pagina e prestazioni reali del browser. GA4 modella utenti, sessioni, canali ed eventi marketing; PostHog è particolarmente utile per eventi di prodotto, funnel e percorsi. Gli ultimi strumenti dipendono da caricamento dello script, consenso, ad blocker, navigazione completata e qualità dell’implementazione. Cloudflare può invece vedere una richiesta anche se la pagina viene abbandonata prima che il codice analytics parta.

Per una riconciliazione utile, allinea periodo, fuso orario, hostname e ambienti, poi confronta grandezze compatibili: page view HTML con visualizzazioni, conversioni con eventi confermati, richieste edge con log tecnici. Aspettarsi uguaglianza tra IP unici e utenti GA4 o PostHog crea falsi allarmi. È più sano definire una gerarchia: Cloudflare per volume e sicurezza, Web Analytics per esperienza di pagina, GA4 per acquisizione e PostHog per comportamento, mantenendo una fonte server-side per le conversioni critiche.

Perché una bassa percentuale di cache non è automaticamente un errore

Una quota bassa può essere corretta se gran parte delle richieste riguarda HTML personalizzato, API, anteprime, autenticazione o risposte con cookie e direttive private. MDN avverte che contenuti personalizzati non devono finire in cache condivise, perché potrebbero essere esposti ad altri utenti. Anche errori, redirect, query molto variabili e richieste non GET possono abbassare il rapporto. Ottimizzare significa aumentare la cache solo dove la risposta è pubblica, stabile e riutilizzabile, non inseguire una percentuale universale.

Con Vercel dietro Cloudflare esistono due livelli CDN. Una richiesta che per Cloudflare è un MISS e raggiunge l’origine configurata può essere servita dalla cache edge di Vercel; perciò il pannello Cloudflare non racconta da solo il carico sulle funzioni o sul server applicativo. Verifica insieme CF-Cache-Status e x-vercel-cache, oltre a Cache-Control, CDN-Cache-Control e Vercel-CDN-Cache-Control. I tre header possono avere destinatari e TTL diversi, mentre regole sovrapposte rendono più complessi invalidazione e debug.

Un audit sicuro prima di cambiare le Cache Rules

Parti da una settimana rappresentativa e classifica gli URL in asset versionati, pagine pubbliche, HTML dinamico, API pubbliche e risposte private. Per ogni gruppo misura richieste, byte, stato cache, codice HTTP e tempo verso l’origine. Esamina i principali MISS, controlla gli header con richieste ripetute e verifica il comportamento dopo deploy e purge. Dai priorità ad asset pubblici pesanti e frequenti; mantieni fuori dalla cache login, area amministrativa, cookie di sessione e dati personalizzati.

• Confronta rapporto per richieste e rapporto per byte, senza confonderli.
• Definisci TTL e chiave di cache per path e contenuto, non con una regola globale.
• Testa query string, cookie, autorizzazione, lingua e varianti prima del rollout.
• Controlla sia Cloudflare sia Vercel e documenta quale livello possiede la risposta.
• Monitora 4xx, 5xx, freschezza e conversioni insieme al miglioramento della cache.

Una regola “cache everything” applicata senza inventario può servire dati obsoleti o privati e rendere invisibili i problemi. Procedi per piccoli gruppi di URL, con rollback e verifica dal browser e dall’origine. I nostri servizi per infrastruttura, analytics e performance aiutano a costruire una lettura affidabile dei dati; per un audit della configurazione Cloudflare e Vercel, contatta AE Digital Agency.