TTFB is something page caching (WP Super Cache) should help with, but I have seen cases where due to networking routes. What certainly helps is page caching at the Cloudflare edge, using Cloudflare APO (paying, but not a lot) or WP Cloudflare Super Cache (as alternative to WP Super Cache), so maybe look at those solutions?
hope this helps,
frank
Thanks for the tip. I have set up the Cloudflare APO on my plantpages.co.uk site as a test (similar speed profile but less busy/important). I will monitor over the next 2 weeks for improvements, if so I will move ahead. I have kept WPSupercache set up but s=removed Bunny CDN – does that sound about right in terms of configuration?
Thanks
if on Cloudflare then bunny is not really needed any more, but not sure if having 2 page caches (WP Super Cache and APO) is useful?
Why would Cloudflare suggest they can stay on then?
Among the most popular caching and optimizations WordPress plugins are LiteSpeed Cache, W3 Total Cache, WP Rocket, WP Fastest Cache, WP Super Cache, Autoptimize. To successfully activate Advanced Platform Optimization when any of the plugins above already present, follow these steps:
Install and activate the Cloudflare WordPress plugin.
Enable Automatic Platform Optimization in the plugin.
Clear any server cache used via other plugins.
Verify that your origin starts serving the response header "cf-edge-cache: cache,platform=wordpress".
Activate plugins integration with Cloudflare
WP Rocket integrates with Cloudflare API.
WP Fastest Cache integrates with Cloudflare API.
W3 Total Cache integrates with Cloudflare API. Make sure to enable the Page Caching option.
3. Integration with Cloudflare cache purging
The rest of the plugins in the list, when producing content optimizations, require triggering of Cloudflare cache purging manually or via API:
LiteSpeed Cache
WP Super Cache
Autoptimize
Hapy to turn off WPSupercache, but wonder why that is not the recommendation from CF as WPSC doesn’t do anything else?
CF knows better then I do, do follow their lead 🙂
Thanks. I have implemented without the WP super cache but there appeared to be no difference in the page timings. There seems to be no preload option in Cloudflare APO. I also found this when researching online:
https://brianli.com/cloudflare-apo-for-wordpress-misconceptions/
`Cloudflare APO is not a replacement for page caching on the origin server. Nowadays, the majority of modern WordPress hosts have some kind of page caching configuration in place on the web server (Nginx, Litespeed, etc.). For example, Kinsta uses the FastCGI Nginx module for page caching. Since Cloudflare APO works on a layer above and external to the origin server, it’s still important to maximize origin server performance with local page caching.
For WordPress sites hosted on servers that aren’t configured for page caching, plugins like WP Rocket and W3 Total Cache are often used to replicate the server-level page caching functionality at the application level. If you’re using a plugin like WP Rocket or W3 Total Cache for page caching, make sure you keep it enabled even after enabling Cloudflare APO!
The reason for not disabling local page caching when using Cloudflare APO is simple. When APO is enabled, Cloudflare still has to make requests to your origin server in order to fill the Cloudflare Workers KV database or edge cache with your site’s HTML pages. Since page caching speeds up requests and reduces CPU and RAM load on the origin server, it’s important to keep page caching enabled.’
Not seeing huge gains either way, but maybe I have to leave it alone and check the performance in a week or so…
There are times when I see lighthouse return a 6 second ‘waiting for server to respond’ and others I get almost 100/100 for mobile and desktop…
that “cloudflare-apo-for-wordpress-misconceptions” is an interesting read 🙂
typically when a page is not in Cloudflares cache, CF will have to request it from your site. if your site is slow to respond (because no page cache OR because the page is in cache but has expired), it will take longer for the page to be returned to the visitor. in that sense having page caching on your own server indeed does make sense, but you’ll also have to make sure the local page cache does not expire too soon.
but when looking at your site now, it seems APO is not active any more (there is no info on APO in the HTTP response header for the HTML) and I see HTTP response header which is likely to impact APO’s advantages;
cache-control: max-age=3, must-revalidate
that is from a WP Super Cache addition to your .htaccess file, you might want to remove or tweak this. once done it will allow APO to cache for more then 3 seconds and it will very likely improve perf. 🙂
Hi
thanks for your thoughts, really useful. I am not seeing the cache control issue in dev tools (when the disable cache is unchecked – it appears with it checked). I can’t see anything in the htaccess file that would cause this issue.
I do get a ‘tcache’ in the ‘cf-apo-via’ instead of just ‘cache’ and it is sometimes missing this message:
cf-edge-cache: cache,platform=wordpress
I was wondering about preloading CF APO as well as the site has many pages but some are only visited rarely… If I could do this do you think it would be worth it or is that not how CF APO works?
Thanks
weird, as I don’t see APO mentioned anywhere in the HTTP response header for the HTML?
Am I looking at the wrong site?
I did the plantpages.co.uk site as a test (mentioned earlier, but I assume you have hundreds of these threads going at any one time!)
indeed, many threads & mails and such.
had a look at plantpages and do see APO active there, but also see the cache-control: max-age=3, must-revalidate header which in turn results in APO throwing cf-cache-status: BYPASS and cf-apo-via: origin,no-cache both meaning something like “not cached on cloudflare but fetched from the origin server”.
Thanks for all your help – TTFB in GTMetrix is good worldwide now, so I will have to sit and be patient for UX report to catch up…
View post on imgur.com
Will let you know…
