Cloudflare Analytics is not one thing. Web Analytics is a free JavaScript beacon that works on any site whether or not it is proxied through Cloudflare, while zone analytics is a separate view built from traffic that actually passes through Cloudflare’s network as your DNS proxy.
The two get conflated constantly because they share a dashboard and a name, but they measure different traffic through different mechanisms, and knowing which one you are looking at changes how you should read the numbers.
Table of contents
- Web Analytics: the free JS beacon
- Zone analytics: what the proxy sees
- Visits vs page views, and what the numbers mean
- Core Web Vitals inside Web Analytics
- Adding the beacon: static, Next.js, WordPress
- Limits vs Google Analytics, and reading it next to server logs
- How this fits the rest of the stack
- FAQ
Web Analytics: the free JS beacon
Cloudflare Web Analytics is a small JavaScript snippet you add to your site’s pages, similar in shape to a Google Analytics tag. It does not require your domain to be proxied through Cloudflare at all - you can run it on a site hosted anywhere, with DNS pointed anywhere, and it still works, because the beacon reports directly to Cloudflare from the visitor’s browser.
It is built to be privacy-friendly by design: no cookies, no persistent visitor identifiers, and no cross-site tracking. That also means it cannot do some things cookie-based tools do, like building a long-term profile of the same visitor across multiple sessions - it counts activity, not identity.
<!-- Add just before </body> -->
<script defer src='https://static.cloudflareinsights.com/beacon.min.js'
data-cf-beacon='{"token": "YOUR_TOKEN_HERE"}'></script>Setup takes minutes because there is no account-linking step beyond generating the token in the Cloudflare dashboard and pasting the snippet in. There is also no sampling on the free tier the way some analytics products throttle data collection past a traffic threshold, so the numbers you see reflect all beacon-reporting traffic, not an extrapolated estimate from a subset of it.
Zone analytics: what the proxy sees
If your domain’s DNS is proxied through Cloudflare (the orange-cloud setting, as opposed to grey-cloud DNS-only), Cloudflare’s edge network sits in front of every request before it reaches your origin server. That vantage point produces a different kind of analytics: total requests, bandwidth, cache hit ratio, threats blocked, and status code breakdowns.
This view is a byproduct of the proxy doing its job - terminating TLS, caching static assets, filtering malicious traffic - rather than a purpose-built analytics product. It is closer to server log analysis than to visitor analytics, and it includes bot and crawler traffic that the JS beacon would never see, since bots rarely execute JavaScript.
The cache hit ratio specifically is worth watching on its own, separate from the traffic totals. A low ratio on a site serving mostly static assets usually means cache rules need tuning - too-short TTLs, cache-busting query strings, or headers that mark content as private when it could safely be shared - rather than a traffic problem at all.
Visits vs page views, and what the numbers mean
A page view is counted every time the beacon fires, once per page load. A visit groups page views from the same visitor within a session window into a single unit, so someone reading three articles in one sitting counts as one visit and three page views.
Neither number alone tells you engagement quality. A high page-view-to-visit ratio suggests people are clicking through multiple pages per session, which is usually a good sign for a content site and a slightly ambiguous one for a landing page, where you might actually want a single, decisive page view that ends in a conversion.
Single-page applications complicate this further, since a client-side route change does not trigger a full page load the way traditional navigation does. The beacon can be configured to fire on route changes in an SPA, but it is worth checking that it actually is, or an app with heavy client-side routing will under-report page views relative to what users are actually doing on the site.
Core Web Vitals inside Web Analytics
Web Analytics reports real-user Core Web Vitals alongside traffic numbers: Largest Contentful Paint (how fast the main content renders), Cumulative Layout Shift (how much the page jumps around while loading), and interaction responsiveness metrics. These are field data - measured from actual visitors’ browsers - rather than a lab simulation.
Field data is more honest than a single lab test because it reflects the real mix of devices, connections, and locations hitting your site, but it is also noisier and takes real traffic volume to become statistically meaningful. A low-traffic site will see these numbers swing around more than a high-traffic one.
Adding the beacon: static, Next.js, WordPress
On a static site, paste the script tag directly into the shared layout template so it loads on every page - a footer partial or base layout is the natural place, ensuring it is not accidentally left off a new page later.
On a Next.js site, load it with the built-in Script component set to load after the page becomes interactive, rather than a raw script tag, so it does not compete with your app’s own hydration and initial render.
import Script from 'next/script'
export default function Analytics() {
return (
<Script
strategy='afterInteractive'
src='https://static.cloudflareinsights.com/beacon.min.js'
data-cf-beacon='{"token": "YOUR_TOKEN_HERE"}'
/>
)
}On WordPress, the cleanest path is your theme’s header or footer template, or a small site-specific plugin that injects the script tag - avoid page builders that strip raw script tags from content areas, since the beacon needs to run on every page, not just one.
Limits vs Google Analytics, and reading it next to server logs
Web Analytics is intentionally lighter than Google Analytics: no custom event tracking, no funnels, no audience segmentation, no integration with an ads platform. It answers ‘how much traffic, how fast, how good are the vitals’ well, and stops well short of full behavioral analytics.
The honest way to use it is alongside your own server or application logs, not instead of them. The beacon tells you what real browsers experienced; your logs tell you what actually hit your server, including the bot traffic, the failed requests, and the API calls the beacon never sees because no browser rendered a page for them.
The two tools are also complementary rather than competing on most real sites: Web Analytics for a fast, privacy-friendly read on traffic and page experience, a heavier tool if you need funnels and campaign attribution, and your own logs as the ground truth underneath both. Running all three is not redundant, it is three different vantage points on the same traffic, and each one catches something the others structurally cannot see.
How this fits the rest of the stack
Cloudflare Web Analytics is free, adds a few lines to a page, and gives an honest, privacy-friendly read on traffic and Core Web Vitals without needing to proxy your DNS through Cloudflare at all. It is worth pairing with the runtime logs and metrics your hosting already gives you rather than treating either one as the whole picture - the RunxBuild hosting calculator is a useful next stop if you are also weighing what the static site or service serving those pages actually costs to run at your traffic volume.
Once the beacon is in, the deploy side of the same site can live on the RunxBuild dashboard, so the traffic numbers and the build that served them sit one tab apart.
Useful related references:
- Cloudflare Rate Limiting: How Rules Work and Sane Starting Thresholds
- Cloudflare Cdn Wordpress: What Works Free and What Production Needs
- WordPress Speed Optimization: The Order That Actually Moves the Number
- Static sites on RunxBuild
FAQ
Is Cloudflare Analytics free?
Cloudflare Web Analytics, the JavaScript beacon product, is free with no traffic cap. Zone-level analytics from the proxy is included automatically once your domain is proxied through Cloudflare, also without an extra charge on the free and most paid plans.
Does Cloudflare Analytics require my domain to be proxied through Cloudflare?
No, for Web Analytics specifically. The JS beacon reports directly from the visitor’s browser and works on any site regardless of DNS setup. Zone analytics, the request-and-bandwidth view, does require the domain to be proxied, since it is measured at Cloudflare’s edge.
What is the difference between Cloudflare Web Analytics and Google Analytics?
Web Analytics is cookieless, lighter weight, and limited to traffic and Core Web Vitals reporting. Google Analytics offers custom events, funnels, audience segmentation, and ad-platform integration, at the cost of a heavier script and cookie-based tracking that needs a consent mechanism in many jurisdictions.
Does Cloudflare Analytics count visits or page views?
It reports both, as separate numbers. A page view is counted on every page load; a visit groups a visitor’s page views within a session window into one unit, so multi-page browsing counts as one visit with several page views.
Can Cloudflare Web Analytics track traffic that blocks JavaScript?
No. The beacon only fires when a visitor’s browser executes the JavaScript on the page, so traffic from clients that block scripts, most bots, and server-to-server requests will not appear in Web Analytics at all. Server or zone-level logs are the way to see that traffic.