[Resolved] Site is SOOO slow with your plugins enabled

[Author]

Posts

[mikeH-3]

I have been trying to fix this for months but I'm at my end. My client is very unhappy. I have this site hidden link that takes anywhere from 5-20 seconds to load TTFB, on average, when your plugins are enabled. It slows down loading every page on the site, not just homepage. It even slows down the backend. This server only has this 1 live site on it (with low traffic) on a digital ocean 1GB server, so that is not the issue. I've tried it on other web hosts as well and all have same result.

So, I cloned it to here hidden link and unpublished your plugins only. You can see it opens pretty fast. Under 1 second TTFB. Compare that to the live site at hidden link.

Please help. I will provide you login to see if you can find what is slowing my sites down so much.

[Christian Cox]

Hi, I'll be glad to take a look. Please provide login credentials for the staging site in the private reply fields here.

[Christian Cox]

Okay here are the results of my tests. Each grouping of active themes and plugins was tested using a 3-run test on webpagetest.org, and the result links are included below.

Types, Views, 2017 theme
Median TTFB: 2.8s
hidden link

Types, Views, Mychurchwebsite theme
Median TTFB: 1.327s
hidden link

All Toolset, Mychurchwebsite theme
Median TTFB: 1.752s
hidden link

All Toolset, Mychurchwebsite theme, Other plugins A - E
Median TTFB: 3.628s
hidden link

All Toolset, Mychurchwebsite theme, Other plugins A - M
Median TTFB: 4.201s
hidden link

All Toolset, Mychurchwebsite theme, Other plugins A - S
Median TTFB: 4.662s
hidden link

All Toolset, Mychurchwebsite theme, All Other plugins (all those that were originally active)
Median TTFB: 5.370s
hidden link

My comments:
1. Types and Views with your theme is actually quite fast - faster than Types and Views with 2017. As other plugins are activated, you can see the TTFB performance takes incremental hits. This is to be expected to some degree, because more plugins means more code execution. The biggest jump I see is in activating plugins A - E in alphabetical order, which produced a jump around 2 seconds in loading time. You could try to run some more pointed tests to see if there is one plugin causing the majority of that difference, and consider switching to another plugin. Or if it's critical, we may be able to collaborate with their developers on a compatibility fix.

2. The tests didn't come close to a 20 second TTFB reproduced in any scenario. However, I was able to reproduce longer TTFB times by manually loading the site in the browser with multiple concurrent tabs open and loading. However, you can see from the tests that there are times when the site performs much much faster. The code and content of your site isn't changing enough between tests to justify that kind of time difference between our results. So I'm not sure how to explain those differences. Check with your hosting company to see if they have object caching, varnish, memcache, redis, or any server-side caching system in place. If so, see if they will disable it temporarily and test again. It's counterintuitive, but if there is a conflict between Toolset and their caching system it will actually speed up performance.

3. Consider adding a third-party WordPress caching plugin. WP caching plugins, unlike the server-side caching systems I mentioned before, typically work by creating static HTML files and serving those up instead of making expensive queries for each request. This can be really helpful on pages where you have lots of nested Views and templates, and sites with lots of plugins. Custom search results performance isn't usually improved, though.

4. If you want to pinpoint slow DB queries, consider a plugin like Query Monitor. If any single Toolset DB query is taking longer than 0.5ms consistently, we can investigate in more detail.

Please let me know your thoughts and we can go from there.

[mikeH-3]

Thank you for your detailed feedback. It is very much appreciated! Somewhere there is a disconnect between what we are seeing. Let me show further:

All same plugins are running except TOOLSET.

Here is the load time with site NOT running your plugins, but every other plugin loaded: hidden link
Here is the load time with site running all plugins, PLUS your plugins (this is same exact everything, including server, but running toolset): hidden link

You'll see a 10 second difference. So there is something specifically and noticeably different between the 2 sites, because of TOOLSET.

It was a 5-20 second load time. NOT always 20 seconds. Usually somewhere between 8-12, which is WAY too long to have to wait for site to come up.

Caching is not option right now. It doesn't work well for what we need.

Knowing this info, can you dig any deeper to find what is causing this? It's causing the WHOLE site to be slow.

[mikeH-3]

ALso, I activated TYPES and it didnt seem to affect load time too much. So it has to be VIEWS, but don't know what.

[Christian Cox]

Somewhere there is a disconnect between what we are seeing.
I see a difference in test performance, but not necessarily a disconnect. That's why I asked about object caching, but I didn't get a clear response from you. Does your host have object caching, Memcache, Redis, Varnish, etc. enabled? If so, can they disable it temporarily so we can run additional tests?

Caching is not option right now. It doesn't work well for what we need.
Can you explain why not so I can consider that while looking for another solution?

Knowing this info, can you dig any deeper to find what is causing this?
Sure, I ran some tests with Query Monitor and saw these two slow queries flagged (screenshot attached). Both of the queries involve adding data to the wp_options table in the database. Do you have access to the database? Can you tell me the number of rows in this table, the total amount of data stored in this table, and any indexes applied to this table?

