Language: English
Request a service

Why Is My Magento 2 Store Slow? 12 Common Causes and How to Fix Them

A slow Magento 2 store is rarely one big problem. It is usually several small ones stacked together. Here are the 12 causes I find most often and how to fix each.

Hasan Gültekin6 min read

If your Magento 2 store feels slow, you are not imagining it, and you are not alone. Magento is a powerful platform, but that power comes with many moving parts. When a store is slow, it is almost never one single problem. It is usually five or six smaller issues stacked on top of each other.

In this guide I walk through the 12 causes I find most often when auditing Magento 2 stores, how to recognise each one and what to do about it. You can use it as a checklist for your own team.

First: measure before you change anything

Before touching code or servers, get a baseline. Otherwise you will never know which change actually helped.

  • Time to First Byte (TTFB) on a cached and an uncached category page
  • Core Web Vitals (LCP, INP, CLS) from real users in Google Search Console or the CrUX report
  • Server-side profiling with a tool such as New Relic, Blackfire or Tideways
  • Cache hit rate of your full page cache (Varnish or the built-in cache)

Write these numbers down. Every fix below should move at least one of them.

1. Full page cache is not really working

This is the number one cause. Varnish is installed, but most pages are still built by PHP on every request. Common culprits:

  • A block somewhere on the page is marked cacheable="false", which makes the whole page uncacheable
  • Customer-specific data is rendered on the server instead of loaded through private content (customer sections)
  • Tracking parameters such as utm_source or gclid create a new cache entry for every visit

Fix: search your layout XML for cacheable="false", move personalised content to customer sections, and strip marketing parameters in your Varnish configuration so they do not split the cache.

2. Production mode is not enabled

It sounds basic, but I still find stores running in default or developer mode. Static files are generated on the fly and errors are verbose.

Fix: run bin/magento deploy:mode:show. If it does not say production, switch it as part of a proper deployment.

3. Too many third-party extensions

Every extension adds observers, plugins and sometimes extra database queries to every request. Twenty extensions doing “small” things can add seconds.

Fix: list every module with bin/magento module:status, remove anything you do not use, and profile the rest. Pay special attention to extensions that hook into product collection loading or the checkout.

4. A heavy frontend theme (Luma and its children)

The default Luma frontend loads RequireJS, Knockout and jQuery, often with hundreds of JavaScript files. On mobile devices this hurts Largest Contentful Paint and Interaction to Next Paint badly.

Fix: short term, bundle and defer what you can. Long term, the most effective option is moving to a lighter frontend such as Hyvä. I wrote a separate guide on Luma to Hyvä migration with costs, timelines and risks.

5. Unoptimised images

Product images uploaded straight from a camera or supplier feed can be several megabytes each.

Fix: serve modern formats (WebP or AVIF), use responsive srcset sizes, lazy-load images below the fold and never lazy-load the main product image, which is usually your LCP element.

6. Slow or misconfigured database

MySQL or MariaDB running with default settings is a common bottleneck, especially on large catalogs.

Fix: tune innodb_buffer_pool_size so your working dataset fits in memory, enable the slow query log and look at what shows up. Keep the database on fast NVMe storage.

7. Indexers running “Update on Save” during busy hours

When indexers are set to “Update on Save”, every product save in the admin can trigger heavy reindexing while customers are browsing.

Fix: switch indexers to “Update by Schedule” and make sure cron is running reliably. Check bin/magento indexer:status for indexes stuck in a “processing” state.

8. Cron problems

Magento depends on cron for indexing, emails, cache cleaning and much more. A broken or overlapping cron quietly makes everything slower.

Fix: check the cron_schedule table for jobs piling up in “pending” or “running” state, and clean up old entries.

9. Redis not used (or shared badly)

Sessions and cache stored on the file system become slow under load.

Fix: use Redis for cache and sessions, ideally separate instances, so a cache flush never logs out your customers.

10. Search engine under pressure

OpenSearch (or Elasticsearch on older versions) powers catalog search and, on many setups, layered navigation. Too little memory makes category pages slow.

Fix: give the search engine dedicated memory, monitor its heap usage and keep it on the same network as your web servers.

11. Large catalog imports during the day

Big product or price imports lock tables and invalidate caches. If they run at 11:00 on a Monday, your customers feel it.

Fix: run imports at night, import in batches, and avoid full cache flushes after every import. Clean only the tags that changed.

12. Under-sized or outdated hosting

Sometimes the server really is the problem: old PHP versions, too few PHP-FPM workers, or shared hosting that was never meant for Magento.

Fix: run a supported PHP version, size PHP-FPM workers for your traffic, and put a CDN in front of static assets. Hardware alone rarely fixes a slow store, but bad hardware can slow down a good one.

A practical order of work

If you are not sure where to start, this order gives the biggest gains for the least risk:

  1. Fix full page cache hit rate
  2. Confirm production mode, Redis and cron
  3. Remove unused extensions
  4. Optimise images and the LCP element
  5. Tune database and search
  6. Plan a frontend upgrade (for example to Hyvä)

Frequently asked questions

How fast should a Magento 2 store be?

Aim for a cached TTFB well under half a second and Core Web Vitals in the “good” range for most real users: LCP at or below 2.5 seconds, INP at or below 200 ms and CLS at or below 0.1.

Will more server power fix a slow Magento store?

Usually only partly. If the full page cache is missing most requests, a bigger server just runs slow code a little faster. Fix caching and code first.

Is Magento 2 still a good choice in 2026?

For stores with complex catalogs, B2B needs or multiple storefronts, yes. It does need regular technical care, which is why performance work should be planned, not reactive.

Need a second pair of eyes?

I help store owners and e-commerce teams find and fix exactly these problems, from Varnish configuration to full Hyvä migrations. If your store is slow and you want a clear, prioritised plan, take a look at my Magento 2 and Hyvä service or request a performance audit.