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

Performance Issue: 504 Timeouts on Parent Category with Deep Hierarchy (Flatsome Theme)

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.
samisraeli(@samisraeli)
13 Posts
Customers
January 29, 2026, 07:17

Dear WOOF Support Team,

I am contacting you regarding a severe performance issue on my WooCommerce store. I am using Products Filter Professional for WooCommerce.

The Problem:

I am experiencing extremely slow load times (often resulting in 504 Gateway Timeout errors) specifically on a"Parent Category" page ("Sunglasses").

  • This category contains approximately 700 products.

  • It has a deep hierarchy of child categories (e.g., Men, Women, Shapes, Brands, etc.).

The Diagnosis:

I have isolated the issue directly to the WOOF filter.

  1. Comparison: I have another category ("Collection") with a similar number of products (700) but without deep sub-category hierarchy. That page loads instantly with the filter active.

  2. Proof: When I temporarily remove the WOOF widget from the"Sunglasses" sidebar, the page loads instantly. As soon as I re-enable the widget, the page takes 10+ seconds to load or crashes (504).

It seems that the plugin is struggling to process the recursive hierarchy of the parent category, causing a heavy load on the server/database.

Technical Environment:

  • Theme: Flatsome

  • Plugin version: 3.3.7.1
  • Wordpress: 6.9
  • woocommerce: 9.8.3

  • Caching Plugin: WP Rocket

  • Server: VPS Environment

  • PHP Version:  8.1

Troubleshooting Steps Already Taken:

To attempt to solve this, I have already performed the following actions, but the issue persists during the initial cache build:

  1. WOOF Settings:

    • Enabled Cache dynamic recount number -> Yes

    • Enabled Cache terms -> Yes

    • Enabled Hide empty terms -> Yes

    • Tried Dynamic Recount -> No (This helped slightly, but we prefer to have it on. Currently set to Yes with caching).

    • Tried Try to ajaxify the shop -> Checked both Yes and No.

  2. Database & Server:

    • Regenerated WooCommerce Product Lookup Tables.

    • Regenerated Term Counts.

    • Cleared all Transients.

  3. Caching (WP Rocket):

    • Enabled Preload.

    • Added a delay to the Preload process (0.5s) to reduce server load during cache building.

    • Confirmed that once a page is successfully cached, it loads fast. However, the initial generation of the page by WOOF is too heavy and often times out before the cache can be created.

My Question:

Is there a specific optimization or index setting for Parent Categories with deep hierarchies? The query seems to be getting stuck when trying to calculate terms for all children and grandchildren of the main category.

I would appreciate your advice on how to optimize the filter for this specific parent category structure.

Thank you,

Sam

Last edited on January 29, 2026, 07:18 by samisraeli · #1
Alex Dovlatov(@alexdev)
596 Posts
January 29, 2026, 21:16

Hello Sam

Thank you for the detailed report. You've done excellent troubleshooting work, and I can see exactly what's happening here.

The Root Cause:

Your"Sunglasses" parent category has a deep hierarchical structure (Men → Women → Shapes → Brands, etc.). When Dynamic Recount is enabled, WOOF must:

  1. Recursively process all child categories
  2. Execute SQL queries for each term to count products
  3. Calculate counts considering the current category context

With your deep hierarchy, this results in hundreds of database queries on each page load, which is why you're experiencing timeouts.

Why"Collection" works fine:

The"Collection" category has a flat structure (no deep child hierarchy), so WOOF makes far fewer queries - that's why it loads instantly.

About Database Indexes:

Adding a composite index can provide a small performance improvement:

ALTER TABLE wp_term_relationships 
ADD INDEX idx_woof_perf (term_taxonomy_id, object_id);

However, this won't solve the core issue - the sheer number of queries remains the same.

The Better Architectural Approach:

Here's the key insight: the filter creates heavy load on every page view, but it's not needed 50% of the time - many visitors (including bots and people just browsing) never use the filter at all.

My Recommended Solution:

Use the filter in hidden/collapsed mode with a button that users click when they actually need it. This way:

✅ The page loads instantly (filter is hidden)  
✅ WOOF processes the filter only when the user clicks the button
✅ No performance impact for users who don't filter  
✅ Perfect for bots and casual browsers  

Use this shortcode instead of the widget: [woof start_filtering_btn=1 autohide=1]

What this does:

  • start_filtering_btn=1 - Shows a"Start Filtering" button
  • autohide=1 - Keeps the filter hidden until the button is clicked
  • The button can be fully customized with CSS to match your Flatsome theme

See it in action here: 

https://demo.products-filter.com/hidden-search-form/

How to implement:

  1. Remove the WOOF widget from the"Sunglasses" sidebar
  2. Add a Text/HTML widget instead
  3. Insert the shortcode above
  4. Customize the button appearance with CSS if needed

This approach gives you the best of both worlds:

  • Fast page loads for all visitors
  • Full filtering power for those who need it
  • Dynamic recount works perfectly (because it only runs when needed)

Let me know if you need help with the button styling or have any questions!

 

#2