Super Speedy Filters

Slow filters do not show on your computer, they show on your customer's phone

A product filter always feels fast when you test it. Your shop is cached, you are on fibre, and you are looking at a category with thirty items. The conclusion is that it works fine and you move on.

The customer is not in that situation. They are in a category with four thousand products, on mobile data, and they are about to tap three or four filters in a row. If each tap takes two seconds, they have not waited two: they have waited eight, and by the third they are gone.

The technical reason is dull but important: WordPress stores the product to category relationship in a table designed for everything, not for filtering. When there are categories inside categories on top of that, the query balloons. That is the bottleneck, and it is exactly where this plugin decides to intervene.

What it does

• Dedicated ancestor tables replacing the usual WordPress joins, so filtering by a category includes its children without huge lists of identifiers.
• Updates without reloading: tapping a filter changes the results, not the whole page.
• A single request returning products, all filters and the visible archive content at once.
• Lazy loading of filters that open on hover or click, so nothing gets calculated that nobody looked at.
• Filter types: categories, attributes, custom taxonomies, price range, stock, sale status, custom fields and colour swatches.
• Hiding dead ends, showing only the options that have available products.
• Fragment caching for the parts that repeat on every load.

Caching has a price and it is worth choosing deliberately

Fragment caching is what delivers the last burst of speed, and it brings the usual trade-off: what gets stored stops being fresh. If you change a category or an attribute, the filter will keep showing the old version until it is cleared.

In a shop whose catalogue is touched once a month, that is not a problem. In one adding products daily, you have to decide how often it clears and accept there may be a window of lag.

The performance tables also need maintenance: they are rebuilt by WordPress scheduled tasks, and if you have those disabled you must trigger the rebuild by hand from the command line. It is a small detail that, forgotten, makes the filters stop reflecting the catalogue.

The ranking warning almost nobody gives

A filter system generates a new address for every combination. With three filters of ten options each, that is a thousand pages saying almost the same thing, and it spreads your authority across urls nobody cares about.

Pretty urls are not enough: you have to decide which get indexed and which do not. The practical rule is to leave indexable the combinations people genuinely search for, brand plus size and the like, and close the rest.

No filter plugin solves this part for you, and it is the one that has cost the most to shops that installed one and watched their traffic fall without understanding why.

Requirements and what it does not do

It needs WordPress 6.2 or higher and PHP 7.0 or higher. It requires no separate database and no external services: it works on the WordPress one with auxiliary tables.

It does not promise a specific response time, and rightly so: that depends on your catalogue, the number of terms, your hosting, your caching and your theme.

The delicate point is the theme. Updating without reloading needs to know which part of the page is the results grid, and that is indicated with selectors. With a standard theme it usually works out of the box; with a heavily customised one, it needs configuring, and that is not always trivial.

Alternatives in the catalogue

Filters are a crowded category and all the worthwhile ones are here. The YITH filter is the most widespread, BeRocket is among the most complete in filter types, and if you work with Divi there is its own filter.

When the problem is not filtering but guiding a buyer who does not know what they are looking for, the approach changes: the step filter leads them by the hand instead of handing over twenty checkboxes.

Frequently asked questions

Why is it faster than other filters?
Because it does not use the usual WordPress joins for categories: it maintains its own tables built for the job.

Does it need a separate search server?
No. It works on the WordPress database, with no external services.

Does it work with any theme?
With most. It needs to know which element is the results grid, and heavily customised themes have to be told.

Is it any use for something other than products?
Yes, it works with other public content types besides WooCommerce.

What if I have scheduled tasks disabled?
The tables have to be rebuilt by hand from the command line, or the filters go stale.

Will Google index every filter combination?
It might, and you do not want that. You have to decide which get indexed and close the rest.