This issue might have something to do with domains on Cloudflare. I initially disabled the Cloudflare Super Page Cache plugin that I use and things improved briefly (so I submitted a ticket to that developer) but then it all continued to lag as above.
Then I noticed that turning developer mode on in Cloudflare (which disables all caching) seemed to fix it, albeit at the cost of no caching.
So now I’ve set up a cache rule in all domains to not cache anything. That gets around the 20 second delays and leaves me with the standard WordPress performance.
But it is entirely a result of the WP6.8 upgrade, as my test system still on 6.7.2 is working fine.
Just leaving there here for anyone with the same issue.
Rob
-
This reply was modified 9 months, 3 weeks ago by
robaxxx.
FWIW, WP is not involved with the server’s handling of specific files that actually reside on the server. It would not be directly responsible for long response times of such files. To be clear, I’m not saying that the update would not be indirectly responsible. For example, an increase in response time could be due to more supporting file references on a page, consuming all available server connections and resulting in longer responses. Only an example, I don’t know the true cause.
Have you tried an optimization plugin that combines multiple .css and .js files into one or two? This could dramatically decrease the number of individual requests necessary for a particular page. Many caching plugins have this option available. Despite you having trouble with caching, it might be feasible to disable caching, yet leave optimization in place. There are also a few plugins that optimize without any caching, for example Page Optimize or Autoptimize.
Thanks for the reply.
There’s no optimisation that will cure this issue other than fixing whatever WP 6.8 feature or bug has caused it. I’ve been building and hosting websites for 25 years now and am well familiar with these details.
This is entirely a result of the 6.8 upgrade. And most probably the new performance features e.g. Speculative Loading, and how they interact with Cloudflare domains.
Running many years of the previous releases and also testing a backup of 6.7.2 don’t have the issue. And enabling Developer Mode or creating a cache bypass rule in Cloudflare stops the problem in 6.8. There are also 2 sites on the WP instance that have their DNS elsewhere, and those do not exhibit the issue.
So it’s either WP 6.8 or Cloudflare just happened to create a bug in their system at the same time. I need to hear from others who have DNS on Cloudflare.
I attempted a downgrade but that turned into a no-go due to the DB changes. I’m also not able to roll back due to ecommerce activity. I can carry on with CF cache disabled, or I move all DNS out of Cloudflare if this is never resolved. But it’s an obvious bug so someone else is bound to have it.
Thanks again
Rob
But wait! Theres more.
I fired up my 6.7.2 test instance to double check, and now that also has the problem. I may have had development mode enabled on it when I checked the other day, not sure.
So the situation at this point is:
DNS on Cloudflare all of a sudden causes these 20 second delays. It happened about the same time as the WP6.8 update, but isn’t related to that. It is also not related to the Cloudflare Super Cache plugin I use.
But it is definitely a change somewhere in the pipeline. The only thing that consistently resolves it is either to add a total cache bypass rule in Cloudflare, or enable development mode in Cloudflare, or have the DNS elsewhere and not on Cloudflare.
I’ll make a post over on Cloudflare and see what they say.
Rob
Hurrah, I’ve resolved the problem after going back through notes and after finding the first bullet point on this page.
The 20 second delay is actually a 19 second a Cloudflare timeout due to connections being rate-limited by RDP Guard, where I had just removed the Cloudflare IP’s from the whitelist. I had done that because I had found that it was also whitelisting bots that it detected – I was trying to reduce bot attacks that day and discovered this issue in the RDP Guard logs.
So, after putting the IP’s back in, the bots are back, but that’s far less of a problem than the 20 second page loads.
All good, closing this.
