An opt-out read as an opt-in
Rocket Loader is a Cloudflare feature that
defers the loading of all of your JavaScript until after rendering.
That is a large thing to do to somebody else’s page, so Cloudflare provides an escape hatch:
a script tag carrying data-cfasync="false" is
left alone.
The attribute is therefore a statement by whoever wrote the script, not by the site. It means “if Rocket Loader is ever turned on here, skip this one” — and since plugin and theme authors have no way to know whether a given installation is behind Cloudflare, the sensible thing for them to do is print it unconditionally. Which is what they do.
Read backwards, though, it looks like evidence. The attribute is a distinctive string in the markup, it appears on sites that use Cloudflare, and it is trivial to grep for. That is how it ends up in detection lists, including one of ours.
What the base says
Of 482 audited sites with stored markup, 63 carry the attribute — about one in eight. On 54 of those 63, the stored HTML contains no other marker of any Cloudflare script optimization at all.
Stored markup alone cannot settle this, and the reason is the interesting part: our copies are fetched with a crawler user agent, and Cloudflare does not necessarily serve the same optimizations to a crawler that it serves to a browser. An absent runtime in our archive could mean the feature is off, or it could mean we were not shown it.
So we asked properly.
The live probe
On 2026-08-04 we requested all 63 sites over HTTPS with a current desktop Chrome user agent, following redirects, and searched what came back.
| Sites | |
|---|---|
| Responded with a full page | 63 |
Still carrying data-cfasync | 62 |
Loading anything from /cdn-cgi/scripts/ | 19 |
| Running the Rocket Loader runtime | 2 |
The two are scratchpetfood.com.au and wpmet.com. Everything else in that column of 63 is a
site whose markup announces a feature it is not using.
The /cdn-cgi/scripts/ row is the near-miss worth separating out, because it is the second
half of why this signal looks good. Cloudflare serves several unrelated things from that path
— email address obfuscation and the analytics beacon most commonly — so a detector that
accepts either the attribute or that path as evidence gets a plausible-looking 19 hits and is
wrong on 17 of them.
Why we care about this particular string
Because a proxy in front of a site has to decide whether the site is already managing its own script execution order. If it is, moving those scripts again is not an optimization — it is two schedulers fighting, and the visible result is a first screen that never finishes.
That decision is only as good as the signals behind it, and this one turned out to be measuring the wrong thing. We report it here for the same reason we publish our misses elsewhere on this site: a detection rule with a 3% hit rate is a fact about our tooling that anyone building similar tooling can use, and it is not the kind of fact that gets published unless the people who made the mistake publish it.
If you are detecting Cloudflare features
Three practical notes from the exercise.
Look for the runtime, not for accommodations to it. rocket-loader.min.js in the delivered
HTML is a fact about this response; data-cfasync in the same HTML is a fact about a plugin
author’s caution.
Fetch with a browser user agent when the question is what a browser gets. Half of what a CDN does is conditional on who is asking, and an archive built by a crawler will systematically under-report exactly the optimizations you are trying to detect.
And check the negative case at scale before trusting a marker. Our original rule was validated on a handful of sites where it happened to be right. A sweep of the full base is what turned a plausible signal into a measured 2 out of 63, and the sweep took minutes.
Method and limits
We scanned the stored original HTML of 482 audited sites for the string data-cfasync, finding 63. Because the stored copy is fetched with a crawler user agent and Cloudflare serves different optimizations to different clients, that scan cannot settle the question on its own — so on 2026-08-04 we requested all 63 sites live over HTTPS with a current desktop Chrome user agent, following redirects, and searched the delivered HTML for the Rocket Loader runtime (rocket-loader) and for anything served from Cloudflare's /cdn-cgi/scripts/ path. All 63 returned a page.
Measured on 4 Aug 2026 across 482 sites. These figures are frozen at that date — we don't quietly restate a published study when the audit base grows.
What this doesn't show
- Not a random sample of the web. 482 sites we chose to audit, so the 13% carrying the attribute describes our base and not the internet. The finding that matters here is the ratio inside that group, which does not depend on how the group was assembled.
- We look at the HTML of one page load. Rocket Loader could in principle be enabled at the zone level and not appear on the page we requested — a page rule, a bypass, or a cached variant would all produce that. The correct reading is therefore "the attribute does not let you conclude Rocket Loader is running", not "these sites definitely do not use it".
- Two sites is a small enough number to be worth naming rather than rounding to a percentage: scratchpetfood.com.au and wpmet.com. Everything else about the sample is a negative result, and negative results are easier to overstate than positive ones.
- We did not check whether the sites had Rocket Loader enabled and then disabled it, which would leave the attribute behind in plugin markup indefinitely. That is in fact one of the likelier explanations for part of the group, and it strengthens rather than weakens the conclusion about the signal.
Sources
- Rocket Loader — Cloudflare Docs
Rocket Loader prioritizes your website's content (text, images, fonts, and more) by deferring the loading of all of your JavaScript until after rendering.
- Ignore JavaScripts — Cloudflare Docs
You can have Rocket Loader ignore individual scripts by adding the data-cfasync="false" attribute to the relevant script tag