Layered navigation is one of Magento’s big selling points. It helps customers filter products, refine results, and find what they want faster. Sounds like a conversion booster.
But on many Magento sites, it does the opposite.
Page load slows. Filters freeze. Bounce rates rise. Conversion rates dip.
What’s supposed to improve UX ends up making it worse.
Why?
How Magento Layered Navigation Actually Works
Layered navigation looks simple on the surface. Customer picks a filter – size, colour, brand – and the page reloads with refined results. Behind the scenes, it’s far from simple.
Each filter triggers a database query that intersects product attributes, stock data, category information, pricing rules, customer groups, and visibility settings. Magento builds a new product collection every time a filter is clicked.
Let’s break it down.
Magento creates filterable attributes in the catalog_product_index_eav or catalog_product_index_price tables. When you select multiple filters, it performs SQL joins across:
- EAV (Entity-Attribute-Value) tables
- Category-product indexing
- Stock index
- Pricing index
- Customer group rules
- Store views and visibility flags
Each click creates a new composite query. Multiply this by large catalogues and multiple store views, and you’ll start to feel the drag.
Now layer in:
- Configurable products
- Search result filters
- Multi-currency pricing
- Product tag rules
- Third-party attribute conditions
The performance overhead builds up. If the filters use OR logic (like colour = red OR blue), it gets worse. Magento’s native logic often doesn’t use query optimisations like subqueries, result caching, or pre-filtered aggregates.
The result? Slow product listing pages, especially when combined with pagination, category sorting, or AJAX-based filtering.
When Layered Navigation Starts Breaking Everything
Magento sites with under 500 SKUs usually don’t notice. But once your catalogue grows – or if you add B2B functionality, custom attributes, or third-party extensions – things start cracking.
Here’s where it gets painful:
1. Slow SQL Queries
Filter combinations generate inefficient SQL. On large datasets, these queries can take seconds. On shared or underpowered hosting, that turns into timeouts.
You can check for this by enabling Magento’s built-in query log or using MySQL’s slow query log. Queries hitting catalog_product_index_eav with multiple joins are usually the culprits.
2. Inefficient Attribute Setup
Too many filterable attributes degrade performance. Attributes set as “filterable in search” or “filterable with results” trigger extra indexing and more query load. Most stores overdo this – filtering on availability, weight, meta fields, brand, material, size, and more.
Go to Stores > Attributes > Product and check which attributes are actually needed for filtering. Reduce them to 3–5 per category if possible.
3. Cache Invalidation
Layered navigation depends on category and product indexers. Every time a product’s stock, visibility, or category changes, the indexes rebuild. On large sites, this causes cache invalidation storms that slow down filtered views.
You’ll often notice it during catalogue imports or automated inventory syncs. Page speed tanks during reindexing.
4. AJAX Filters Without Optimisation
Many Magento themes or modules add AJAX filtering to make UX smoother. Sounds good. But if you don’t use query result caching or partial block refresh, the full product collection is reloaded on every click – via AJAX. That doesn’t make it faster. It just hides the slowness behind a spinner.
5. Third-Party Modules That Extend Filters
Popular filter modules like Amasty Layered Navigation or MagePlaza Advanced Layered Navigation add extra features: image swatches, price sliders, brand groups. But they often add more complex logic or load JS frameworks that slow rendering. Some even override Magento’s default index tables, which breaks compatibility with other modules.
Performance drops sharply when multiple filter modules run simultaneously.
What to Do Instead: Smarter Filtering for Speed and UX
Now for the part that matters.
To fix layered navigation, you don’t need to kill it. But you do need to rebuild it with a different mindset. The goal isn’t just “filter everything.” It’s to show the most useful filters with the least performance cost.
Let’s walk through how to do this properly.
1. Reduce the Number of Filterable Attributes
Go through your product attribute list. Ask yourself: do customers actually need to filter by this? If the answer is no – disable it for layered navigation.
Focus on high-impact filters:
- Category-specific sizes (e.g. shoe size only in footwear)
- Colour (but group them into families: red, blue, black)
- Brand (if you have a large catalogue)
- Price (ideally pre-defined ranges, not sliders)
Avoid filtering on things like:
- SKU
- Stock status
- Visibility
- Metadata
- Weight or dimensions (unless critical to the category)
You can still use these fields for sorting or search – just not filtering.
2. Use ElasticSearch or OpenSearch Smart Filtering
Magento supports ElasticSearch as a catalogue search engine. If configured properly, it can handle layered navigation filtering too – with much better performance.
Set it up under Stores > Configuration > Catalog > Catalog > Catalog Search.
To make it effective:
- Enable faceted search
- Enable search synonyms (for terms like “blue” = “navy”)
- Optimise the Elasticsearch config to increase heap memory and use SSD disks
- Use a dedicated ElasticSearch node or service (like AWS OpenSearch or Bonsai.io)
This removes the burden from MySQL and speeds up filtered page loads considerably.
3. Add Frontend Filter Caching
Use Varnish or a JS caching layer to cache common filter combinations. You can create VCL rules in Varnish to serve cached HTML for popular filtered pages.
Combine this with Fastly’s Magento module or Cloudflare rules. Cache not just base categories, but filtered variants (e.g. /shoes?colour=black&size=42). This is especially useful for SEO too.
4. Replace Native Layered Navigation with Lightweight Alternatives
Instead of extending Magento’s native logic, consider modules that rebuild the filter UI from scratch using lightweight JS and custom API endpoints.
Hyvä Filters is one of the fastest options – built for performance and simplicity. It loads only the data needed and doesn’t touch the massive core filter index.
5. Add Analytics to Track Filter Usage
Use GA4 custom events or tools like Hotjar to track which filters are actually used. If 90% of users never click “Material” – get rid of it.
Less is faster.
How to Monitor and Maintain Filter Performance Over Time
Fixing navigation isn’t a one-time job. Filters need monitoring – especially if your product catalogue or attributes change frequently. Here’s how to stay ahead of slowdowns.
- Check Query Logs Weekly
Use New Relic to monitor query times on category and search result pages. Set alerts for query times over 500ms on high-traffic pages. - Review Attributes Quarterly
Audit the filterable attributes per category. Clean up ones that were added during product imports or quick changes. - Monitor Cache Hit Rates
In Varnish, check hit/miss ratios on layered navigation URLs. A low hit rate means you’re regenerating too many filtered pages server-side. - Benchmark Filter Click Speed
Use Google Lighthouse or WebPageTest to measure how long it takes for the filtered page to load after a click. Aim for under 2 seconds on desktop. - Talk to Merchandisers
Ask if customers complain about slow filters. Some issues don’t show up in metrics – they show up in complaints or call centre logs.
A layered navigation system is only as good as its relevance and speed. If you can’t offer both – remove the filters until you can.
Magento’s layered navigation can slow down even the best-built stores. But with cleaner attributes, smarter tech, and lighter frontend logic, you can keep it fast – and useful.
