I moved my WordPress website to Cloudflare Workers and compared the speed

Hi, I shared my experiences moving my static WordPress page website to the Cloudflare workers and compared the speed results.

Just my 2 cents:

if you test something always test it from multiple views/positions (geo-wise) becasue for me the worker edition is not just about 3-4 times faster but also does performn much much better when it comes to other SEO standards. On top of this the worker edition is much smaller and loads faster, also it does not produce as much CPU load as the normal version which is important when it comes to mobile devices.

Beside this you also do hast different version hosted on both types of hosting.
The version hosted on www.movsumov.com seems to be newer then the version on farid.movsumov.workers.dev. If you compare something please just include one varaible. Not two or more. Otherwise the comparison is not clear and not valuable at all!

Here the screenshots:



Final comparison from me:

With CloudFlare Workers your stats changed to (tested from germany - stuttgart)

Event/Size Time native Time CF-W Ratio
Load-Event 1.27s 277ms 4.58x faster with CloudFlare
DOMLoaded 787ms 185ms 4.25x faster with CloudFlare
Finish 2.04s 1.27s 1.6x faster with CloudFlare
kB transfered 381kB 196kB 1.94x less data to transfer with CloudFlare

Beside all this facts your page, just by moving it to CloudFlare improved its GPSI by some points. Even if you host it on Wordpres (which I’m not as fan of becasue of the pure optimizations of most pages!) you improved it from:
Test HERE as it can vary

Test HERE as it can vary

Which is a bump from 85 => 90 (on mobile, please just test mobile!) which is very good for doing nothing.

These are just my 2cents and seems we made different experienc, but I also have to manage, that I was served from CPH which is nor even the closest POP/Ray which most probable tells you are using CloudFlare free package. So this again could improve by switching to pro by a lot.
So all these tests have been made under “ok” but nnot even perfect conditions as I normaly get served from FRA which then would be even faster.

1 Like

this for me also seems not to be true. May it is static, but its not getting served static!
Your site (if I soft-reload) does not trigger a 304 HTTP Code but a 200 HTTP Code instead, which tells me:

  • your site may is staic, but it not getting threathen statically.
  • or your site it static by technical definition, but it not getting served statically

last option often is the case when PHP is getting used as it does not cache statically by default, it caches dynamically.

You can just visit my site (https://www.hotmann.de) and check the http-response code after some (soft) reloads (without “disable Cache”) and see it will trigger a 304 code which implicates it is getting cached AND served statically, as dynamic content is not triggering 304 (normally).

1 Like

Here an additional independent test:

This test is getting done, both times from Amsterdam, NL - GCE and shows shat the CloudFlare edition outperforms your normal website in every discipline.

Thanks for the detailed analysis M4rt1n, now when I am checking again it seems also faster to me. Did you change some configuration? By static, I meant actually a website that is not being updated often but it is a WordPress website which I explained details in the blog post. Nice to see it is working faster now.

1 Like

What do you mean by:

I do not have access to anything that let me change configurations which would affect anything on this sites. You are hosting these sites, which makes it impossible for me to change anything.

Ok, but the technical definition is something else, which would confuse other people who read your blogpost.

Have fun with it! You can switch to CloudFlare whenever you want and if you do have problems with performance or anything else, just contact the support, they are working hard to make all sites performing fast.

1 Like

Thanks for sharing your findings :slight_smile:

It’s interesting to see how the ease of usage and availability of Cloudflares services for Wordpress creates more awareness, Cloudflares “Cache everything” have always been making Wordpress sites super-fast. And the new Cloudflare sites will just make this even more apparent when it ends up in the hands of new developers and Wordpress maintainers!

Can’t wait until Cloudflare Apps have workers enabled (again), it’s going to be exciting to see what people create with it. Maybe even a Wordpress killer:wink:


Sorry I was thinking you work at Cloudflare. Interesting to see speed increased today comparing to yesterday. Can this be because some smart algorithm which is optimizing content delivery.

You are welcome, yes definitely I am also now following Cloudflare closely.

The speed increase is probably due to KV values now being delivered (and cached) regularly from edges instead of from the central KV location. Makes a big difference on the first few requests and total average.

No sorry I’m not working at CloudFlare.
In the forum here people can be split into 3 groups:

  1. regular user (me)
  2. MVPs
    special people with special knowledge in some areas, but not working for CloudFlare and are from the community. They do have a “MVP” sign at their profile
  3. CloudFlare-people
    they work at CloudFlare and do have a CloudFlare batch at their profile

No workers normaly did not change the last days. What could affect performance at any site getting routed through CloudFlare is:

  1. your ISP and how he routs your traffic to CloudFlare IPs/Servers.
    This most often is affecting performance at CloudFlare related things the most and can not be improved by CloudFlare, then by buying a higher plan (Pro, Business, Enterprise)
  2. overloaded network at CloudFlare. This COULD be a thing, but sinc esome years I have just encountered this once yet, so this might not be it.

For checking where you get served from CloudFlare you simply open the Dev-Console in your browser and check the response header.

cf-ray: 5fa6729e5db07367-CPH

Today I’m getting served from CPH (Copenhagen) which is not very good, but my ISP actually sometimes does stupid things.
CloudFlare itself is normaly serving you from the fastest/closest POP/RAY possible. OFC Paying members are preferred.

So many things could affect performance, but the difference was (140ms -42ms) 98ms which is very much so I think it might was something non-related to CloudFlare as no performance-issues have been tracked the last days. See ==> https://www.cloudflarestatus.com/


Thanks for this tip on how to check the location.

I am again started to get a slower response. Doc load time 160ms was 50ms in the morning.

cf-ray: 5fa6a7804ad1e6b0-EWR which is in New Jersey

Really strange why they serve page to someone who is in Amsterdam from New Jersey :thinking:

Thats indeed strange. Please open a support ticket with this and pass the cf-ray into it so they can debug it.

I ATM do get served from amsterdam: cf-ray: 5fa6b8e6adb07239-AMS

What does show in colo field, and your Workers? You might be better off if you could add a Worker route for your zone, by visiting Workers tab in your domain on Cloudflare, and set one.one.one.one in CNAME record (with :ngrey:) for that route in DNS tab. That will make sure further requests will hit, which could make you traverse a more optimized path and possibly hit the nearest premium PoP.

I didn’t see this trick documented anywhere, so wanted to share. Normally, you’re expected to put 100:: AAAA record (with :norange:, which will make you go through a standard set of IPs designated for free plan customers) if you need a Workers route for a subdomain as per official docs:

Subdomains must have a DNS Record

All subdomains must have a DNS record to be proxied on Cloudflare and used to invoke a Worker. For example, if you want to put a worker on myname.example.com , and you’ve added example.com to Cloudflare but have not added any DNS records for example.com , any request to myname.example.com will result in the error ERR_NAME_NOT_RESOLVED .

To support this, you should use the Cloudflare dashboard to add an AAAA record for myname to example.com , pointing to 100:: (the reserved IPv6 discard prefix).