Why is your Magento 2 store slow? The answer almost always comes down to a missing Varnish cache, slow MySQL queries and a poorly configured Elasticsearch or OpenSearch search engine, which together are the most common sources of performance problems. In our experience, most executives only face the speed problem once their conversion data starts to deteriorate, even though the technical causes show up in server-side metrics, in measurable form, much earlier. In a large share of cases, slowness doesn’t stem from a single fault but from several mutually reinforcing server- and code-level problems, each of which causes significant load on its own. This article walks through the 7 most common server and code issues that slow down a Magento 2 store, and shows which symptoms each problem produces.
Missing Varnish cache: the costliest oversight
A missing Varnish cache is the most common and also the costliest issue we find when auditing a slow Magento 2 store, because this single configuration setting alone makes a dramatic difference in load time. In our experience, using the built-in, file-system-based full page cache instead of Varnish means the system runs PHP and queries the database on every single request, whereas with Varnish, cached pages can be served straight from memory, without PHP execution or database access. The official Adobe Commerce documentation also clearly confirms that built-in caching is significantly slower than Varnish, which was designed specifically to accelerate HTTP traffic.
What are the symptoms of a missing or misconfigured Varnish cache?
The most typical symptom of a missing or misconfigured Varnish cache is that product and category pages take whole seconds to load without caching, while with a proper Varnish configuration this drops to the millisecond range. When simply enabling Varnish isn’t enough: if even a single block in the layout has the cacheable=”false” attribute, because that disables caching for the entire page, and the problem can often be traced back to one poorly written custom module.
Slow MySQL queries: the hidden database bottleneck
Slow MySQL queries are the second most common reason a Magento 2 store becomes slow, and this problem is particularly insidious because its symptoms only become noticeable gradually, as the product catalog and order volume grow. In the cases we have examined, the most common causes include missing or misconfigured indexing, too many EAV attributes, and unoptimized custom modules that generate frequently repeated queries. We have observed this pattern on several projects: the larger the product master data and customer group structure of a B2B online store, the harder a poorly optimized database layer hits the speed of the entire system.
How can you recognize a database-level performance problem?
A database-level performance problem typically shows up as a slow admin panel, long indexing times and high CPU load on the MySQL server, even when frontend caching is otherwise working properly. Who shouldn’t postpone query optimization: companies whose product catalog grows regularly or that run frequent imports, because their database load grows exponentially with catalog size.
| Issue | Typical symptom | Primary fix |
| Missing Varnish cache | Load times measured in seconds | Enable Varnish, check cacheable blocks |
| Slow MySQL queries | Slow admin, high CPU load | Indexing and query optimization |
| Misconfigured OpenSearch | Slow or inaccurate search | Review index structure and shard configuration |
| Unoptimized images | Slow category page loads | Optimize image format and compression |
Misconfigured Elasticsearch or OpenSearch
A misconfigured Elasticsearch or OpenSearch is the third critical issue, directly affecting not only search speed but also the performance of catalog pages and filters in a Magento 2 system. In our experience, most clients run into this problem when the search engine’s indexing is out of step with the actual size of the product catalog, and the shard configuration or memory allocation has stayed undersized relative to the growth since launch.
When does the OpenSearch configuration pose an immediate risk?
The OpenSearch configuration poses an immediate risk when search response times climb into the seconds range, or when catalog synchronization regularly fails with errors, because this directly hurts the shopping experience and conversion. When you shouldn’t ignore the search engine setup during a project rescue: if the store is preparing for a seasonal campaign with a big traffic increase, because an undersized search index can collapse under peak load.
The 7 most common server and code issues that slow down Magento 2 stores:
- Missing or misconfigured Varnish cache.
- Unoptimized MySQL queries without proper indexing.
- Undersized or misconfigured Elasticsearch/OpenSearch index.
- Oversized images without compression or a suitable format.
- Incorrect or missing use of Redis for session and cache handling.
- Too many conflicting third-party modules.
- Outdated PHP version or undersized server infrastructure.
In a Magento 2 performance audit, the following items must always be reviewed:
- The Full Page Cache backend type and its actual cacheable coverage.
- Identification of the slowest MySQL queries based on the slow query log.
- The OpenSearch index size, shard count and response time.
- The hardware and software health of the server infrastructure and hosting operations.
- The number of installed modules and their actual impact on page load.
Unoptimized images: the invisible speed killer
Unoptimized images are the fourth most common issue slowing down Magento 2 stores, and this problem is especially insidious because nothing visually hints at it: the store looks great, it just loads slowly. In our experience, most catalog pages are slow because uploaded product photos land on the server at their original, uncompressed size, and the system doesn’t use a modern image format with smaller file sizes instead of older JPEG or PNG. In the cases we have examined, image optimization alone, with no other intervention, delivered a 20–40 percent improvement in load time on category pages where many product images appear at once.
Which specific settings improve image loading speed the most?
The biggest improvement comes from switching to a modern image format with smaller file sizes, enabling lazy loading and adding a CDN, because together these significantly reduce the load on the server and the network. When you shouldn’t postpone image optimization: if the store’s product catalog consists of visually rich categories with many photos, because in that case image size is proportionally the biggest factor in total page load time.
Incorrect or missing use of Redis for session and cache handling
Incorrect or missing use of Redis is the fifth critical issue, causing noticeable slowdowns especially in high-traffic Magento 2 stores, because without it session handling and cache fragment storage generate significant database load. In a large share of cases, we have found that file-system-based session storage remains in place even in stores whose traffic would have justified introducing Redis long ago, and this oversight becomes truly critical during peak traffic periods.
Why is it a problem if the Redis configuration isn’t separated?
It causes problems when session storage and cache storage run on the same Redis database without separation, because a large cache flush can then temporarily slow down or even interrupt active user sessions. Who needs a dedicated, separated Redis configuration most: any store with many logged-in users at once and frequent cache invalidation, because for them the lack of separation poses a direct risk to the user experience.
Too many conflicting third-party modules
The sixth common issue is an excessive number of conflicting third-party modules, which degrades not only performance but also the stability and maintainability of a Magento 2 store. In our experience, during most project rescues we see that a large share of the modules has accumulated over the years, and many of their features have long gone unused, while they continue to load the system in the background on every single page load.
How can you identify modules that add unnecessary load?
Modules that add unnecessary load can typically be identified with profiling tools, such as the built-in Magento profiler or an external APM solution, which show exactly which modules generate the most queries or the longest execution time during a given page load. Should you remove all modules at once to improve performance? No, because that carries serious functional risk; the right approach is gradual, one-by-one testing and the systematic phasing out of modules that have truly become unnecessary.
Outdated PHP version and undersized server infrastructure
The seventh, often underestimated issue is an outdated PHP version and undersized server infrastructure, which fundamentally limits how effective any of the optimizations mentioned above can be. In our experience, Magento 2 systems running on older PHP versions are not only slower than those on modern PHP versions but also pose a security risk, because vendor support for these versions eventually ends as well.
Which server resources are most often undersized?
The most frequently undersized resources are memory, which becomes a bottleneck during indexing and import operations, and CPU capacity, which limits the number of requests that can be served simultaneously during peak traffic. When upgrading the PHP version alone isn’t enough: if the underlying server infrastructure (processor, memory, storage speed) hasn’t been sized in proportion to the store’s actual traffic and catalog size, because in that case the upgrade only brings partial improvement.
Which fix order is the right choice for a slow store
The right choice is never for the executive to try to fix every issue at once, but to tackle the 7 most common server and code issues in a weighted order, moving from the factors with the greatest business impact to the smaller ones. In our experience, most successful performance improvements start with configuring the Varnish cache correctly, because that single step alone makes a dramatic difference in load time, followed by a review of slow MySQL queries and the OpenSearch configuration, which become an ever-greater burden as the catalog grows. In a large share of cases, image optimization, a proper Redis setup and phasing out unnecessary modules are complementary steps that individually have a smaller impact but together make a significant difference to the final user experience. It is important to remember that an outdated PHP version and undersized server infrastructure fundamentally limit the effectiveness of all other optimizations, so a truly comprehensive performance overhaul must not ignore this layer either, even if its symptoms are less conspicuous than a missing cache or slow search.
In our experience, most clients achieve lasting improvement when they don’t treat these issues as a one-off fix, but maintain the system as part of continuous, metrics-driven monitoring. Who a one-off, ad hoc performance fix isn’t right for: companies that regularly expand their catalog or prepare for seasonal traffic peaks, because for them even a previously well-tuned Varnish, MySQL and OpenSearch configuration can gradually become undersized as they grow. The right choice, then, isn’t a single technical trick, but a structured, prioritized fix order that starts with the highest-impact server and code issues and, through continuous monitoring, keeps the Magento 2 store fast and reliable in the long run.
