On a catalogue of more than a hundred references, filters are not a comfort but the condition of access to the products. Setting them up raises three questions: which attributes to make filterable, how to hold the load on a large catalogue, and how to make them usable on a phone screen.
The consequences of these filters on search ranking are a distinct subject, treated separately.
Which attributes to make filterable
The temptation is to offer everything. It is the most frequent mistake and the most costly in performance as in readability.
Three criteria for keeping a filter.
It is filled in on at least 80% of the category’s products. A material filter populated on thirty products out of two hundred produces misleading selections: the customer believes they have seen the whole aisle when they have seen what was documented.
It genuinely discriminates. An attribute where 95% of products share the same value filters nothing. Look at the distribution of values before deciding.
It matches a choice criterion. The customer filters on what helps them decide, not on what your supplier thought useful to document. Packed weight, internal reference or customs code have no place in a filter panel.
A benchmark: six to eight filters per category cover almost every need. Beyond that, the panel becomes a form.
Filters vary by category
A design point often neglected, which makes the difference between a useful panel and a generic one.
Shoe size makes sense on shoes, none on accessories. Power makes sense on power tools, none on screws.
A filter panel identical across the whole shop therefore displays worthless criteria everywhere, which drowns the relevant ones. Configuration must be done per category, with an inherited and overridable filter set.
A practical corollary: the values offered must be restricted to those present in the current category. Offering thirty colours when the category only contains four is a common implementation mistake.
AJAX Faceted Filters for PrestaShopThe faceted navigation that filters fast and indexes right€99.00
The filter types
Four forms, each suited to a data type.
Checkboxes for discrete values: brand, material, size. They allow multiple selection, which is the expected behaviour.
Colour swatches for colours, obviously, with the name in a tooltip. A textual list of colours is noticeably less effective.
The price slider, with a double handle. Two precautions: display the real bounds of the category rather than fixed values, and allow direct entry of amounts for those who know what they are looking for.
Toggles for binary criteria: in stock, on sale, fast delivery. They go at the top of the panel because they are the most used.
The results counter
A decisive element for usage, and it poses a real technical difficulty.
Displaying the number of products behind each value prevents the customer from selecting an empty combination. It is what every mature filtering interface does.
The cost is real: computing these counters means as many aggregation queries as displayed values, at every selection change.
Three approaches depending on catalogue size. On a small catalogue, direct computation passes without optimisation. On a medium catalogue, a single aggregation query replaces the per-value queries. On a large catalogue, a dedicated index or an external search engine becomes necessary.
A complementary display rule: a value with zero results is greyed out rather than removed. Its disappearance makes the list jump and disorients.
Performance on a large catalogue
Three bottlenecks, in the order they appear.
The filtering queries. A filter on several attributes produces multiple joins on the attribute and feature tables. It is what brings a database to its knees on large categories.
The counter computation, mentioned above, which often costs more than the filtering itself.
The total count, needed for pagination. On a broad selection, it covers tens of thousands of rows.
Two levers before considering a redesign. A dedicated index table that pre-computes product-value correspondences, updated on every catalogue change. And a per-combination cache, with a short lifetime, which absorbs the most frequent selections.
A point of method: measure before optimising. Time the response of a filtering on your biggest category, with three active filters. If you exceed one second, the problem is real and locatable.
The mobile behaviour
This is what decides real usage, since the majority of traffic goes through it.
The desktop side panel has no equivalent on mobile. The solution that works is a full-screen panel, opened by a button, with the filters stacked vertically.
Five implementation rules.
The opening button remains reachable while scrolling, in a fixed position, with the number of active filters displayed.
Applying is explicit. On mobile, filtering at every tick produces incessant reloads. The visitor ticks what they want, then confirms with a button showing the number of expected results.
Active filters are visible after the panel closes, as chips removable with one gesture.
Reset is reachable without reopening the panel.
The panel closes on back, without leaving the page. A full-screen panel that traps the back button is a major friction.
What breaks in production
Four situations to check after implementation.
Filters on variants. Should a product available in red size S and blue size L appear in a red plus size L selection? No. Filtering must apply to the existing combinations, not to the cross-product of the product’s attributes.
Availability. An in-stock filter based on the product’s quantity without accounting for variants produces false positives.
Sorting after filtering. It must be preserved when the visitor changes a filter, otherwise it resets at every adjustment.
Empty categories after filtering. Plan a useful message rather than a blank page: offer to remove the last applied filter, which is almost always the one that emptied the selection.
Measuring
Three indicators.
The filter usage rate per category. A category where nobody filters is either too small to need it, or fitted with unsuitable filters.
The ranking of used filters. You will almost always discover that three filters concentrate most of the usage, which justifies moving them to the top and considering removing the others.
The conversion rate of sessions with filtering, compared with sessions without. A visitor who filters has a more precise intent, and the gap measures the value of the device.
The AJAX Faceted Filters module for PrestaShop implements this device on PrestaShop 8 and 9: configuration of filterable attributes per category, filtering without reload with result counters, a dedicated index for large catalogues and a full-screen panel with explicit confirmation on mobile.
