Skip Navigation

[Resolved] slow website

This support ticket is created 6 years, 10 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

This topic contains 28 replies, has 3 voices.

Last updated by Christian Cox 6 years, 10 months ago.

Assisted by: Christian Cox.

Author
Posts
#527596

Please let me know your thoughts on this analysis, thanks!

#527665

Hi Christian,
thank you for your detailed answer, I've tried to disinstall the Google Maps plugin in a copy of the website but the improvement wasn't very noticeable, it's true that the number of requests drops a lot (and so does the weight of the homepage), but this doesn't turn into a big leap in the performance.

I understand what you're telling me but the support team from Flywheel is still saying that these admin-ajax are the main culprit for the delay in this website. They wrote "The POST rate on the site is higher than the cache rate, and that's always going to have a direct negative impact on performance".

Actually I'm trying to erase some plugins to reduce the complexity of the website, we've already seen that this doesn't help to reduce the waiting time of the first request but at least we can scratch away one second. Anyway, with 23 active plugins it seems weird to me to have such a relevant delay...

Thanks,
Nicola

#527677

...it's true that the number of requests drops a lot (and so does the weight of the homepage), but this doesn't turn into a big leap in the performance.
Can you be a little more specific about what you mean by "performance"? What criteria are you referring to? For example, I've mentioned several criteria here, like the page's DOM Loaded event, time to first byte, Document Ready, etc. that have quantifiable values.

"The POST rate on the site is higher than the cache rate, and that's always going to have a direct negative impact on performance"
I'm not sure I completely understand what this means - server caching is a bit out of my skillset - but I'll be glad to investigate in a bit more depth. I don't know why there are 3 admin-ajax calls fired off immediately upon page load. That seems unusual to me. I will try to create a clone of your staging site so I can investigate further on a local environment where I can control things more effectively. I will update you when I have some more information.

#527685

After running some tests directly on your staging environment, I'm not seeing a major difference in major performance metrics when I disable Toolset plugins completely. Please see the attached screenshot, specifically the bottom row of each window. Note that the Finish metric doesn't mean anything here, since this number increases whenever one of the AJAX-loaded images finishes loading periodically in your Revolution Slider. DOMContentLoaded shows a difference of about 1.7 seconds, and Load difference is about the same at 1.7 seconds. I think this is within an acceptable range of differences, considering how much more content and functionality is included with Toolset.

Frankly, I'm not sure much can be done here. I won't be able to test the difference with and without Toolset against your normal server load because it would require disabling all Toolset plugins on your live site. However, I can try to run the waterfall tests again tomorrow during your peak server loads to see if I can observe any bottlenecks I have overlooked. I will update you tomorrow with any more information I find.

#527718

Thank you Christian, I really appreciate your help.
I've just eliminated the plugin Visual Composer (it was used only in 5 pages) but, unfortunately, the results are below my expectetions as I get, from Pingdom, nearly the same results I had before: 5 seconds for the home page and 4.5 for one of the inner pages. Consider that in Italy is night now, so I expect to see longer times tomorrow, during the peak hours.

With performance I'm generically talking about the load times, more specifically we can't understand how to reduce the delay we see with the first request: in Pingdom the chronometer goes always up to 3 seconds or more while the "requests" counter is stuck to the first request. After that, when the first one is over, it arrives quickly to the end.

Thanks a lot,
Nicola

#527903
Screen Shot 2017-05-24 at 7.47.59 AM.png

Peak test from around 2pm CEST:
hidden link

You've got A's and a B across the board here, and the load times look good. Items 2-5 and 11 must be loaded and parsed before your page can be displayed. If you want to decrease the page load times, this is an area where I would try to improve. I would try to move these items out of the head of the document and into the body of the document.

Then I would try to delay the loading of Google Maps until the user scrolls into the maps section of the site. Pretty much every file loading between 3 and 5 seconds is maps-related. These are the two areas I would try to improve, but you've got fairly good results already.

#528087

Hi Christian,
I already tried to erase the Google Maps Plugin but the benefits are not so big (more or less half second, as the maps are already not blocking the render of the page).

I paste here what the support team fron Flywheel just wrote me:

"I cloned this site to a test server and ran several uncached load tests, and what I found was that the latency in server response disappears when the plugins are deactivated.

So I then installed the P3 Performance Profiler Plugin on the site and ran a test with it as well. It looks like the Layouts plugin is the biggest source of latency, followed closely by the Toolset Views plugin.

To summarize: our server is doing everything it can, and things actually aren't in bad shape for users since they'll be receiving a much faster, cached version of the site. But the *un*cached version is slow because of the plugins; about 70% of the site's overall load speed—almost three total seconds—is because of plugin load."

I'm not expecting that Toolset doesn't affect the performance at all, but it looks like it has a big role in our waiting times. We compared the loading times with Toolset plugins enabled and then with Toolset plugins disabled, 10 tests each, and the average value we have in the first case is 4.9 seconds, in the second case is 2.9 seconds, so we have a difference of 2 seconds. Is this normal? I understand that with these plugins disabled the pages are loading less content, but this is not sufficient to justify a delay of 2 seconds. Have we made some mistake using the plugin?

