Magento has a reputation for being slow. In my article on why people hate Magento I explained where that reputation comes from: the platform is built to model almost any catalog, pricing rule and store view you can imagine, and it pays for that flexibility at runtime. A default install on modest hardware will crawl.
The good news is that Magento speed is a solved problem. A properly configured production store on the right stack is genuinely fast, and most slow Magento stores are slow for a handful of predictable reasons. This guide walks through how to get from a sluggish default to a fast production store, in the order I actually work through it when I audit a store. The focus is Magento 2 and Adobe Commerce, since Magento 1 has reached end of life.
Start by measuring, not guessing
Before changing anything, find out where the time actually goes. Optimizing blind is how teams spend a week on the wrong thing. Put real numbers on the problem first:
- Application profiling with a tool like New Relic APM or Blackfire, so you can see which requests, queries and code paths are expensive.
- The database, using the MySQL slow query log to catch queries that need indexes or are being run too often.
- The frontend, using Lighthouse, PageSpeed Insights or WebPageTest, and watching the Core Web Vitals: Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint.
Take a baseline now so that every change later can be measured against it. If you cannot measure the improvement, you cannot claim it.
Run Magento in production mode
A surprising number of slow stores are simply running in the wrong mode. Developer mode disables key optimizations and is not meant for live traffic. For production you want:
- Production mode enabled (
bin/magento deploy:mode:set production), which compiles dependency injection and serves pre-generated static content instead of building it on the fly. - Static content deployed and dependency injection compiled as part of every deploy.
- Indexers set to “Update on Schedule” rather than “Update on Save”, so indexing runs in the background on cron instead of blocking every admin save.
- Cron running correctly, because Magento relies on it for indexing, cache flushing and many background jobs. A broken cron quietly degrades everything.
Cache aggressively
Caching is the single biggest lever in Magento performance. Out of the box Magento has a full page cache, but for production you should go further:
- Use Varnish for full page cache instead of the built-in PHP cache. Magento can generate the Varnish configuration for you, and a warm Varnish cache serves catalog and category pages in milliseconds without touching PHP at all.
- Move cache and sessions to Redis. Using Redis for the default cache, the full page cache metadata and session storage takes heavy load off the database and the filesystem.
- Understand hole punching. Dynamic blocks such as the cart or a logged-in greeting are loaded separately so the rest of the page can stay fully cached. If a store has broken this, cache hit rates collapse and you get the worst of both worlds.
When people say Magento is fast for them, this is usually the difference. A high full-page-cache hit rate is what turns the platform from slow to quick.
Fix the database and search layer
Magento is database heavy, so the data layer deserves real attention:
- Tune MySQL or MariaDB. Give the InnoDB buffer pool enough memory to hold the working set, and keep an eye on the slow query log. On large Adobe Commerce stores, splitting checkout and order data onto separate databases can relieve pressure on the main catalog database.
- Run a proper search engine. Recent Magento versions require OpenSearch or Elasticsearch for catalog search and layered navigation. Give it enough memory and keep it on its own resources, because a starved search cluster shows up as slow category pages.
- Keep indexers healthy. Stale or broken indexes cause slow queries and wrong results. Make sure indexing runs on schedule and completes.
Tune PHP and the web server
The runtime underneath Magento matters as much as Magento itself:
- Run a current PHP version supported by your Magento release. Each recent PHP release has been meaningfully faster than the last, so staying current is free performance.
- Enable OPcache and give it enough memory, and raise the realpath cache. Magento loads a lot of files, and caching that work pays off immediately.
- Size PHP-FPM correctly for your CPU and memory, so you have enough workers to handle concurrency without exhausting the server.
- Turn on HTTP/2 and compression (gzip or brotli) at the web server, and make sure keep-alive and sensible cache headers are set for static assets.
Optimize the frontend and assets
Even a fast backend feels slow if the browser has too much to download and render. On the frontend:
- Put a CDN in front of static and media assets so images, CSS and JavaScript are served close to the visitor.
- Optimize images. Serve modern formats such as WebP, size images to what the layout actually needs, and lazy load below-the-fold images. Oversized images are one of the most common Core Web Vitals problems.
- Reduce and defer JavaScript and CSS. Merge, minify and bundle where it helps, defer non-critical scripts, and be ruthless about third-party tags. Every marketing pixel and chat widget has a cost.
- Watch the theme. A heavy or poorly built theme can undo a lot of backend work. Keep the critical rendering path lean.
Audit your third-party extensions
This is the hidden cause behind more slow Magento stores than anything else. A single badly written extension can add expensive queries to every page, disable caching, or load blocking scripts across the whole site. When I audit a slow store, the extension list is one of the first places I look.
Review every installed module, measure the cost of the ones you suspect, and remove anything you do not truly need. Fewer, well-chosen extensions almost always beat a long list of convenient ones.
Do not overlook the hosting
Magento is not a platform that runs well on cheap shared hosting. It expects real resources: enough CPU and memory, fast storage, and ideally separate services for the database, Redis and search. If a store has outgrown its server, no amount of configuration will fully rescue it. Matching the infrastructure to the traffic and catalog size is part of the job, not an afterthought.
If you are still on Magento 1
Magento 1 reached end of life in June 2020. If your store is still on it, you are running unsupported software with no official security patches, and much of the modern performance tooling above simply does not apply. In that case the honest answer is that the best performance move is not another round of tuning, it is planning an upgrade to Magento 2 or a move to a platform that fits you better.
How I can help
Making Magento fast is methodical work, and it is exactly the kind of thing I do with teams. Depending on where you are, I can help you:
- Audit and optimize your current store. I profile the full stack, find where the time actually goes, and give you a prioritized plan to make the store fast and stable, without a rebuild.
- Upgrade to the latest version. If you are on Magento 1 or an old Magento 2 release, I help you plan and carry out the upgrade so you are supported, secure and on modern performance tooling.
- Move to another platform. If Magento is more than your store needs, I help you migrate to something simpler such as Shopify, WooCommerce or a headless setup, without losing your catalog, customers, orders or search rankings.
If your store is slow and you want a clear plan rather than guesswork, take a look at my consultancy page and get in touch.
Wrapping up
Magento speed is not magic. It is measurement, production configuration, aggressive caching, a healthy database and search layer, a tuned runtime, a lean frontend, a disciplined extension list, and hosting that fits. Work through those in order and a slow store becomes a fast one. Skip the measurement and you will spend a lot of effort in the wrong places.
For more of my Magento notes, see Why people hate Magento?, How to integrate Magento and Drupal?, 15 Questions about Magento Ecommerce System, and My Experiments with Open Source CMS and E-commerce Solutions.
A note on this article: this is a rewrite and expansion of a short link post I first published on this site back in 2012. I have updated it in 2026 to cover Magento 2 and Adobe Commerce performance in practical detail. If you are looking for the original list of tips that inspired the first version, search for Guido Jansen’s writing on Magento speed.
