Huge Performance Impact

Dear ddebnath,

Thank you for writing to us about your issue! It’s true that we’ve added a few “heavy” options in the recent releases of our plugin, though we always try to make such functionality pluggable rather than auto-enabled. After reading your post I ran some GTmetrix tests on one of our test sites to see if there has been a severe speed drop since the last time we measured the plugin performance.

Since our host’s servers are located in Europe, I chose London in the GTmetrix list of locations, and all the tests received grade A with 99% – 100% performance ratings. Then I decided to change the GTmetrix location to Canada, and surely enough the performance quality for the same pages dropped to grade B with an average of 79% rating.

I then ran checks on your site as well, and it shows grade E with 45-47% in any location that I checked, apart from India, in India it immediately raises to grade A with 90% performance measurement! Please do take the test site location into account when checking the speed, and perhaps consider making further investigation into the quality of services offered by your hosting provider, because this obviously plays a huge role in the overall site performance.

Filtering IS a resource-consuming process, with hundreds of queries sometimes running during a single AJAX call. We do our best to optimize the performance, by using caching and other techniques, but the usage of fast and reliable servers is very important, especially on sites with thousands of products and large amount of filters.

In your particular case I would like to draw your attention to the Products search widget. It uses the built-in Woocommerce search engine that runs alongside regular filtering queries, which is expected to cause performance drops, usually on sites with tens of thousands of products. We’ve included it with our plugin to provide our users with the ability to combine string search with filtering, but should probably add some kind of warning about its performance impact, so thank you for bringing the issue to our attention!

Please don’t hesitate to contact us through our contact form if you would like us to perform some further speed tests for your site!

Hello ddebnath,

We haven’t heard from you in a while so I’ll be marking this thread as resolved. Please feel free to open a new thread and link to this one if you have further questions!

Hey @annastaa ,
I’m plugging this thread instead of creating a new one, since I’ve got some similar problems. We have a filter-set with category, terms & a search box.
We also have ~2.000 products with about ~60k variations in total. So a lot to crunch through.

You’ve mentioned that there is some sort of caching used when filtering, right? Since I can’t really seem to notice this. Even when performing the same filters (without using the search input) multiple times they take the same amount of long load times.

Since our products aren’t tracked in stock we would be okay with just 1:1 caching the result of a filter, so it get’s returned instantly on a second request that is the same.

Secondly, would it be possible to only include the search-field if it’s actually populated, if the search is that performance heavy?

Thanks for a reply.

Best,
Florian

Hello Florian,

And thank you for your question!

While there may be many possible reasons for filtering getting slow, but from what I’ve seen so far, the most basic of all usually lies in the inadequate correlation of server performance to shop demands. A few simple filters may run smoothly in a shop of 1000 items even on a mass-market-quality hosting account, but one definitely needs better server for a multiple-filter installations in a shop with thousands of items, many categories and attributes!

There are options and filters that put more strain on the server than others. When a setting is resource-consuming, we usually try to put warning about that in the respective section of our plugin documentation page.

The string search widget that you refer to in your question can be named among the resource-consuming. Our plugin is not a dedicated string search plugin, we are offering this option to give users the choice of combining keywords search with filters. Our code doesn’t use index tables or any other specialized caching technique for its string search widget, but rather relies on the native Woocommerce search engine. On the other hand, the string search code is only called when the widget is used, so if you don’t use it, the reason is somewhere else.

Generally speaking, you could speed up the performance by being careful with the following options:

• Reduce / eliminate the usage of product counts / hidden empty items style
• Disable the annasta Filters > Plugin settings > Stock filter variations support option
• Price filter and other ranges: increase range slider steps, or better yet — introduce the pre-set ranges list (of type 0-100, 101-500, 500-1000 etc).
• Disable the Dynamic price sliders (annasta Filters > Plugin settings)

As for caching, our plugin uses the built-in Woocommerce caching mechanism which is currently programmed to cache any result of AJAX loop queries, for 30 days. The (non-AJAX) Woocommerce loop does its caching automatically too. Woocommerce cache is kept in form of transients (in the wp-options table). We also use caching for product counts.

We are currently working at new options that will give our users more control over caching.

If you are an advanced user and wish to carry out comparisons for non-cached / cached performance, you are welcome to write to us and we will provide you with code that will help you “switch off” the AJAX caching.