PluginUs.Net - Business Tools for WooCommerce and WordPress

[realize your idea - make your dreams come true]
Botoscope is currently in early access

Support Forum

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

Site running slow with WOOT, BEAR and HUSKY

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.

Hi, we are experiencing slowness with our website http://www.crosshydraulics.com.au
Customers and our staff are complaining that access the site is slow.

We fully respect the issue may not be with your plugins but can we please request that you review to check and see?

Your thoughts and recommendations would be highly appreciated.

Hello Mark

Thanks for flagging this, and no problem checking from our side.

We accessed http://www.crosshydraulics.com.au from Europe and went through the home page, category pages and a single product page (where the variations/parts table loads via AJAX). Everything loaded briskly for us, including that AJAX table, even across the distance to Australia. One caveat: the site sits behind Cloudflare, so from here we cannot see the real origin server or measure true server latency. In short, we were not able to reproduce the slowness you describe, which is exactly why the specifics below matter.

A quick note on each plugin so you know where they can and cannot affect speed:

BEAR (Bulk Editor) is an admin-only tool. It registers no hooks or scripts on the public frontend, so it has no effect on visitor-facing page speed. It only runs while you are actively using it in wp-admin.

HUSKY (Products Filter) is active on the site. The filter itself is lightweight, but product searching can be tuned if it ever feels slow. We have a dedicated guide with concrete steps here: https://products-filter.com/searching-is-slow . One item worth highlighting: in tab Advanced there is an option"Init plugin on the next site pages only", which lets you load HUSKY only on the pages that actually use it, instead of on every page.

WOOT (Products Tables) renders its table on the single product page via AJAX. The dataset there is fairly dense, but it loaded instantly for us. If you want that specific request faster, database-level caching helps (see below).

To investigate properly, since we could not reproduce it, please give us the specifics:

  1. The exact URLs that feel slow (home, a category, a product page, or the admin side).
  2. Whether it is slow for visitors, for staff in wp-admin, or both.
  3. Approximate load times you are seeing, in seconds, and on what device, connection and rough location.
  4. Ideally a short screen recording of the slowness, or a PageSpeed / GTmetrix report link.

That lets us separate a plugin issue from a general site or hosting issue.

On the general side, we ran your home page through PageSpeed (mobile) https://pagespeed.web.dev/analysis/https-www-crosshydraulics-com-au/p69rsniolb?form_factor=mobile , and the main bottlenecks there are site-wide rather than plugin-specific: a large amount of render-blocking JavaScript and CSS (roughly 342 KB of scripts), many separate HTTP requests, and short browser cache lifetimes. Addressing those usually gives the biggest real-world gain. Practical directions:

Use an optimization plugin to combine, minify and defer scripts, inline small critical CSS, and set long cache headers. Autoptimize is a solid free option and the one we usually recommend. Since you already use Cloudflare, enabling its optimization and CDN delivery on top of that will speed up asset delivery, not just cache it.

One important caution: aggressive"combine / delay JavaScript" settings can break AJAX features, and both the HUSKY filter and the WOOT table rely on AJAX. If you enable JS delay or combine, exclude the filter and table scripts so they keep working.

For the dense product table specifically, you can reduce database load with object caching, for example Redis Object Cache if your host supports Redis. Be careful here though: do not full-page-cache or fragment-cache the dynamic AJAX responses themselves, as that can serve stale or wrong data such as outdated variant or price info. Caching at the database-query level is the safer route; full-page caching of dynamic endpoints is the thing to avoid.