Thanks,
Nicola

#528496

latency in server response disappears when the plugins are deactivated
“Latency” is the amount of time it takes for the host server to receive and process a request. In the waterfall, that time shows up at the left edge of each request, and looks like a narrow line with 3 colors. This latency time is very low, even when Toolset is enabled.

We compared the loading times with Toolset plugins enabled and then with Toolset plugins disabled, 10 tests each, and the average value we have in the first case is 4.9 seconds, in the second case is 2.9 seconds, so we have a difference of 2 seconds. Is this normal?
It can be. In the waterfall I included above, the last 3 seconds before the page load is complete is all map-related, and Toolset has no control over how fast those files are delivered or parsed. Neither does your host - they're all loaded from 3rd party servers. I've recommended a solution for this, which is to delay maps loading until the map is scrolled into view.

#528981

Hi,
we disinstalled the previous Google Maps plugin and used Toolset Maps (it looks like it's not making a big difference, the pages are a bit ligher but no real difference in time load), I've looked if there's a function to delay the load of the maps but I haven't found it. How can I achieve this result?

Thanks,
Nicola

#529433

Toolset plugins don't provide a way to handle lazy-loading of maps. This would require custom code that falls outside the scope of the support we provide here, unfortunately. I would recommend looking for a 3rd party plugin that will allow you to lazy-load portions of your site when the user scrolls them into the viewable window.

#530492

Hi Christian,
we tried to lazy-load the maps but didn't found a working solution via plugin. We disabled Google Maps and noticed that they have a small relevance as without them the pages are loading less than half a second faster, so we opted to keep them as they are. Moreover we think theyr're somehow already lazy-loading as they are between the last elements that appear.

You told me that 2 seconds of delay can be due to Toolset's plugins. Are there indications about how to set up a fast website with Toolset? For example: no nested views, maximum suggested number of views (per page and totally), maximum number of layouts and content types.

Our hosting provider includes the service of caching, so we do not need a plugin for that, anyway would there be one that you suggest to install to cache the output of the views, so that it's not generated any time a user opens a page?

Thanks,
Nicola

#530514

We disabled Google Maps and noticed that they have a small relevance as without them the pages are loading less than half a second faster, so we opted to keep them as they are.
May I see the waterfalls for these tests?

You told me that 2 seconds of delay can be due to Toolset's plugins.
You asked if it can be normal. Toolset has no control over some things, like loading external Google Maps assets. When you turn on maps, these assets become required to display the results of your Views. If these assets are slow to load from another server, then I would not characterize Toolset as being directly responsible. To be clear, I'd like to see the waterfalls of the tests you have mentioned (4.9 vs 2.9) after disabling Toolset plugins. Please run them on a service like webpagetest so that you can share the results with me, and I can investigate further.

...would there be one that you suggest to install to cache the output of the views, so that it's not generated any time a user opens a page?
There are several out there...you might try WP Super Cache, which will generate static HTML page versions of each page in your site. However, notice the top row of the waterfall image I posted here: https://toolset.com/forums/topic/slow-website/page/2/#post-527903
This is the only row that will perform faster, because it's the only row that corresponds to something that will be stored in that cached HTML file. A caching plugin does not speed up downloads of assets (CSS, JavaScript, Images, etc), so you're not going to see massive improvements in those areas.

#530877
screencapture-tools-pingdom-1496229469906.png

Hi,
The tests were made with Pingdom, and the times reported are an average of 20 tests (10 tests with Google Maps on and 10 without Maps). Pingdom showed not much difference in times, the weight of the page and the requestes dropped to less than half but this had little effect on loading times. Morevover we have long times even for the pages that don't include maps.

Anyway we did tested the website with webpagetest and here are the waterfalls:
1) Homepage with everything on:
hidden link

2) Homepage without Google Maps
hidden link

3) Homepage with Toolset disabled (and also Google Maps disabled)
hidden link
Effectively here we don't see the big difference we had with Pingdom.

This is instead the waterfall of the page hidden link, that does not include maps, with everything on:
4) hidden link

With WebPageTest this page seems faster, but with Pingdom we have longer times that are closer to our experience browsing the website. See attached screenshot.

Thanks,
Nicola

#530958

Okay, so the tests I have run and the tests you have run are showing good results. The difference between time-to-first-byte is negligible in the tests you have provided when Toolset is completely disabled and when everything is enabled, meaning that there is not a significant problem with Toolset delaying the server from sending your page. This is in line with what I've been saying all along. The main delay is not serving the content of your page. The main delay is in serving up assets that are required for your page to load.

If webpagetest is measuring results significantly different from what you're experiencing, then perhaps there's an issue loading the site from specific locations. Perhaps it's just faster here on the East Coast of USA (by default, webpagetest runs its tests on a location near Washington, DC) because it's closer to your host's location. I can't think of any reason why Toolset would perform so differently in different locations - nothing is location-specific about our system. This sounds like more of a network or host issue than anything else.

If you have any other thoughts on how Toolset can improve here, I'll be glad to hear them.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.