PluginUs.Net - Business Tools for WooCommerce and WordPress

[realize your idea - make your dreams come true]

Support Forum

You need to log-in to create request (topic) to the support

Excessive front-end asset loading — HUSKY Products Filter loads 27 JS files on pages without any filter widget

The support doesn work on Saturdays and Sundays, so some Friday requests can be answered on Monday. If you have problems with registration ask help on contact us page please
If you not got email within 24~36 business hours, firstly check your spam box, and if no any email from the support there - back to the forum and read answer here. DO NOT ANSWER ON EMAILS [noreply@pluginus.net] FROM THE FORUM!! Emails are just for your info, all answers should be published only here.
The support doesn work on Saturdays and Sundays, so some Friday requests can be answered on Monday.

Hello,

I'm running HUSKY - Products Filter Professional for WooCommerce v3.3.8.1 on a WooCommerce/Dokan marketplace site (elektrotekhnika.com), WordPress 7.1, WooCommerce v11.0.1.x, theme Wolmart.

During a performance audit I found that the plugin enqueues around 27 separate JS files (plus a comparable number of CSS files) on every single page of the site — including pages that don't contain any HUSKY filter widget or shortcode at all, such as the homepage. This is a significant contributor to total page weight and request count.

What I've already checked on my end:

  • The plugin is on the latest available version.
  • Under Advanced → Extensions, all optional extensions are already disabled except the two default ones I actually use (Featured products, Quick search).
  • I reviewed the Advanced → Conditionals tab, but it appears to control filter behavior per page, not asset enqueueing.

My question: is there a supported way to have HUSKY only enqueue its scripts/styles on pages that actually contain a filter (product category/archive pages), rather than loading them globally on every page including posts, the homepage, and static pages that have no filter present? If there's a filter hook or a setting I'm missing, I'd appreciate pointers. If this isn't currently possible, I'd like to flag it as a performance improvement request, since global asset loading is a meaningful load-time cost for stores with a large catalog and heavy homepage traffic.

Happy to share network request exports or a debug log if that helps.

Thank you!

Hello Roman

There are three ways to deal with this. The first one solves your problem completely, the other two are softer.

1. The radical way: do not let the plugin start at all

On pages where HUSKY is not needed, the plugin can simply not initialize. Then there is nothing to enqueue at all — no scripts, no styles, no hooks.

We are adding this switch to the plugin itself and it will ship in one of the next releases. Until then you can add it by hand. In the plugin's index.php, right after the ABSPATH check at the very top of the file, add these three lines:

if ( ! empty( $GLOBALS['disable_woof_plugin'] ) ) {
return;//included into the next version code
}

Then create a file wp-content/mu-plugins/husky-scope.php and put your own logic in it. Any logic you want — by address, by request type, by anything:

<?php

$uri = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '';
$allowed = array('/shop/', '/product-category/');
$load = false;
foreach ($allowed as $needle) {
	if (strpos($uri, $needle) !== false) {
		$load = true;
		break;
	}
}
if (!$load) {
	$GLOBALS['disable_woof_plugin'] = true;
}

 

It must be an mu-plugin. Files in mu-plugins load before regular plugins, and that is the only moment early enough for this to work. A theme's functions.php loads later and will have no effect.

Decide by the request address only. At that moment WordPress has not run the main query yet, so is_front_page(), is_page() and similar tags are not available there and will not give correct answers.

Two warnings. The edit to index.php will be lost on every update until the switch ships officially, so re-apply it or wait for the release. And if your theme or another plugin calls the woof() function in a template, a page where the plugin is switched off will break — with Wolmart and Dokan this is worth testing before going live.

2. The settings way: choose the pages in the admin

If you would rather not touch code, open the plugin settings, Advanced tab, and find the field"Init plugin on the next site pages only".

Put one URL or URL mask per line. On pages that do not match, the plugin does not initialize and loads nothing. A line starting with # means strict comparison of the whole address, for example #https://elektrotekhnika.com/shop/. Without # it is a mask matched anywhere in the address, so product-category covers all your category pages.

Next to the field there is a Reverse switch. It inverts the logic, so instead you can list only the pages where the plugin must be switched off. Use whichever direction is shorter to maintain — with a marketplace homepage and many static pages that is usually the normal direction, listing the shop pages.

One safeguard: any address containing the filter search slug always initializes the plugin, whatever your masks say. Your filter links cannot be broken by this setting.

3. Combining the files on pages where the filter does load

In the same Advanced tab there is an option"Optimize loading of HUSKY JavaScript files". Enable it and the core scripts are served as one combined file instead of five, and they move from the head into the footer. Test your front end after enabling it, because the load order changes.

Extension scripts are not combined by that option. If you use an optimization plugin, you can group them yourself: all our handles start with woof. The core ones are woof_front, woof_radio_html_items, woof_checkbox_html_items, woof_select_html_items, woof_mselect_html_items, and the extensions follow the pattern woof_name_html_items. Combining them is safe, but do not defer or delay woof_front, that breaks AJAX filtering.

A few third-party libraries we enqueue do not carry that prefix, so watch for them separately: icheck-jquery, chosen-drop-down, plainoverlay, and select2 or selectWoo, which comes from WooCommerce itself.

And please update. You are on 3.3.8.1, the current version is 3.4.3, and there are fixes since then that matter for WooCommerce 11.

Place please actual purchase code of the plugin into the private area of the ticket:
https://share.pluginus.net/image/i20230222134241.png
https://share.pluginus.net/image/i20230222134615.png
https://share.pluginus.net/image/i20230222134511.png

Best regards,
Alex