The Cloudflare Script That Was Slowing Down My Site (And How I Fixed It)

I was doing a routine performance audit on MyTreda when I noticed something in the network tab I didn't put there.

Cloudflare was injecting `email-decode.min.js` into every page that had a contact email in it. The script was loading as render-blocking — meaning the browser had to wait for it before it could finish painting the page.

For a product where I care a lot about PageSpeed scores, that was worth investigating.

What Cloudflare Email Obfuscation Does

Cloudflare has a feature called Email Address Obfuscation. It's enabled by default on most Cloudflare-proxied sites. The idea is to protect email addresses from being harvested by spam bots.

Here's how it works under the hood:

1. Cloudflare scans the HTML of every outgoing response, looking for `@` patterns
2. When it finds one, it rewrites the email into an encoded version
3. It injects `email-decode.min.js` into the page — a small script that decodes and renders the email client-side

So a plain email like `hello@mytreda.com` in your HTML gets replaced with something like:

<a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="...">[email protected]</a><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script>

The problem with that last line is the script loads synchronously. It's render-blocking by default. That adds latency to your First Contentful Paint — exactly the kind of thing that chips away at PageSpeed scores.

Where It Was Happening

In MyTreda's footer, I had a support email written the normal way:

// Footer.tsx

const SUPPORT_EMAIL = 'hello@mytreda.com';

That string exists in the rendered HTML, Cloudflare sees the `@`, and the injection kicks in. The fix was simple: don't let the full email address exist as a literal string in the HTML that Cloudflare parses.

The Fix

// Split to prevent Cloudflare email-obfuscation from injecting email-decode.min.jsconst SUPPORT_EMAIL = 'hello' + '@' + 'mytreda.com';

By assembling the email in JavaScript rather than hardcoding it, the full `@` pattern never appears in the static HTML. Cloudflare scans the HTML and finds nothing to obfuscate. The script doesn't get injected. The email still renders correctly in the browser because React assembles the string at runtime before it hits the DOM.

The Tradeoff

This is worth being honest about: by bypassing Cloudflare's obfuscation, you're giving up the spam protection it provides.

Cloudflare's encoding makes it harder for basic scrapers to harvest the email. If you split the string in JS, a scraper that runs JavaScript can still find it — though most basic ones won't bother.

For a support email that's already on a public-facing page, that tradeoff made sense for me. The performance gain was more valuable than the marginal protection. Your call might be different.

If you want full protection and no render-blocking script, the better option is to drop the `mailto:` link entirely and use a contact form. The email never appears in the HTML at all.

How to Verify It's Working

After deploying:

1. Open the page in an incognito window
2. Open DevTools → Network tab → filter by "email"
3. If `email-decode.min.js` doesn't show up, you're good

You can also view the page source (`Ctrl+U`) and search for __cf_email__. If Cloudflare is still intercepting, that class will be there.

Quick Summary

Small thing, but this is the kind of detail that adds up when you're trying to keep PageSpeed scores consistently high. Found it during a routine review, fixed it in two minutes.