Here is my GTMetrix scores. There is a 301 issue at the top.
Here is my GTMetrix scores. There is a 301 issue at the top.
This redirect took too long, but it was performed by WordPress, not by Cloudflare.
You can make Cloudflare perform this kind of redirect by enabling Always Use HTTPS, which can be done at the dashboard (SSL/TLS > Edge Certificates > Always Use HTTPS).
Then you should always test using the canonical URL (with https://) so that the test reflect the time it will take for most of your visitors to get to your page, as they will likely click on a link (Google, social networks etc) previously formatted with the https prefix.
Also changed this setting to ON: Automatic HTTPS Rewrites
Is that correct?
My backend is really really slow. Is there anything on Cloudflare’s side that can speed that up?
That’s clearly a hosting issue. Don’t be afraid to switch hosts for better performance. If you’re selling product, it’s worth paying for quality Managed WordPress hosting.
Bluehost is telling me Cloudflare is the host now because the name servers are pointing there and referring me to you to fix this issue.
I’ve been on with them for a while now.
So you can stop paying them then?
Sorry couldnt resist
That’s woefully ignorant of them.
How much traffic does your site get?
I just built the website in the last month so it is building. But of course when the site is this slow the stats go way down.
And I agree that it is silly to tell me that Bluehost is no longer the host. Since all my cPanel stuff, etc is there.
So what you’re telling me, though, is there is no way that speedy Cloudflare can’t speed up this backend??
This is Audrey, by the way–I’m supporting Helen on her site.
Whoa. I’m at 60 hits today (aka growing). Probably because between Bluehost and your suggestion on Cloudflare, the front side is faster.
Now I just need the backend. There has to be a way.
The backend is completely dependent upon the host (Cloudflare ).
But seriously, back end is all database calls and live updates. Only the server can speed that up through database, PHP optimization and just plain server speed.
And this will translate to a faster site overall because many of those calls also do the same work as the backend.
Alright. I’ll go back to them then. They sent me here. You send me there. I’m not savvy enough to know how to resolve this.
Looks like I do have Managed Wordpress Hosting. Sigh.
Managed WordPress hosting is awesome. Totally worth the money for a commerce site.
LearnDash mainly would deal with logged i wordpress users and as such Cloudflare caching usefulness would be limited to static assets and if you enable CF cache everything for guest dynamic HTML cache. But web site performance is only as good as it’s weakest link and server performance involves both front end (at CF edge + web server origin) and backend (origin server PHP/MySQL/cpu/ram/disk resources and tuning) optimisations.
As LearnDash is predominantly logged in user specific, then CF cache misses for dynamic HTML generated content for logged in users would hit your origin server. So your site performance would be only as good as your origin server/hosting performance.
See 2yr old blog post at https://pressidium.com/blog/2018/high-performance-hosting-for-wordpress-learndash/
Although LearnDash is a leading player, it is very resource-intensive. By nature, applications that need to dynamically render real-time personalized content such as an LMS (Learning Management System) will require content to be largely uncached and users to be logged in to the backend. LearnDash is no exception to this inherent problem.
In this post, we’ll see why there isn’t a lot that WordPress hosting providers can do, besides matching the CPU power that is needed for LearnDash to properly function, and how Pressidium addresses these general performance issues.
How is WordPress LearnDash resource intensive?
No matter if you have a low or high traffic e-learning site you will experience technical problems once you start placing demands on it. This might be through the number of registered users, the number of courses, number of simultaneously active users, or any combination of these. These problems can range from full hardware utilization and throttling, database write problems to users experiencing severe slow-downs, even interruptions during course time.
Database throttling and transaction conflicts
LearnDash executes some long sets of SQL queries. For example, if you have a large number of users, say 20,000, LearnDash will fetch all of them even if you just want to select one profile to edit.
Basic server clustering solutions are also of little help in this case. Almost every action performed in LearnDash updates the database. When the server cluster that is serving your LearnDash e-learning site is under heavy load, the cluster server nodes are constantly writing to the database. This can lead to transaction conflicts .
In high-traffic situations, these can often result in database table locks, or a full database-lock, disallowing write access to everyone. This of course, is disastrous.
Peak CPU utilization
WordPress LearnDash by nature is a dynamic application that does not cooperate well with caching strategies. This is not LearnDash’s fault as we said in the beginning, but it does mean that you can’t simply accelerate its performance, just by caching HTTP responses.
This is so because there are logged-in users, that are in the middle of multiple-choice tests, with timers & content that needs to be uniquely rendered for them, and simply there is very little that can be cached.
So having almost all content uncached, means that each LearnDash user that is taking a test, will spawn at least, 1 backend PHP process. Imagine what will happen, if 50 users log-in nearly simultaneously!
In general, for a user to experience a smooth LearnDash session, they will need dedicated CPU resources. However, CPU demand is not constant, as each user may spend some idle time online, while doing the test. If the total amount of the backend PHP processes waiting to be served is a multiple of your total CPU pool resources, and you don’t do something drastic to lessen the load (for example, shut down some of them), an avalanche will start and you will lose the entire server.
To sum up, simple VPS setups and WordPress hosting plans that are not Enterprise will only be able to handle a few dozen of logged-in users at best. In those cases where all of the users perform some action nearly simultaneously, you’ll hit a peak, and everything will start failing.
I haven’t used LearnDash myself but have been looking at learning management platforms for my own project/product usage and from my limited research all Wordpress based LMS systems would all have similar limitations due to logged in users not being able to leverage CF and other levels of caching that guest non-logged in users can. And fact is Wordpress performance without caching is pretty poor out of the box.
Quoting myself on some comments I made on my forums when I was discussing LMS options
Doing more research into LearnDash as it has 3rd party mobile app supporting products so you can use mobile app for users to take LearnDash courses too. But seems scalability of concurrent users seems kind of low between 75-150 users from tests at Hosting High Traffic LearnDash Sites and from comments in that blog article needs alot of cpu resources and some folks on higher end wordpress managed hosting managed 340+ concurrent users. I guess is comes down to scaling Wordpress itself for logged in.
It’s the kind of scalability challenge I like to dig my teeth into and see how much better I can make a Centmin Mod Wordpress install scale compared to other folks Guess part of the challenge will be testing how well Wordpress scales for logged in member versus guest full page caching
As to LMS systems, seems Moodle might be a better fit from reading on their hardware/performance forums, most folks are hitting road blocks at way higher user concurrency rates of 2,500 to 8,000 versus Wordpress LMS solutions which seem to hit same scaling road blocks at between 150-350 concurrent users. Plus Moodle has free self-hosted version too so I can start out and test/benchmark/scale optimise as I go without the monthly costs. Also Moodle seems to have more documentation/guide info for scaling Moodle including cluster/load balanced setups. So something for further down the track too
Basically if you’re using LearnDash, prepare to throw more server hardware at your hosting side when you have more concurrent logged in users.
This is incredibly helpful. Thank you. I appreciate your time in helping me resolve these issues in the new coronavirus context. I am hoping we’ll all be able to find a way forward to get these LMS systems running more smoothly on more systems.
I checked html of this page. This file - CF rocket loader is loaded 7 times. Other resource resource files have similar problem.
So the LCP problem is likely caused by the theme issue.
But I don’t understand the code for rocket loader is normally added by Cloudflare. Why are there so many instances?
More detailed recommendations,
Thanks for your thoughts.
I discovered that Sucuri was causing problems and slowing down Cloudflare so I disabled Sucuri.
I use WPRocket but I don’t know if that’s the same as CF rocket loader. It seems like there was an option for a rocket loader maybe on Cloudflare??
The name similarity is a coincidence. Cloudflare’s Rocket Loader is just for optimizing JS files. WP Rocket is a super nice caching plugin for WordPress…and does some JS optimization as well.
I generally leave Rocket Loader disabled, as HTTP/2 overcomes some of what Rocket Loader set out to do, and my sites do their own JS optimization.
That’s disappointing that Sucuri slowed things down. Wordfence can also protect your site for free and is worth a try. Hopefully it won’t slow your site down.
You can disable Rocket Loader as CF panel. See what happens.
WP Rocket is a Wordpress Cache Plugin to speed up page loading by converting dynamic page to static. Rocket Loader is a CloudFlare feature. You can disable it at Optimization section under Speed tab of your CF dashboard.
From the html codes, it seems the cache function of WP Rocket is not enabled. That’s why you receives “Reduce initial server response time” every time in page speed test. If the cache plugin is working, there’s normally the following words at the bottom of the html codes.
Furthermore, there’s conflict between WP Load and Jetpack in image LazyLoad. It appears lazyLoad is enabled by two plugins. And Jetpack wins. So need to disable one.
This topic was automatically closed after 30 days. New replies are no longer allowed.