circle

How to disable Cloudflare caching and Web Analytics

Green network cables plugged into a Cat6 patch panel in a server room

If your site suddenly hangs while loading and you haven’t changed anything, search your page source for beacon.min.js. That script is Cloudflare Web Analytics, and Cloudflare can inject it into every page it proxies. This guide shows how to switch it off. It then covers how to disable Cloudflare caching completely, so every request goes straight to your origin server.

What is static.cloudflareinsights.com?

It’s the address Cloudflare Web Analytics loads from. Web Analytics, also called Real User Monitoring or RUM, adds this script tag to your HTML as the page passes through Cloudflare’s network: https://static.cloudflareinsights.com/beacon.min.js

You won’t find it in your theme, your plugins or your server files. Cloudflare adds it at the edge, which is why so many site owners spend hours looking in the wrong place.

Why the Cloudflare beacon script slows some sites

Most of the time the script loads without anyone noticing. The trouble starts when a visitor’s ad blocker, or a DNS blocker on their router or office network, blocks cloudflareinsights.com. If the blocker refuses the request, nothing happens. If it drops the request silently, the browser keeps waiting until the connection times out.

Browsers must finish every defer script before firing the DOMContentLoaded event. Anything on your site that waits for that event waits too, including menus, sliders and many WordPress plugins. The page looks half loaded, the tab spinner keeps going, and nothing in your own code explains it.

The beacon.min.js ERR_BLOCKED_BY_CLIENT error

If you see net::ERR_BLOCKED_BY_CLIENT next to beacon.min.js in your browser console, a browser extension blocked the script. On its own that error is harmless, because the block is instant. The slow case is the silent drop described above, which shows up in the Network tab as a request stuck on pending.

How to disable Cloudflare Web Analytics

  1. Log in to the Cloudflare dashboard.
  2. Open Analytics & Logs in the account sidebar, then Web Analytics.
  3. Find your domain in the site list and open it.
  4. Disable the site, or remove it from the list.
  5. Go to Caching, then Configuration, and select Purge Everything. Cached pages still carry the old script until you clear them.

New requests stop getting the script within a minute or two. To confirm it worked, open your site in a private window, view the source and search for cloudflareinsights. If there’s no match, the script is gone.

Still there after disabling it?

Then something other than automatic setup is adding it. Check your theme’s header.php, any “insert headers and footers” plugin, Google Tag Manager, and Cloudflare Zaraz for a manually pasted snippet. Remove it there.

Block injection from your server

If you want a guarantee that Cloudflare never changes your HTML, send this header from your origin:Cache-Control: no-transform

Cloudflare won’t modify responses carrying that header, so the script can’t be injected. It also switches off other Cloudflare features that rewrite HTML, such as Rocket Loader and email address obfuscation.

How to disable Cloudflare caching completely

Cloudflare has no single off switch for caching. By default it caches static files like images, CSS and JavaScript, and passes HTML through. To stop all caching, create a Cache Rule.

  1. Select your domain, then go to Caching and Cache Rules.
  2. Select Create rule.
  3. Under “If incoming requests match”, choose All incoming requests.
  4. Set Cache eligibility to Bypass cache.
  5. Name the rule “Bypass all caching” and select Deploy.
  6. Purge the cache again so nothing old is served.

To check it, open your browser’s developer tools, go to the Network tab and look at the response headers. The cf-cache-status header should show BYPASS or DYNAMIC, never HIT.

Temporary option: Development Mode

If you only need caching off while you test changes, turn on Development Mode under Caching, Configuration. It suspends caching for three hours, then switches itself off.

Leave the proxy entirely

If you only use Cloudflare for DNS, set your records to DNS only, the grey cloud icon. Cloudflare then stops proxying your traffic, so there’s no caching and no script injection.

The trade off is that your origin IP becomes public in your DNS records. You also lose Cloudflare’s firewall and DDoS protection. For most sites, keeping the proxy on with a bypass rule is the better choice.

Keep your origin IP hidden

The proxy only hides your IP if nothing else gives it away. Check these:

  • Other DNS records. A mail, ftp or cpanel record pointing at the same server, with the grey cloud, exposes the IP.
  • Email headers. If your web server also sends mail, its IP shows up in every message header.
  • Old DNS history. Services like SecurityTrails keep past records. If your IP was public before Cloudflare, consider moving to a new one.
  • Your origin firewall. Allow web traffic only from Cloudflare’s published IP ranges, so a leaked IP still can’t serve your site directly.

What this means for Australian sites

If your server is in Sydney or Melbourne and most visitors are Australian, the trip from browser to origin is already short. Bypassing the cache costs a local audience less speed than a global one. Your server now handles every request, though, so watch CPU use and response times for the first week.

Routing matters too. The Cloudflare data centre an Australian visitor reaches depends on their ISP and your plan, and it isn’t always the closest one. We tested this in BunnyCDN vs Cloudflare for Australian routing.

Even with caching and analytics both off, the proxy still does one job many site owners rely on: it hides your origin server’s IP address. Visitors, bots and attackers only see Cloudflare’s addresses, which makes it much harder to target your server directly. If that’s why you use Cloudflare, keep the orange cloud on and switch off only the features you don’t want.

FAQ

No. It’s Cloudflare’s own analytics script. Some security scanners flag it because it appears in your HTML without your code adding it.

Cloudflare says it doesn’t set cookies or use local storage. It still sends visit data to Cloudflare, so mention it in your privacy policy while it’s on.

No. The traffic figures in your zone’s Analytics tab come from Cloudflare’s edge, not from the script, so they keep working.

Cloudflare didn’t treat the response as cacheable and fetched it from your origin. That’s the default for HTML pages.

Not directly. Google measures how fast real visitors load your pages, not whether you use a CDN. [Inference] With a fast Australian host and a mostly local audience, the difference is usually small. Check Core Web Vitals in Search Console a month after the change.

Photo by Brett Sayles