Magento’s search engine has grown up. The platform dropped MySQL search and made Elasticsearch mandatory from Magento 2.4 onwards. On paper, it sounds like a performance boost. In practice? Not always.
Many Magento stores start fast. Then search begins lagging. Autocomplete takes seconds. Category pages crawl. Indexing fails quietly in the background.
Is search secretly killing your store’s speed?
What Magento Stores Get Wrong With Elasticsearch
Elasticsearch is fast — but only when configured right. Most Magento stores treat it as “set and forget.” That’s where the trouble starts.
A basic install of Elasticsearch on shared hosting won’t cut it. Even with a VPS, memory usage gets out of hand. Elasticsearch loves RAM. It’s built to run on large heaps with generous CPU access.
Developers often overlook these early signs:
- High CPU spikes on product filter clicks
- Autocomplete timing out under load
- Broken category filters
- Frequent index re-runs
- Elasticsearch crashing silently and restarting
Here’s where misconfigurations begin:
- Heap size set too low (should be around 50% of total RAM, max 32GB)
- Insufficient field data caching
- Filters generating expensive queries (especially layered nav)
- Wildcard or “match all” searches on large product sets
It gets worse when third-party modules enter the mix.
Some filter modules rewrite Elasticsearch queries inefficiently. Others load all attributes instead of just visible ones. B2B stores often compound this with shared catalog permissions, customer group filters, and price display logic.
Magento’s own documentation warns against overloading Elasticsearch with poorly configured queries and layered filters.
The Real Performance Sink: Layered Navigation and Facets
This is where most stores burn.
Every filter applied in Magento sends a new query to Elasticsearch. If you’ve got size, colour, material, brand, and more — each facet adds weight. It seems small. But each one adds load.
What hurts the most:
- Categories with over 1,000 SKUs and multiple filters
- Search results with custom sort orders (e.g. Best Sellers)
- Reindexing triggered while customers are actively browsing
Some stores go further. They install enhanced layered navigation modules. These promise better UX. They often disable Magento’s flat tables and override filters with JavaScript-based calls to Elasticsearch. Every scroll, every click, every pageview — it all hits the engine.
Do this at scale? It becomes chaos.
Here’s a rule: if your filters load in over 1.5 seconds, Elasticsearch isn’t configured right — or it’s overworked.
How to Optimise Elasticsearch for Magento (Without Breaking Search)
This is the core of it. And this section goes long for a reason.
Fixing Magento Elasticsearch issues doesn’t mean switching engines. It means tuning what you have. That starts with the server itself.
1. Get Elasticsearch off your Magento server.
Magento should run PHP and MySQL. Elasticsearch needs its own space. If you’re running them together, separate them now. Use a cloud instance or containerised setup like Docker on a dedicated node.
2. Set your heap size properly.
Elasticsearch should use 50% of the available system RAM, up to 32GB. Don’t exceed that, or garbage collection will choke.
3. Check your field mapping.
Disable unnecessary fields from being indexed. Magento tends to over-map attributes. Use the bin/magento indexer:status and :reindex tools to verify what’s being indexed. Use _mapping API calls in Elasticsearch to trim unused fields.
4. Review third-party layered navigation extensions.
Some fire off 5–10 queries per page. Replace them with leaner modules like Amasty Improved Layered Navigation(well-optimised) or develop your own with only essential filters.
5. Monitor query load using Elasticsearch’s slow logs.
Log and inspect all queries taking more than 100ms. You’ll often see bloated ones caused by “should” clauses, wildcard matches or nested product attributes.
6. Enable caching for search results.
Magento’s full-page cache doesn’t always cover layered navigation. Use a Varnish setup with ESI blocks to cache filter results where possible. Or pre-warm common queries with a job queue.
7. Use synonyms sparingly.
Too many synonyms in Elasticsearch (especially long ones) slow down queries dramatically. Keep synonym files lean and tested.
There’s no quick fix here. But once you clean your mappings, optimise your queries, and isolate Elasticsearch — things will improve quickly.
What You Can (and Can’t) Expect From Elasticsearch
Even when optimised, Elasticsearch isn’t magic. It won’t solve broken product taxonomies. It won’t make your product names clearer. And it won’t handle front-end rendering delays caused by JavaScript bloat.
But it will improve:
- Search speed
- Category filtering
- Indexing reliability
- Backend performance
What it can’t do:
- Replace product tagging
- Understand user intent
- Fix broken filter logic
This is why some large Magento sites pair Elasticsearch with AI-powered solutions like Klevu or Algolia. Those tools sit on top of Elasticsearch, feeding it structured queries and filtering noise. They cost more — but for high-SKU stores, they’re worth it.
Magento gives you access to Elasticsearch’s raw power. But it doesn’t teach you how to tame it.
When to Consider Replacing Magento Search Entirely
If you’ve optimised Elasticsearch and performance still suffers, it might be time to swap search layers. This isn’t uncommon.
You can:
- Use Algolia with Magento’s official integration module
- Deploy Klevu for AI-driven search suggestions
- Custom-build a lightweight microservice that handles search separately, offloading Magento entirely
These routes make sense if:
- You’ve got over 50,000 products
- Filters break frequently
- Your customers rely on precision search
- You support multiple store views with language-specific indexes
They come with cost. But they reduce Magento overhead.
Magento’s Elasticsearch is powerful — when treated right. Most slowdowns come from filter overload, poor server configs, and noisy third-party extensions. Fixing it takes care. And patience.
Your search shouldn’t punish your store’s speed.
