Wordpress sites slow, looking for different solutions to the problen
I have several sites on Bluehost, all running Wordpress with Divi theme. They are all painfully slow. Bluehost says to go to GTMetrix and fix all the issues. I've tried, using plugins on some sites and using code on others. (EG: used the attached code to defer parsing of javascript on techgardens.com/optical-en
I have a web developer who says he can fix the issues permanently, but we'd probably need to keep him around. I think this is the way to go, but i'm looking for other solutions to provide as options to the CEO.
Are there web hosts who are wordpress-specific, who provide support on cleaning up wordpress specific problems like the ones listed above?
Any other potential solutions you can see? Thanks, all.
code-html.html
I have a web developer who says he can fix the issues permanently, but we'd probably need to keep him around. I think this is the way to go, but i'm looking for other solutions to provide as options to the CEO.
Are there web hosts who are wordpress-specific, who provide support on cleaning up wordpress specific problems like the ones listed above?
Any other potential solutions you can see? Thanks, all.
code-html.html
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
You will gain more information using a browser debugger and looking at the network tab to see what may be the cause of the slow-down. This kind of thing is really hard to diagnose in this kind of question, but start by looking at how the browser interacts with the web server and look at what is causing the delays. From there you can start to focus on problem areas.
To answer the question about Wordpress hosts - yes, I am sure they exist.
As to curing the problem, people often just "throw hardware" at it until it goes away. Sometimes, this makes sense but other times it pays to find the root cause of the issue and often it is relatively straightforward if you work in a structured fashion.
To answer the question about Wordpress hosts - yes, I am sure they exist.
As to curing the problem, people often just "throw hardware" at it until it goes away. Sometimes, this makes sense but other times it pays to find the root cause of the issue and often it is relatively straightforward if you work in a structured fashion.
Agreed that you need to take a look at how a browser is actually parsing the page. You can use the developer tools in Chrome or FireFox for an easy way to do this. Use the 'Network' tab and take a look at what is taking time to load and also see if there are any errors. Look especially for timeouts accessing things like 'favicon' files or any SSL chain problems will also slow things down.
Bluehost is a very good host for WP sites, so it seems unlikely your problem is with hosting. I use siteground, personally, but I don't think your host is the problem.
As another test, can you load a different theme on your site without losing too much functionality? Perhaps on a 'staging' site so you don't disrupt the live site? If you notice dramatic differences in load times, then it's something screwy with your theme.
Any chance you can provide a url so I can take a look at load times on my system and see if I notice anything glaringly obvious?
Bluehost is a very good host for WP sites, so it seems unlikely your problem is with hosting. I use siteground, personally, but I don't think your host is the problem.
As another test, can you load a different theme on your site without losing too much functionality? Perhaps on a 'staging' site so you don't disrupt the live site? If you notice dramatic differences in load times, then it's something screwy with your theme.
Any chance you can provide a url so I can take a look at load times on my system and see if I notice anything glaringly obvious?
Ok, just had a second to take a quick look, I'll take a more detailed look later today. But, 2 things stand out right away for me:
First of all, your site loads in 6.21s-8.4s for me. However, nearly 82% of the total time was spent on initial loading and waiting for a response. The total time-to-first-byte (TTFB) was over 4s. This means that after DNS lookup is completed (which was pretty fast), my browser was waiting on your server to start sending data. Seems that you are loading a lot of javascript. I know your plugins are minifying that and caching it, but are you loading any javascript from external sites? Have you considered using a CDN in that case? Your graphics don't seem too bad. One of your plugins (product-enquiry-pro) is choosing to load FontAwesome locally instead of via their CDN which is taking nearly 2 seconds for your webserver to process, so you may want to check that plugin.
What are your server specs? Running near max RAM? What PHP version are you using?
I also noticed that 1.js from cdn.ywxi.net is also taking 1s to load and is timing out with a NDX (domain not resolved). This particular domain is linked to McAfee and also used by some content accelerators. Are you using a McAfee secure seal? If not, are you content accelerators using this cdn link for some reason (you may have to disable them one by one to see if one of them is the culprit). If so, disable both of these things and see if your site loading times improve. Not all caching plugins actually speed up your site... unfortunately.
Like I said, just a quick look to get started. Let me know if you have any feedback and I'll take a more in-depth look later to see if I can come up with any more ideas for you.
First of all, your site loads in 6.21s-8.4s for me. However, nearly 82% of the total time was spent on initial loading and waiting for a response. The total time-to-first-byte (TTFB) was over 4s. This means that after DNS lookup is completed (which was pretty fast), my browser was waiting on your server to start sending data. Seems that you are loading a lot of javascript. I know your plugins are minifying that and caching it, but are you loading any javascript from external sites? Have you considered using a CDN in that case? Your graphics don't seem too bad. One of your plugins (product-enquiry-pro) is choosing to load FontAwesome locally instead of via their CDN which is taking nearly 2 seconds for your webserver to process, so you may want to check that plugin.
What are your server specs? Running near max RAM? What PHP version are you using?
I also noticed that 1.js from cdn.ywxi.net is also taking 1s to load and is timing out with a NDX (domain not resolved). This particular domain is linked to McAfee and also used by some content accelerators. Are you using a McAfee secure seal? If not, are you content accelerators using this cdn link for some reason (you may have to disable them one by one to see if one of them is the culprit). If so, disable both of these things and see if your site loading times improve. Not all caching plugins actually speed up your site... unfortunately.
Like I said, just a quick look to get started. Let me know if you have any feedback and I'll take a more in-depth look later to see if I can come up with any more ideas for you.
WPT test suggest your site is tooled well + primary problem is your hosting.
How you resolve your hosting will be determined by site revenue.
If your site generates massive cashflow, then you'll have more options than a low cash flow site.
Check out InMotion, A2, Kinsta.
Or if you're tech savvy, lease iron (dedicated servers) from OVH or SoYouStart.
How you resolve your hosting will be determined by site revenue.
If your site generates massive cashflow, then you'll have more options than a low cash flow site.
Check out InMotion, A2, Kinsta.
Or if you're tech savvy, lease iron (dedicated servers) from OVH or SoYouStart.
Had another look at your site. I'm still a little concerned about that 1.js file loading from the NDX domain, so I'd look into that to save 1-2s of loading time. There's not much you can do about the plugin choosing to load FontAwesome locally since I'm assuming you didn't write the plugin. So I wouldn't worry about that.
I'm tending to agree with David that you may want to look at the server. The TTFB number is the big concern in your loading times and usually points to an overloaded or incorrectly configured server. I'm surprised since Bluehost has a good WordPress reputation. However, that does depend on the hosting plan you are signed up for. Their lower tier plans (not the optimized plans) seem quite underpowered and they do not mention what version of PHP they are using. It could still be version 5 instead of 7 which is very very very much slower. In addition, it seems that the RAM on those shared machines is dynamically allocated instead of being permanently allocated so that will cause a slowdown too.
I'd probably look at your hosting plan and, after talking with Bluehost, weigh out whether or not you can bump up to a plan with a little more RAM and little more horsepower (CPU) in general. I think that would be the best bang for your buck in terms of bumping performance since everything else seems to be, on the surface, pretty well configured and optimized. Remember though, you don't have to go overboard, you probably just need to step up one tier. I'm not sure how busy your site is or what it's being used for exactly, but I would think that something like a dedicated virtual server would be overkill unless you are getting thousands of visitors per month. I'd suggest stepping up one tier for a month and seeing how that goes then assessing from there.
I hope that helps!
I'm tending to agree with David that you may want to look at the server. The TTFB number is the big concern in your loading times and usually points to an overloaded or incorrectly configured server. I'm surprised since Bluehost has a good WordPress reputation. However, that does depend on the hosting plan you are signed up for. Their lower tier plans (not the optimized plans) seem quite underpowered and they do not mention what version of PHP they are using. It could still be version 5 instead of 7 which is very very very much slower. In addition, it seems that the RAM on those shared machines is dynamically allocated instead of being permanently allocated so that will cause a slowdown too.
I'd probably look at your hosting plan and, after talking with Bluehost, weigh out whether or not you can bump up to a plan with a little more RAM and little more horsepower (CPU) in general. I think that would be the best bang for your buck in terms of bumping performance since everything else seems to be, on the surface, pretty well configured and optimized. Remember though, you don't have to go overboard, you probably just need to step up one tier. I'm not sure how busy your site is or what it's being used for exactly, but I would think that something like a dedicated virtual server would be overkill unless you are getting thousands of visitors per month. I'd suggest stepping up one tier for a month and seeing how that goes then assessing from there.
I hope that helps!
Also your TTFB varies wildly, which is a sure indicator your site speed is dependent on amount of machine resources being taken up at any given time slice by other sites or VM/VPS instances on your machine.
This suggests your hosting company, WebSiteWelcome, has to many sites on your machine... or...
Misunderstands how to tune LAMP Stacks for easy coexistence of many sites on one machine.
Likely changing hosting is your only hope.
Some good options on fixing this are listed above.
@Asif, Bluehost + HostGator used to be excellent hosting. Usually better than most managed hosting. Then EIG bought them both. Fired all the excellent support staff. Replaced support with EIG support, which seem to have near zero experience. Since the EIG purchase both companies no longer provide acceptable hosting.
Which brings up another point. Before you choose hosting, check to see if EIG owns the company + avoid all EIG properties.
This suggests your hosting company, WebSiteWelcome, has to many sites on your machine... or...
Misunderstands how to tune LAMP Stacks for easy coexistence of many sites on one machine.
Likely changing hosting is your only hope.
Some good options on fixing this are listed above.
@Asif, Bluehost + HostGator used to be excellent hosting. Usually better than most managed hosting. Then EIG bought them both. Fired all the excellent support staff. Replaced support with EIG support, which seem to have near zero experience. Since the EIG purchase both companies no longer provide acceptable hosting.
Which brings up another point. Before you choose hosting, check to see if EIG owns the company + avoid all EIG properties.
Wow, you are all great! TO answer some questions:
1. We ensured before we transferred from Godaddy that we'd be on php 7.0, and I just confirmed that.
2. Our hosting package is cloud business
3. We do use a McAfee Seal. If I go to https://cdn.ywxi.net/js/1.js directly, it loads instantly. What's up with that? Does that mean the server is taking 1 second to serve it up?
4. Shared server so not sure about the specs. But every now and then the sites all go down, and when I check with them and ask them to check the server, there does always seem to be a problem they are fixing.
Thanks for all the information, I'll close this question after doing some research based on what you've told me, Everyone gets points!
1. We ensured before we transferred from Godaddy that we'd be on php 7.0, and I just confirmed that.
2. Our hosting package is cloud business
3. We do use a McAfee Seal. If I go to https://cdn.ywxi.net/js/1.js directly, it loads instantly. What's up with that? Does that mean the server is taking 1 second to serve it up?
4. Shared server so not sure about the specs. But every now and then the sites all go down, and when I check with them and ask them to check the server, there does always seem to be a problem they are fixing.
Thanks for all the information, I'll close this question after doing some research based on what you've told me, Everyone gets points!
I'm glad you got this narrowed down and best of luck in your search! I've been using Siteground for a while now for all my shared-hosted sites and they have been pretty great.
@David I had no idea Bluehost got bought out, that's good to know so I don't accidentally recommend them to any of my clients, thank you for the heads up!!!
@David I had no idea Bluehost got bought out, that's good to know so I don't accidentally recommend them to any of my clients, thank you for the heads up!!!
1. We ensured before we transferred from Godaddy that we'd be on php 7.0, and I just confirmed that.
Bad idea, as PHP-7.0 hits EOL (end of life, so no service) in around 10 weeks.
Best to upgrade to PHP-7.2 or PHP-7.3 (will GA any day now).
2. Our hosting package is cloud business
This may or may not be useful as Cloud/VPS == Slow because all Cloud tech, I've seen to date, is built on heavy VM technology.
Anytime you involve a heavy VM in anything you're site(s) will slow down to a crawl.
Better to run iron (bare metal, dedicated server) for speed.
3. We do use a McAfee Seal. If I go to https://cdn.ywxi.net/js/1.js directly, it loads instantly. What's up with that? Does that mean the server is taking 1 second to serve it up?
The link you mention has nothing to do with your site speed because your site is running HTTP2, so this .js file loads in parallel with all other assets.
4. Shared server so not sure about the specs. But every now and then the sites all go down, and when I check with them and ask them to check the server, there does always seem to be a problem they are fixing.
Only way to fix this is using a bare metal server or smart managed WordPress hosting company that uses bare servers, which are well tuned.
All the WebPageTest test runs I've done, all point to your hosting as the speed problem.
Your site is fairly well tooled, so nothing you can really do about your speed, so long as you're using your current hosting.
Bad idea, as PHP-7.0 hits EOL (end of life, so no service) in around 10 weeks.
Best to upgrade to PHP-7.2 or PHP-7.3 (will GA any day now).
2. Our hosting package is cloud business
This may or may not be useful as Cloud/VPS == Slow because all Cloud tech, I've seen to date, is built on heavy VM technology.
Anytime you involve a heavy VM in anything you're site(s) will slow down to a crawl.
Better to run iron (bare metal, dedicated server) for speed.
3. We do use a McAfee Seal. If I go to https://cdn.ywxi.net/js/1.js directly, it loads instantly. What's up with that? Does that mean the server is taking 1 second to serve it up?
The link you mention has nothing to do with your site speed because your site is running HTTP2, so this .js file loads in parallel with all other assets.
4. Shared server so not sure about the specs. But every now and then the sites all go down, and when I check with them and ask them to check the server, there does always seem to be a problem they are fixing.
Only way to fix this is using a bare metal server or smart managed WordPress hosting company that uses bare servers, which are well tuned.
All the WebPageTest test runs I've done, all point to your hosting as the speed problem.
Your site is fairly well tooled, so nothing you can really do about your speed, so long as you're using your current hosting.
Really need to know the traffic currently and expected on your site. If you're serving thousands of people daily then sure, look into a bare-metal setup or dedicated VM. But, that can be quite an investment. For most sites with medium traffic loads, I have to disagree, a GOOD shared hosting plan can work quite well for you. I suspect that you are not on a well-managed (as David very aptly put it) shared hosting plan. I'm not disagreeing with what David said, actually I agree with most everything, but dedicated hosting is something you really have to weigh the costs of. I've always seen $100+/month as a lowest-tier rate. If you can afford that, then go for it :-)
Took another look at your site and seems that call to McAfee isn't taking as long to time out now. When I first looked, yes it loaded in parallel but took so long that it was still loading after everything else which is why I mentioned it. So yes, I very much agree it comes down to your hosting.
In the meantime, have you tried a CDN to see if you can offload some of the burdens from your current server? Maybe Cloudflare since they are free? Might give you the speed boost you need to bring things to an acceptable level despite your current setup and while you weigh your options. Changes in the overall loading time might give you some insights also. Just a thought.
Took another look at your site and seems that call to McAfee isn't taking as long to time out now. When I first looked, yes it loaded in parallel but took so long that it was still loading after everything else which is why I mentioned it. So yes, I very much agree it comes down to your hosting.
In the meantime, have you tried a CDN to see if you can offload some of the burdens from your current server? Maybe Cloudflare since they are free? Might give you the speed boost you need to bring things to an acceptable level despite your current setup and while you weigh your options. Changes in the overall loading time might give you some insights also. Just a thought.
Thanks, Asif, I will find out for sure tomorrow, but I'm sure thousands of people daily is way out there, more likely hundreds. Thanks for your input!!
Actually, I have to admit, I don't even know how to offload traffic to a CDN, but I'll research it now. :)
Check out Cloudflare. You can google "cloudflare tutorial" or use the getting started links on their website. Plus, they have a wizard when you sign up. It's really easy and lets you cache javascript, CSS, etc. on their servers and they'll serve it for you. They are not the fastest CDN out there on the free plan, but it might be just enough to help you out for now.
If you need more help than the wizard or online tutorial, let me know and I'll walk you through it.
If you need more help than the wizard or online tutorial, let me know and I'll walk you through it.
Asif, David has talked to me as well about using the Divi theme. His opinion is, it takes so many resources that it will eventually take your site down, if your traffic gets high enough. Sounds right to me, but would love to hear your opinion as well?
You must be very careful with CloudFlare too.
You can't just setup CF + expect it to work. Usually CF destroys sites, because many times CF gets confused + starts hitting site for every request, rather than caching requests + also does this from 2x or more CF instances.
If you use CF, you best test it continually with an uptime + continuous speed tester + be ready to remove CF when ever it takes down your site.
CF will only slow down well tuned LAMP Stacks running well tooled sites.
CF will sometimes help, with poorly tuned LAMP Stacks or poorly tooled sites.
No CDN or proxy can fix this type of problem in the long run. Better... to identify + fix real problems, rather than adding layers of tech.
At least, that's been my experience.
You can't just setup CF + expect it to work. Usually CF destroys sites, because many times CF gets confused + starts hitting site for every request, rather than caching requests + also does this from 2x or more CF instances.
If you use CF, you best test it continually with an uptime + continuous speed tester + be ready to remove CF when ever it takes down your site.
CF will only slow down well tuned LAMP Stacks running well tooled sites.
CF will sometimes help, with poorly tuned LAMP Stacks or poorly tooled sites.
No CDN or proxy can fix this type of problem in the long run. Better... to identify + fix real problems, rather than adding layers of tech.
At least, that's been my experience.
On that I totally defer to David, he seems more knowledgeable than I. Personally, I haven't used the Divi theme very much, so I have limited experience. Based on what I know of it though, I'd totally agree that it is very resource heavy and relies on a lot of scripting which has to be processed by your server at some point.
Again, I think this all comes down to the actual and near-future expected traffic your server is facing. If you can step to a CDN to handle *some* elements (especially static elements) and a moderately beefed-up plan for now and evaluate your needs going forward to budget for dedicated hosting, it saves money. If you have the budget to go for dedicated hosting right away, then I'd definitely do that instead and save yourself the trouble of worrying about capacity issues.
Sorry, I'm on my phone so this is a little terse...
Again, I think this all comes down to the actual and near-future expected traffic your server is facing. If you can step to a CDN to handle *some* elements (especially static elements) and a moderately beefed-up plan for now and evaluate your needs going forward to budget for dedicated hosting, it saves money. If you have the budget to go for dedicated hosting right away, then I'd definitely do that instead and save yourself the trouble of worrying about capacity issues.
Sorry, I'm on my phone so this is a little terse...
David, I guess we were commenting at the same time... didn't see your post.
I completely agree with you about CF presenting some problems. Also, it does not speed things up in all cases and can break some things, involving tweaking to get it working. I have not, personally, experienced it taking down any of my sites in the past but, I defer to you since it seems like you have more experience in this area.
I only suggest CF for a few reasons:
My main focus in suggesting a pause before jumping to dedicated hosting is because I don't know what your budget situation is, Mel. I'm used to working with small/medium businesses where budgets are tight and extracting money for IT can be tough. So I'm biased but, again, I don't know your situation here or even if you have final say on that decision. My advice is still in-line with David if you have the cash :-)
I completely agree with you about CF presenting some problems. Also, it does not speed things up in all cases and can break some things, involving tweaking to get it working. I have not, personally, experienced it taking down any of my sites in the past but, I defer to you since it seems like you have more experience in this area.
I only suggest CF for a few reasons:
- It's free to try
- Based on it's caching, you might see more clearly exactly what is hitting your server hardest and be able to substitute scripts/plugins
- It can be pretty easily reverted if it causes problems or doesn't help (just avoid any HSTS or CF-linked SSL settings) though it could take 24-hours for DNS changeover
My main focus in suggesting a pause before jumping to dedicated hosting is because I don't know what your budget situation is, Mel. I'm used to working with small/medium businesses where budgets are tight and extracting money for IT can be tough. So I'm biased but, again, I don't know your situation here or even if you have final say on that decision. My advice is still in-line with David if you have the cash :-)
You are both a huge help in my work to provide some working solutions to my client. Thanks a million. I'll come back with some numbers of daily visits tomorrow.
Hi, traffic is small, only 500-1000 visits a month per site. I'll definitely look into siteground, I've seen them recommended elsewhere. I will need to take time to look through all of the invaluable information on this thread, thanks gain so much.
Interesting: regarding PHP, Bluehost only offers:
PHP 5.4
PHP 5.4 (Single php.ini)
PHP 5.6
PHP 5.6 (Single php.ini)
PHP 5.6 (FastCGI)
PHP 7.0 [Beta, check site functionality for compatibility after enabling]
All files with the extension .php will be handled by the PHP 7.0 engine.
Latest version of PHP.
PHP 7.0 (Single php.ini) [Beta, check site functionality for compatibility after enabling]
PHP 7.0 (FastCGI) [Beta, check site functionality for compatibility after enabling]
All files with the extension .php will be handled by PHP 7.0 FastCGI processes.
FastCGI for PHP makes all your PHP applications run through mod_fastcgi instead of mod_suphp. This eliminates the overhead of loading the PHP interpreter on every hit. Since it is always in memory ready for the next hit, the responses will be generated faster.
PHP 5.4
PHP 5.4 (Single php.ini)
PHP 5.6
PHP 5.6 (Single php.ini)
PHP 5.6 (FastCGI)
PHP 7.0 [Beta, check site functionality for compatibility after enabling]
All files with the extension .php will be handled by the PHP 7.0 engine.
Latest version of PHP.
PHP 7.0 (Single php.ini) [Beta, check site functionality for compatibility after enabling]
PHP 7.0 (FastCGI) [Beta, check site functionality for compatibility after enabling]
All files with the extension .php will be handled by PHP 7.0 FastCGI processes.
FastCGI for PHP makes all your PHP applications run through mod_fastcgi instead of mod_suphp. This eliminates the overhead of loading the PHP interpreter on every hit. Since it is always in memory ready for the next hit, the responses will be generated faster.
This is fairly typical of most hosting companies... They tend to be way far behind the curve of sensible software versions to run.
Since PHP-5.6 + PHP-7.0 EOL in roughly 10 weeks now, this means no more security fixes, so first time either of these versions becomes hackable, there will be no fix + sites running these versions will be permanently hackable.
To me, this type of nonsense is unacceptable.
Since PHP-5.6 + PHP-7.0 EOL in roughly 10 weeks now, this means no more security fixes, so first time either of these versions becomes hackable, there will be no fix + sites running these versions will be permanently hackable.
To me, this type of nonsense is unacceptable.
With that amount of traffic, I personally don't think the extra cost of a dedicated server is worth it. My mid-tier plan with Sitegound can easily handle that load. I checked to be sure, Siteground supports PHP7.2 but defaults to 7.0. I would give them a call or check out some other good shared hosting providers that can give you a plan that actually fits your needs. I know when I first switched to Siteground, they gave me a 30-day money-back guarantee. So I could leave my existing site where it was, migrate a 'staged' site to their servers before doing any DNS hanky-panky and try them out. If it didn't like it, they would refund me the one-year prepaid hosting fees (like $65USD). Plus, their support is actually knowledgeable and can get you set up very quickly and correctly if you're not comfortable setting things up yourself.
Anyways, just something to think about.
Anyways, just something to think about.
Do you know which version of PHP your site is actually running on? Even though newer versions are available, the default might be v5.4 which is really slow. If they use cPanel there may be a "Select PHP Version" tool you can use, or otherwise some equivalent.
This has been a learning curve. I want to thank everyone who helped out for your knowledge, experience and patience!
Premium Content
You need an Expert Office subscription to comment.Start Free Trial