Quote from Alex Dev on October 9, 2026, 15:01

Hello

Thank you for your message.

A general “the site is slow” can have many causes (hosting, theme, other plugins, number of products, caching), so to see what really takes the time I need some details:

1. A link to your site and to the pages that feel slow.
2. How you measured it: PageSpeed Insights, GTmetrix, Query Monitor or anything else, with the numbers or screenshots.
3. The same measurement on the same page with HUSKY temporarily deactivated, so we can see how much of the load time really comes from the filter.
4. Your HUSKY version and the approximate number of products in the shop.

Meanwhile, here is what you can already do, depending on your case.

If you have a lot of products and dynamic recount is enabled, the recount can indeed slow the page down, because the plugin has to count the products for every term in the filter. Two options help here:

You can load the filter form only on demand. Add start_filtering_btn=1 to the shortcode, for example [woof start_filtering_btn=1]. The page then shows only a “Show products filter form” button, and the form with its counts is loaded by AJAX when the visitor clicks it. You can change the button text with start_filtering_btn_txt. All shortcode attributes are described here: https://products-filter.com/document/shortcodes

You can also enable “Cache dynamic recount number for each item in filter” in the plugin settings, Advanced tab. On a production site it makes the recount much faster. Remember to clean that cache, or set an auto-clean period, when you add new products.

If your catalog is not that big and the concern is the plugin’s CSS and JavaScript loading on pages where there is no filter at all, use “Init plugin on the next site pages only” in the Advanced tab. List the pages where you want the filter, and the plugin will not initialize anywhere else. There is also a reverse mode that disables it only on the pages you list.

Once I have the details above, I can tell you exactly where the time goes.

Best regards, Alex

Sources: HUSKY shortcodes documentation

Quote from patH on October 9, 2026, 15:13

Thank you Alex for the quick answer !

1. A link to your site and to the pages that feel slow.
   All pages are slow, but let's start there : https://boutique.ramscores.com/categorie-produit/formations/duos/
2. How you measured it: PageSpeed Insights, GTmetrix, Query Monitor or anything else, with the numbers or screenshots.
   I tried WebPageTest.
   First Contentful Paint 5s   Largest Contentful Paint 5s   Cumulative Layout Shift 0.175   Time To First Byte 3.592s   Start Render 5s   Speed Index 5.971s   Total Blocking Time 0.065s   Page Weight 1MB   DC Time 6.505s   DC Bytes 1MB   Total Time 7.073s   Total Requests 147
3. The same measurement on the same page with HUSKY temporarily deactivated, so we can see how much of the load time really comes from the filter.
   First Contentful Paint 3.822s    Largest Contentful Paint 3.822s    Cumulative Layout Shift 0.175    Time To First Byte 2.737s    Start Render 3.8s    Speed Index 4.586s    Total Blocking Time 0.002s    Page Weight 1MB    DC Time 5.176s    DC Bytes 1MB    Total Time 5.695s    Total Requests 83
4. Your HUSKY version and the approximate number of products in the shop.
   Version 3.4.5.
   900 products.

Quote from Alex Dev on October 12, 2026, 15:31

Hello

Thank you for the measurements, they show quite clearly where the time goes.

Comparing your two tests:

Time To First Byte: 3.59 s with HUSKY, 2.74 s without it. So HUSKY adds about 0.85 s on the server side.
Requests: 147 with HUSKY, 83 without it. So the filter adds about 64 files (JavaScript and CSS).
Total Blocking Time is very low in both cases, so the browser has no problem running the scripts.

The most important number is the 2.74 s Time To First Byte without HUSKY. That is the server time of the site itself, before any filter is involved, and it is the main reason every page feels slow. A page cache plugin usually brings this down to a few hundred milliseconds. HUSKY works fine with page caching, because filtering is done by AJAX.

For the part that comes from HUSKY, please do the following:

1. Advanced tab: enable "Cache dynamic recount number for each item in filter" and "Cache terms", and set an auto-clean period for them. If you use the price filter, also enable "Optimize price filter". Most of the 0.85 s is the product counting for each term in the filter (900 products and three languages), and these caches remove it for repeated requests.

2. Advanced tab: set "Optimize loading of HUSKY JavaScript files" to Yes. The scripts then load in the footer instead of the page head, so the page starts rendering earlier.

3. Extensions tab: disable every extension you do not actually use on the site. Each enabled extension loads its own JavaScript and CSS files, even when it is not used in your filter, so this is where most of the 64 extra requests come from.

4. Page cache for the whole site, as described above. This will give the biggest improvement on all pages, not only the shop.

5. You mentioned that all pages are slow. By default HUSKY initializes on every page, including pages without any filter (home page, single product pages, cart, checkout), and adds the same server time and files there. In the Advanced tab use "Init plugin on the next site pages only" and list only the pages where the filter is shown, for example your shop and product category pages. On all other pages HUSKY will then not load at all, so they get back the full 0.85 s and the extra requests.

After these changes please run the same WebPageTest on the same page again and send us the numbers. If the server time added by the filter is still high, install the Query Monitor plugin, open the same page and send us a screenshot of the Queries by Component section, so we can see exactly which queries take the time.

Kind regards, Alex

Quote from patH on October 12, 2026, 18:29

Thanks a lot for your helpful message.

For the part that comes from HUSKY, please do the following:

1. Advanced tab: enable"Cache dynamic recount number for each item in filter" and"Cache terms", and set an auto-clean period for them.

How can I set an auto-clean period... can see any option for that.

3. Extensions tab: disable every extension you do not actually use on the site.

I am using no extra extensions, but can we disable ACF fields [acf_filter], Searching by Author, In Stock, as I do not use them ?
For the rest I tried WP Super Cache.
And I can understand the Time to first byte is disaster, OVH shared server...

Quote from Alex Dev on October 13, 2026, 15:28

Hello

Thank you for the update.

1. Auto-clean period. The period selector appears only after the cache option is switched on and saved. Set “Cache dynamic recount number for each item in filter” to Yes and save the settings. After the page reloads you will see a “clear cache” button under the option and a drop-down with the auto-clean period (every 7 days by default). The same works for “Cache terms”.
2. ACF fields, Searching by Author and In stock are system extensions, so they have no checkbox in the Extensions tab. You can still switch them off: go to the Advanced tab, find “Forcing disabling of functionality” and enter their keys separated by commas:

acf_filter,by_author,by_instock

Then save the settings. The key of each extension is shown in square brackets next to its name in the Extensions tab. Only disable extensions that are not used in your filter form.

WP Super Cache is a good choice for the page cache. After setting it up, please run the same WebPageTest again and share the numbers, then we can see what is left.

Kind regards, Alex

Quote from patH on October 13, 2026, 16:34

Thank you Alex for your help.

So here is the results of WebPageTest.

First Contentful Paint 5.751s
Largest Contentful Paint 8.062s
Cumulative Layout Shift 0.3
Time To First Byte 4.063s
Start Render 5.8s
Speed Index 7.636s
Total Blocking Time 0.198s
Page Weight 1MB
DC Time 7.985s
DC Bytes 1MB
Total Time 9.134s
Total Requests 136