Implementation Help?


I’m not an expert on “cache everything” but I can explain what my code does which should be completely independent of any other cache settings. For the HTML it caches it rewrites the cache headers to make it cache for a year (just locally). When it is sent to the browser it puts the original headers back. My script should edge-cache the HTML independently of any Cloudflare settings or the headers that are passed back to the browser.


Good to know.

It sounds like you set a really high Edge Cache time, but will purge it if it’s been modified?

How long will it really stay in that edge cache if the page hasn’t been modified?

And your worker will override any funky stuff I do with Page Rules and W3TC?


Yes, it is cached as long as possible and then when an update happens the cache is purged. As for how long it ACTUALLY stays in cache, that is going to depend on how frequently it is accessed and how busy the edge is. If it isn’t accessed for several days I’d bet it will get automatically aged out of the cache independently of the cache settings.

Think of the worker as a layer in front of everything else. The page rules and W3TC will still run on the requests that aren’t served from the worker cache.


Thanks. My last question…in two parts…

Is the Workers cache separate from the regular edge cache? Does the “Purge Everything” button clear the Workers cache?


Sort of. The cache itself is separate and resources in the worker cache are independent of the regular cache when accessing them (or accessing the regular cache) but the global “purge all” does also purge the worker caches.

If the worker edge cache doesn’t automatically purge for some reason (like you changed a file manually on the server) then a purge all through the UI will also clear the worker cache.


a quick thank you and some feedback.

I implemented this and the workers have shaved 2-3 seconds on avg and more in certain parts or the world.

A major breakthrough that seems to continue to get better and better.

It did seem to take a few days to “take” which I am not sure why. Upon implementation it took several days for the scores to drop and ever since have continued to get better and better.

Thanks @pmeenan


@pmeenan @sdayman or anyone else…

Do you see anything more on the site that could be pushed to the edge via workers?

Ideally it could be re-used for other sites on wordpress as well.

The Google Pagespeed is poor:

and the WPT is here:


It looks like Google Fonts are being used. You might benefit from switching to the combination worker that includes support for the Edge Cache, Accelerating Google Fonts and experimental support for proxying (and cache-extending) 3rd-party scripts.

It looks like the fontawesome css from the maxcdn cache might still be a bottleneck and the combined worker doesn’t yet support re-writing 3rd-party css (because it needs to rewrite URLs within the CSS as well) but it’s on my list of things to look at.

Looking at the response headers for the HTML, I don’t see any of the edge-cache headers. Was it enabled? (clicking on the first request in the filmstrip view here). I usually spend most of my time working on speed in the filmstrip view to see what requests are likely blocking the content rendering.

It might be worth experimenting with Rocket Loader on and off. My guess is that it becomes a tradeoff between rendering performance and TTI but if TTI improves and rendering performance doesn’t get much worse it may be worth turning it off (if rendering performance gets a lot worse then I wouldn’t recommend it).


Tried to turn off RocketLoader but cost a few seconds on page rendering…

Also added the Combination Worker.
Thanks @pmeenan (not sure why it was not showing up as it was added and is added again…:thinking: )


It’s looking better now (in WebPageTest anyway).

The field data for the Page Speed Insights report will take a month or two to catch up (it is based on the Chrome User Experience Report). I’m not sure why the Lighthouse report on the Page Speed page doesn’t look much better for times yet.

FWIW, I’m seeing a “42” speed score from Lighthouse when testing on real devices.

The biggest issues right now look like tradeoffs between render, content and TTI. Rocket Loader and the YouTube player look like they are both pushing out the TTI. If you enable Mirage you can lazy-load the images which will help with some of the “suggestions” from Lighthouse.

There’s still a little bit of room for the worker to help with loading the fontawesome css and fonts faster but it’s not going to be a huge improvement, just incremental.


Perhaps your page could benefit from preloading and preconnecting hints.

You can test preloading by enabling “Server Push” on your wp-config.php file, following these instructions. It makes the locally served resources required by the HTML (CSS, JS etc) to be pushed out to the browser, instead of waiting for each request.

You can use a plugin such as Pre Party to preconnect to third-party services. You have to be careful not to overdo it. Just preconnect with a few basic domains that are certain to be requested at every page. Then test (with and without preconnecting) using mobile profiles. The plugin can only add resources to all pages, but in contact with the developer he told me he’s preparing an update that will allow for page-level customization.

You may want to consider adding preconnect to these domains: (if you always have video on your pages) (if you use pixel, remarketing)

I’m testing now preconnecting to these services for a static website with Google ads: (requested if you use GA remarketing or Adsense)

The ads themselves add a lot of other connections, but since we can’t know in advance which ads will run on each page, there’s very little to be done about them.

Adding preload and preconnect shaved 0.7 to 0.9 seconds (in a few cases over 1 sec) of my WP website loading time. These changes didn’t earn points with GTMetrix or WPT, thouh. Only the points that matter, in seconds! :sunglasses:

I’m not a developer and I don’t use Workers, but perhaps Workers could help with that somehow.