[mikeH-3]

There is no caching running on the server that I am taking advantage of, no. Varnish and memcache are availbale, but I have them turned off.

I want to get to the root of the problem as to why toolset is adding so much to the load time. Turning on caching is just a bandaid and when I have it on, my client gets upset because the changes he makes are not reflected in the site right away, especially when you do a future publish.

Thanks for running the query thing. These are the types of things I need help with that I have no idea how it works. I can send you the options database I have running on that site. How do I do that through there? THis is screenshot of the tables: hidden link

[Christian Cox]

A site clone created with Duplicator will be best, since it will include your site's database, theme and plugin files. I can install Duplicator Pro on the test site and get started if you approve of this plan. Otherwise, I'll need you to create a database dump file and backup your theme and plugin folders so I can download them all to my local environment. Let me know how you would like to proceed.

[mikeH-3]

Sure, that would be fine. Thanks much!

[Shane]

Hi Mike,

Christian is currently on a public holiday today but he will be back tomorrow to continue helping here.

Thanks,
Shane

[Christian Cox]

My local environment shows no slow queries related to Views, so I uploaded the site clone to a different environment you can access and test. Please add this entry to your computer's hosts file:

74.50.54.120  cts.christianc.host

Then you can log in to a clone of your site here:
hidden link

This clone has all the same plugins active and all the same content, but I did not include any of the wp-content/uploads directory (should not affect TTFB times). The server is running PHP 7.2.7. You can see that the site is very fast. A run of 9 tests on webpagetest.org produced a median TTFB of less than 1 second:
hidden link
Here's another run using PHP 7.1.17:
hidden link
Median TTFB of less than 1 second again.

Query Monitor also shows very fast results. On the homepage, the slowest query for Views is 0.0007 seconds. That's less than one millisecond - nothing at all like what is happening on your server.

Do you have a different environment available for testing, preferably with another hosting company? I will be glad to upload this site clone and run tests there as well because I'm unable to replicate the problem you are experiencing on your live and staging sites. Per our support policy https://toolset.com/toolset-support-policy/, our support team is unable to troubleshoot issues that are specific to your server environment and cannot be replicated on other environments.

If no other test environment is available, I have some further steps you can try to isolate the issue on your own:
- Ask your host to temporarily switch PHP versions for this site. I can see your live site was running PHP 7.2.8. See if you can downgrade temporarily to a lower version, something between 7.0 and 7.2. It's possible there is an issue with one component or extension installed with the 7.2.8 version of PHP, and that same problem will not occur on another version.
- Check the minimum server requirements at https://toolset.com/toolset-requirements/ and be sure your host's mbstring extension is enabled and the eval function is enabled.
- Analyze, defragment, and/or optimize your database tables (especially the wp-options table) using phpMyAdmin or another database inspection tool. You should create a backup of the database before running these processes.
- Fix all site warnings and errors. There is currently a PHP Deprecation notice logged on every page load:

Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; wpse104808_user_caps has a deprecated constructor in /path/to/wp-content/mu-plugins/hideadmin.php on line 3

There is also a JavaScript error on the homepage:

(index):11 Uncaught ReferenceError: gform is not defined

- Install a PHP info page on your site and compare against the one I have uploaded here as a reference: hidden link
We have information about creating a PHP info page here: https://toolset.com/toolset-requirements/

[mikeH-3]

Thanks for this email. I tried logging into /wp-admin on your server and I just get a blank page. It was a successful login though since my login info was correct. Can you fix that for me? Also, the homepage isn't loading any of the slideshow or anything below sermons... so it doesn't seem to be a true clone of the site. The pages on the site show nothing either below where it says [HTML5-BANNER width="1500" height="500" class="bannerdiv"]

Once you can fix this I can look and test.

Thanks! Mike

[Christian Cox]

Hmm, not sure what happened overnight but I have rebooted the test server and it seems to be working again. Can you please check now?

[mikeH-3]

Thanks, I can access the site now. Site is both fast and slow. Homepage took 11 seconds to open the first time. Now it is down to 1 second, which is good (when I go a second time). Secondary pages took anywhere from .5 to 4 seconds to open. Backend is really slow... 6 seconds for dashboard to open. I click on a custom post type, like sermons (in backend) and it took 4 seconds to load. Clicked on documents custom post type and it took 9 seconds to load. SO something is still going on. hidden link

[Christian Cox]

I spoke to my systems team and it turns out this test server was running low on disk space. I've cleaned up some of my test sites so it's running more smoothly now. Looks like the vast majority of those slow queries on the backend were caused by the Duplicator plugin I used to create the site clone. I have now disabled that plugin. Please navigate through the backend again. When you see slow page times, please click the Query Monitor status bar to open the QM panel and take a screenshot of the slow queries if any are found. If no specific slow queries are noted, switch to the Queries by Component tab in the QM panel and show me a screenshot of the longest-running plugins. Click the plugin name in the list and sort the queries by time so I can see a screenshot of the long-running queries. I'll try to replicate those findings myself and see what can be done.