Proxying Third-Party JavaScript as First-Party JavaScript (and the Potential Effect on Analytics)

Why first-party JavaScript is a get-out-of-jail-free card

Cloudflare Workers make proxying another URL almost trivially easy. A minimal Worker script is enough to fetch a remote resource and return it:

addEventListener("fetch", (event) => {
  event.respondWith(
     fetch("https://css-tricks.com")
  );
});

No error handling, no frills — but it works:

This becomes interesting when you consider that many sites hand you a JavaScript URL for a specific purpose. CodePen does exactly this for Embedded Pens, exposing an endpoint like:

That URL is:

https://cpwebassets.codepen.io/assets/embed/ei.js

Proxying it through a Worker is just as simple:

Even the content-type header comes through correctly without extra work:

Where this gets powerful is routing. Rather than relying on the Worker's own URL, you can attach the Worker to a route on your own domain inside the Cloudflare dashboard. That allows a URL on css-tricks.com to serve the proxied script:

Once that's in place, loading the embed is a matter of pointing a <script> tag at your own domain:

<script src="https://css-tricks.com/super-real-url/codepen-embeds.js"></script>

From the browser's perspective, that is first-party JavaScript. In reality, it's third-party code served through a proxy.

The motivation: blocker-proof scripts

The immediate question is why anyone would go through the trouble. The blunt answer: ad-blockers and privacy tools typically block third-party scripts by domain, but few people bother blocking first-party requests. That makes proxying attractive to sites running ads on their own pages — though it's a practice with obvious ethical gray areas. Banning ads should be a right, and forcing users to hunt down individual scripts to block them undermines that. At the same time, proxying to dodge a CORS limitation on your own site is harmless enough.

Analytics sits in a murkier middle zone. Plausible, for example, is a third-party analytics service pitched at privacy-conscious site owners. It's not the sort of script that raises red flags, but it is still analytics — a category broad enough that it can easily end up on blocklists. Over time, that means progressively less accurate data as more visitors block it.

Since very few people block first-party JavaScript, proxying analytics promises more reliable numbers. Plausible even publishes their own docs for proxying through Cloudflare. The setup is a bit more involved than the embed proxy above, but it works.

What the numbers show

Testing the proxied approach on CSS-Tricks produced a direct comparison. The earlier, non-proxied Plausible data set was compared with an identically-sized window using the proxy:

The proxied period's results are visibly different:

The week in question was 6% busier per unchanged Google Analytics data, so 15.7% more unique visitors would have been expected with the non-proxied setup (about 1.16 million). Instead, the proxied setup saw 1.32 million — a 13.8% increase over the non-proxy approach. Straight comparison between proxied Plausible and Google Analytics shows a staggering 32% delta in unique visitors.

Pageviews told a similar story. The non-proxied setup actually reported 6.6% fewer pageviews than Google Analytics; the proxied one reported 19.4% more. The numbers wobble between metrics, but for this site they suggest that on the order of 20-30% of visitors are blocking Google Analytics outright.