Magento layered navigation slows on large catalogs because every filter click triggers an OpenSearch aggregation across all filterable attributes, not a simple database lookup. The fixes are attribute hygiene, tuned index mappings, and controlling filter URLs. A Hyva theme renders the results faster, but it does not fix a misconfigured search index underneath.
Layered navigation is the sidebar of filters on a category page: price, color, size, brand, and any custom attribute you expose. On a 500-product store it is invisible. On a 50,000-SKU catalog with 40 filterable attributes it becomes one of the heaviest interactions on the site, and it is where large merchants lose both Core Web Vitals and conversions. Here is what actually happens under the hood and how to make it fast on a modern Magento and Hyva build.
Why layered navigation gets slow: the real mechanism
Most articles on this topic still describe layered navigation as a set of “database queries.” On Magento 2.4.x that is out of date and it leads people to fix the wrong thing.
In current Magento and Adobe Commerce, layered navigation is powered by the search engine. When a shopper lands on a category or applies a filter, Magento sends a query to OpenSearch (or Elasticsearch on older installs) and asks for an aggregation: for every filterable attribute, count how many products match in the current result set. That aggregation is what builds the filter list and the product counts next to each option.
The cost scales with three things: the number of filterable attributes, the number of distinct values per attribute, and the size of the result set being aggregated. A catalog past roughly 10,000 products with rich attributes will see filter interactions creep over 800ms if the index is untuned, and that latency lands directly on Interaction to Next Paint. Fixing the MySQL layer does nothing here, because the aggregation never touches MySQL. You tune the search engine and you trim the attributes.
What the theme does, and what it does not
Hyva helps, but it is important to be precise about how, because vendors oversell it.
A Hyva theme build renders the category page and the filter sidebar with a fraction of the JavaScript and DOM weight of legacy Luma. That makes the page paint faster and respond faster, which lifts Largest Contentful Paint and INP on category templates. Hyva also makes AJAX filtering straightforward with Alpine.js rather than the heavy RequireJS and Knockout stack Luma used.
What Hyva does not do is change the query underneath. The OpenSearch aggregation is identical whether the frontend is Luma, Hyva, or headless. If your filter interaction is slow because the index is untuned or you have 40 filterable attributes, migrating the theme will make the shell faster while the filter still stalls. The frontend and the search configuration are two separate problems, and you have to fix both. Our Magento and Adobe Commerce development team treats category-page performance as a full-stack job for exactly this reason.
The attribute hygiene that fixes most of the problem
Before touching index settings, audit which attributes are filterable. This one step resolves the majority of layered navigation performance complaints, and it costs nothing but discipline.
Every product attribute in Magento has two relevant flags: Use in Layered Navigation (filterable on category pages) and Use in Search Results Layered Navigation. Teams tend to set attributes filterable “just in case,” and the aggregation pays for every one of them on every category load.
- Make an attribute filterable only if shoppers actually use it to narrow products. Color, size, brand, price: yes. Internal SKU flags, supplier codes, and one-off spec fields: no.
- Watch
Display Product Count. Showing the count next to each filter option forces the aggregation to compute counts for every value, which is more expensive than hiding them. On very large catalogs, turning counts off can meaningfully speed up the interaction. - Set attribute position and swatch rendering deliberately. A 200-value attribute rendered as swatches is a rendering cost on top of the aggregation cost.
A merchant with 45 filterable attributes rarely needs more than 10 to 15. Cutting the list is the single most effective change available, and it improves usability at the same time, because a wall of irrelevant filters overwhelms shoppers.
Tuning OpenSearch for faceting at scale
Once attributes are trimmed, tune the engine. The right level of effort depends on catalog size.
| Catalog size | What to tune | Typical impact |
|---|---|---|
| Under 10,000 SKUs | Attribute hygiene, disable legacy flat catalog | Usually enough on its own |
| 10,000 to 100,000 SKUs | Index mapping, shard count, refresh interval, aggregation limits | Filter latency from 800ms+ down to sub-200ms |
| 100,000+ SKUs or heavy traffic | Dedicated OpenSearch nodes, memory sizing, query caching, ElasticSuite or a SaaS engine | Keeps facets fast under concurrency |
A few specifics that matter regardless of size. Flat catalog is a legacy Magento 1 era feature; on 2.4.x it should stay disabled, because EAV with proper indexing and OpenSearch is the supported path and flat catalog now tends to hurt stability more than it helps. Keep your indexers on schedule and healthy, since a stale catalog search index produces both wrong counts and slow queries. And confirm you are on a current search engine, because Magento 2.4.6 and later added official OpenSearch support and later patches fixed real faceting bugs, such as attributes with incorrect integer mapping. Our deeper guide to OpenSearch versus Elasticsearch tuning for Adobe Commerce covers the node sizing and mapping work for the largest catalogs.
Server-rendered versus AJAX filtering on Hyva
How the filter applies to the page is a Core Web Vitals decision, not just a UX one.
Server-rendered (full reload): the shopper clicks a filter, the page reloads with the new URL, and the server returns a fresh, cacheable page. This is simple, SEO-friendly, and stays inside full page cache. The downside is a full navigation on every filter change, which can feel heavy on a large catalog.
AJAX (Alpine.js on Hyva): the filter updates results in place without a full reload. This feels fast and modern, and Hyva makes it clean to implement. The risk is Cumulative Layout Shift and INP: if the grid reflows as results swap, or the main thread blocks while Alpine re-renders a large list, you trade one metric for another.
The correct pattern on Hyva is AJAX filtering that reserves layout space so the grid does not shift, updates the URL so the state is shareable and crawlable, and keeps the re-render off the main thread long enough to protect INP. Getting this right is the same craft as the broader work in our playbooks on reducing INP with Alpine.js patterns and cutting Largest Contentful Paint on a Hyva storefront. Do not assume an AJAX layered navigation extension ships with these safeguards; most do not, and many need a Hyva compatibility module before they render at all.
When native is not enough: alternatives compared
For most catalogs, tuned native layered navigation on OpenSearch is fine. Some cases need more: very large catalogs, complex faceting rules, or merchandising-driven filter ordering.
| Option | Strength | When to choose it |
|---|---|---|
| Native OpenSearch layered navigation | No extra cost, fully supported | Most catalogs after tuning |
| ElasticSuite | Richer relevance and faceting, popular in the community | Large catalogs needing better relevance, if configured carefully |
| Adobe Commerce Live Search | Managed, AI relevance, no infrastructure to run | Adobe Commerce merchants wanting a hands-off engine |
| Algolia or similar SaaS | Very fast facets and instant results at scale | Huge catalogs and high concurrency where speed is the priority |
ElasticSuite is powerful but not free performance: faceted navigation can slow product list pages when filter blocks, attribute counts, or aggregation logic are misconfigured, so it needs the same discipline as native. For the SaaS route, we cover the rendering and indexing tradeoffs in detail in our guide to running Algolia on Magento and Hyva.
The SEO trap: filter URLs and crawl budget
Performance is not the only risk layered navigation creates. Every filter combination can generate a unique URL, and on a large catalog that produces millions of thin, near-duplicate pages that eat crawl budget and dilute rankings. This is the problem the performance guides skip and the SEO guides isolate, when it needs to be handled together.
The standard approach: allow crawling and indexing of a small set of valuable single-filter pages that match real search demand, add canonical tags that point multi-filter combinations back to the clean category page, and use robots directives or URL parameter rules to keep the combinatorial explosion out of the index. Decide this deliberately rather than letting the default behavior flood Google with filter permutations. It protects both crawl efficiency and the full page cache hit rate, which ties back to the caching discipline in our full page cache and Varnish on Hyva guide.
Google’s own guidance on managing crawl budget is worth reading if your catalog is large enough for this to bite, and Core Web Vitals thresholds for the filter interaction are documented in web.dev’s INP reference.
A layered navigation tuning checklist
Work this in order; each step is cheaper than the one after it.
- Audit filterable attributes and cut the list to the ones shoppers actually use.
- Reconsider
Display Product Counton very large catalogs. - Confirm flat catalog is disabled and indexers are healthy on schedule.
- Verify you are on a current OpenSearch version with recent Magento patches.
- Tune index mapping, shards, and refresh interval to catalog size.
- Choose server-rendered or AJAX filtering deliberately, and protect CLS and INP if AJAX.
- Control filter URLs with canonicals and robots rules before they flood the index.
- Measure filter interaction latency in field data, not just a lab test.
Comparing platforms for faceted search
If catalog scale and filtering are central to your business, the platform matters. Magento and Adobe Commerce give you the deepest control over faceting, index tuning, and custom filter logic, which is why large-catalog B2B and DTC merchants stay on it. A Shopify or Shopify Plus store leans on apps for advanced faceting with less low-level control, BigCommerce offers solid native faceting for mid-size catalogs, and Shopware has a capable filter system rooted in European B2B. The tuning principles here map most directly to Magento’s OpenSearch-backed navigation.
FAQ
Why is my Magento layered navigation slow even though my server is fast?
Because the bottleneck is usually the OpenSearch aggregation, not the web server. Layered navigation asks the search engine to count matches across every filterable attribute on each interaction. Too many filterable attributes or an untuned index makes that slow regardless of how fast your PHP or database layer is.
Does Hyva have built-in layered navigation?
Hyva renders Magento’s layered navigation in its default theme, and it renders it far lighter than Luma. Advanced features like AJAX filtering, price sliders, and multi-select often come from extensions, which need a Hyva compatibility module. The theme speeds up rendering; it does not replace the search engine that builds the filters.
How many filterable attributes is too many?
There is no hard limit, but most large catalogs perform well with 10 to 15 filterable attributes and struggle past 30 to 40. The cost is per-attribute on every category load, so the fastest win is cutting attributes that shoppers do not actually filter by.
Should I use AJAX filtering or full page reloads on Hyva?
AJAX feels faster and Hyva makes it clean with Alpine.js, but only if it reserves layout space to avoid Cumulative Layout Shift and keeps re-rendering off the main thread to protect INP. If those safeguards are not in place, a well-cached server-rendered reload can deliver better Core Web Vitals.
Will layered navigation hurt my SEO?
It can, if filter combinations generate millions of crawlable URLs. Use canonical tags on multi-filter pages, index only a curated set of high-demand single-filter pages, and block the rest with robots rules or parameter handling. Handled well, layered navigation helps SEO by matching filter pages to real search demand.
Getting category pages fast
Layered navigation performance is a full-stack problem: attribute hygiene and OpenSearch tuning on the backend, careful AJAX rendering on the Hyva frontend, and URL governance for SEO. Fixing one layer and ignoring the others is why so many large catalogs still have slow filters after a theme migration. Bemeir is the first US-based Hyva Gold partner with 16 years of Magento experience and an ecosystem of technology partners across search and performance, and we tune all three layers together. If your category pages are slow under real traffic, talk to Bemeir.
