The five, side by side
| Route | Works on | What you change | Who tunes it | Where it stops |
|---|---|---|---|---|
| Caching or optimization plugin | WordPress | Install a plugin | You, through settings and exclusion lists | A builder has nowhere to install it; cached HTML is still the same page |
| CDN or edge network | Any site | DNS | You, through rules | By default it delivers the page as it is |
| Script in the head | Site builders | Paste code into the head | The vendor | Runs after the browser has met the page’s own files |
| Developer or agency | Any site you can edit | The site’s code | Them, once | The next redesign, plugin or marketing tag |
| Reverse proxy (WebSpeed) | Any platform | DNS; an SDK on request | Us | One server, no CDN; little to gain above a score of about 70 |
They also stack: a WordPress site can run a caching plugin behind Cloudflare with a developer’s fixes in the theme. So the useful question is what the next one adds on top of the ones already in place.
A plugin: WordPress only, and mostly about when the page arrives
A caching plugin saves the HTML that WordPress would otherwise build on every visit, so the server answers sooner. The better ones go further and defer scripts or inline the CSS the first screen needs.
Two limits come with the form. A plugin needs a plugin system, so on Wix, Squarespace, Webflow, Duda or Tilda there is nowhere to put one. And a page cache changes when the page arrives, not what is in it: a page that asks a phone to run two megabytes of third-party JavaScript asks the same after it is cached. We measured this on nine WordPress sites run by performance-plugin makers and speed publishers, and wrote it up in a caching plugin didn’t make these sites fast on mobile.
The larger picture points the same way. Of the 705 WordPress sites in our audit base with a valid before and after measurement (30 September 2026), 346 already ran a caching or optimization plugin we could detect from outside. Through our proxy, 63% of them still gained on mobile without losing more than two points on desktop, by a median of 4 points. The plugin had done its part, and the page work was still there.
A CDN: closer to the visitor, same page
Cloudflare and other CDNs keep copies of your files near the visitor and can take over TLS and caching. That shortens the trip, which matters most for heavy files and for visitors far from your server. What a CDN does not do by default is change the page. Cloudflare does not cache HTML unless you add a rule or use its WordPress add-on, and it has been retiring the features that did touch the page: Auto Minify in August 2024 and Mirage, its image loading for slow connections, in September 2025.
So we checked whether a site already behind Cloudflare leaves less for page-level work to do. Of the 705 WordPress sites in our audit base with a valid before and after measurement (30 September 2026), 299 answered through Cloudflare. Through our proxy, their mobile score rose, without desktop dropping more than two points, on 59% of them. On the 406 without Cloudflare it was 63%, and the median gain was 4 points in both groups. That gap is inside the run-to-run noise: Cloudflare in front did not use up the work inside the page.
Two things that number does not say. Cloudflare was detected from the response headers when each audit ran, and a CDN that answers as a plain web server goes unrecognised, so a few of the 406 sit behind one. And across all platforms the gap looks wider (58% against 62%), but that is the platform mix, not Cloudflare: almost every Webflow site sits behind it, almost no Squarespace, Duda or Tilda site does, and those three gain more. These are sites we chose to audit, not a sample of the web.
A script in the head: the only door on a builder, and it opens late
On a site builder, the one place you can add code is a field for the head or the end of the body. Speed apps for builders work from there: a script that defers other scripts and adds preloads.
The limit is the order in which the browser reads a page. By the time a script at the end of the head runs, the browser has already met the builder’s own stylesheets and scripts and started fetching them. A script can add a preload; it cannot take back a stylesheet that has already been requested. We built this route ourselves for Tilda and switched it off in August 2026, because the ceiling is in that order and no tuning moves it.
One more check before you trust a script like this: whether it does the same for a visitor as for the test. Some speed scripts recognise Lighthouse and change the page only when it is the one loading it, which lifts the score and nothing else. Compare the screenshot in the PageSpeed report with the page in your own browser, fonts and images included.
A developer or agency: the deepest reach, once
Someone with access to the code can do what no layer in front of it can: replace a slider plugin, drop an unused font family, move the site to a better host. It is the one route that removes work from the page instead of reordering it.
It is also a project with an end date. Sites keep changing after the handover: a new tag from marketing, a landing page built outside the theme. Nothing reapplies the fix. We have no measurements of agency work, so there is no number here. If you hire one, ask for mobile before and after figures from three runs each, as in our guide to running the test, and ask what keeps the result once they have gone.
A reverse proxy: any platform, with its own ceilings
This is the route we sell. A reverse proxy sits between the visitor and your site. Your site serves the page as it always has; the proxy rewrites how it loads (third-party scripts deferred, critical CSS inlined, unused head assets dropped, the first-screen image preloaded) and hands the result on. It works on the delivered HTML, so it does not matter what built the page: WordPress, Tilda, Wix, Squarespace, Duda or a hand-written site. You connect with a DNS change, and for sites that cannot move DNS an SDK is available on request.
Where it stops:
- One server, no CDN. The proxy adds a hop, and visitors far from it get no edge nearby. If your audience is on another continent, a CDN does something this cannot.
- No dashboard of your own. There are no per-page settings; we configure the site, and excluding a page goes through us.
- Little to gain on sites that are already fast. Of 381 sites we audited in August 2026, those starting in the 30s and 40s gained a median of 11 points, and those above 70 were as likely to lose points as to gain them.
- It reorders and trims; it cannot remove what the page needs. A 4 MB background video is still 4 MB, only later.
Which one fits your site
- WordPress with a caching plugin, still slow on mobile. The plugin has done the server half. What is left is in the page, which is work for a page-level optimizer or a developer.
- A site builder. A plugin is not an option and a head script hits the ceiling above, which leaves a proxy or a rebuild. What we found on each builder is in our platform pages.
- Already above 70 on mobile. Expect small and uncertain gains from any tool. The larger wins are usually in the content: heavy media and third-party tags.
- Visitors far from your server. Start with a CDN. It is the one route on this list that shortens the distance.