Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
The fastest wins in Magento speed optimization are almost always on the server side and are cheap: serve pages from full page cache, run production mode, use Valkey for cache and sessions, and keep PHP current with OPcache. After that, most remaining slowness comes from the frontend: heavy JavaScript, unoptimized images and third-party scripts. Work in that order, measure each change, and you avoid spending weeks on fixes that move nothing.
Below are 25 fixes ranked by typical impact and effort, each with a way to verify it worked. The impact and effort ratings are Mistri's editorial judgment based on common patterns, not measured benchmarks or a guarantee; your own measurements decide what matters on your store.
Measure before you fix
Speed has two sides, and they need different tools.
- Server response time (time to first byte): how long Magento takes to produce the HTML. Measure with a profiler or APM, server logs and repeated requests with and without cache.
- Page experience: how fast the page renders and responds in a real browser. Google's Core Web Vitals measure this at the 75th percentile of real visits: LCP of 2.5 seconds or less, INP of 200 ms or less and CLS of 0.1 or less count as good.
Record a baseline for your key templates (home, category, product, cart, checkout) using field data from the Chrome UX Report or your own real-user monitoring, plus lab runs in Lighthouse for debugging. Test with a cold and warm cache. Our Core Web Vitals guide for Magento explains how to read each metric.
25 fixes ranked by impact and effort
| # | Fix | Impact (editorial) | Effort (editorial) | How to verify |
|---|---|---|---|---|
| 1 | Serve pages from full page cache (Varnish on-premises, Fastly on Adobe Commerce on Cloud) | High | Low | Second request to a category page returns a cache hit header; server response time drops sharply |
| 2 | Run in production mode | High | Low | bin/magento deploy:mode:show reports production |
| 3 | Use a supported PHP version with OPcache enabled and sized for the codebase | High | Low | OPcache status shows no restarts from a full cache; PHP 8.5 for 2.4.9 |
| 4 | Store default cache and sessions in Valkey instead of the file system | High | Low | app/etc/env.php shows the Valkey backend; disk I/O falls |
| 5 | Remove cacheable="false" blocks that make whole pages uncacheable | High | Medium | Search layouts for the attribute; cache hit rate rises on affected templates |
| 6 | Audit and remove unused or heavy extensions | High | Medium | Fewer modules in config.php; profiler shows fewer observers and plugins per request |
| 7 | Cut and delay third-party scripts (chat, reviews, tag manager tags) | High | Low to medium | Lab Total Blocking Time and field INP improve |
| 8 | Optimize the LCP image: right size, modern format, not lazy-loaded, high fetch priority | High | Low | Lighthouse identifies the LCP element and its load delay shrinks |
| 9 | Put static and media files behind a CDN | High | Low | Asset responses show CDN cache headers; faster loads from distant regions |
| 10 | Profile slow server code with an APM or profiler | High | Medium | Slowest transactions identified and fixed one by one |
| 11 | Move to a lighter frontend (Hyvä or Breeze) if Luma JavaScript is the bottleneck | High | High | Field LCP and INP in CrUX or RUM data after launch |
| 12 | Set indexers to Update by Schedule and make sure cron runs | Medium to high | Low | bin/magento indexer:show-mode; no growing backlog |
| 13 | Warm the cache after deploys and flushes | Medium | Low | First visitors after a deploy get cache hits on top pages |
| 14 | Clean specific cache types instead of flushing everything | Medium | Low | Deploy scripts and admin habits use cache:clean with types |
| 15 | Follow Adobe's JS guidance: do not merge JS; avoid merge and bundling on HTTP/2 | Medium | Medium | Network waterfall shows fewer blocking scripts; no RequireJS errors |
| 16 | Use critical CSS and defer the rest | Medium | Low | Render-blocking CSS warnings disappear in Lighthouse |
| 17 | Set width and height on images and reserve space for banners | Medium | Low | CLS under 0.1 in field data |
| 18 | Lazy-load below-the-fold images only | Medium | Low | Above-the-fold images load eagerly; offscreen images defer |
| 19 | Tune MySQL or MariaDB (buffer pool, slow query log) | Medium | Medium | Slow query log shrinks; database time per request falls |
| 20 | Size OpenSearch properly and keep it healthy | Medium | Medium | Search and category response times stable under load |
| 21 | Enable asynchronous order email sending and grid indexing | Medium | Low | Checkout and admin saves are faster; emails still send via cron |
| 22 | Trim layered navigation and product list sizes | Medium | Low | Category page server time and DOM size fall |
| 23 | Enable HTTP/2 or HTTP/3 and Brotli or gzip compression | Medium | Low | Response headers show protocol and content encoding |
| 24 | Clean oversized tables (old quotes, logs, cron history) | Low to medium | Low | Table sizes reduced; backups and some queries faster |
| 25 | Self-host and preload key fonts with font-display swap | Low to medium | Low | No late text swap shift; fewer third-party requests |
Impact means the typical effect on page speed for a store where the fix is missing. Effort is relative: "low" is configuration, "medium" needs a developer for days, "high" is a project.
Server and caching fixes (1–5, 12–14)
Full page cache is the foundation
With full page cache working, most category, product and CMS pages are served without running Magento's PHP stack. Adobe recommends Varnish for on-premises stores; Adobe Commerce on Cloud uses Fastly. The common failure is not missing Varnish but pages that never get cached: a single block marked cacheable="false" in a layout makes every page using that layout uncacheable. Our guide to Magento caching with Varnish and Valkey covers each layer and how invalidation works.
Production mode and PHP
Developer mode compiles and generates files on the fly and shows detailed errors. It is far slower and should never run on a live store. Production mode serves precompiled code and static files. Pair it with a supported PHP version (2.4.9 requires PHP 8.5) and OPcache configured with enough memory for Magento's large codebase.
Valkey for cache and sessions
Since 2.4.9, Adobe's CLI tooling uses Valkey in place of Redis for cache and session configuration. Keeping cache and sessions in memory removes a lot of disk I/O, especially on shared or network storage.
bin/magento setup:config:set --cache-backend=valkey --cache-backend-valkey-server=127.0.0.1 --cache-backend-valkey-db=0
bin/magento setup:config:set --session-save=valkey --session-save-valkey-host=127.0.0.1 --session-save-valkey-db=2Indexers, cron and cache habits
Indexers set to "Update on Save" reindex during admin saves and imports, slowing both. "Update by Schedule" moves the work to cron. Also check how your team clears cache: a full flush after every content edit throws away the page cache and makes the next visitors pay for rebuilding it. Clean specific cache types instead, and warm top pages after deploys.
Code and extension fixes (6, 10, 19–22, 24)
Every extension can add plugins, observers, layout blocks and JavaScript. One poorly written observer on a frequently dispatched event can slow every request. Use a profiler to find the slowest transactions and methods, then decide per extension: fix, replace or remove. Disabled extensions still deserve removal from the codebase, because they still have to be maintained and upgraded.
On the database side, check the slow query log, the buffer pool size and the size of tables that grow without limit, such as old quotes and cron history. Make sure OpenSearch has the memory it needs; slow search affects both search results and category pages. Adobe's configuration best practices also recommend asynchronous email sending and asynchronous grid indexing for busy stores.
Frontend fixes (7–9, 11, 15–18, 23, 25)
Images
The largest image above the fold is often the LCP element. Serve it at the displayed size in a modern format, do not lazy-load it, and consider fetchpriority="high". Lazy-load images further down the page, and always set width and height so the layout does not shift.
JavaScript
The Luma theme loads many JavaScript modules through RequireJS and Knockout, which costs time on slower phones. Adobe's guidance is not to enable "Merge JavaScript Files", and not to merge or bundle files if your site uses HTTP/2. Third-party scripts often cost more than Magento's own, so audit every tag and remove or delay what does not earn its place.
Change the frontend
When the theme itself is the bottleneck, replacing it is the highest-impact and highest-effort fix on this list. Hyvä replaces Luma's frontend stack with Alpine.js and Tailwind CSS, and Breeze keeps Luma's templates while replacing its JavaScript layer. Our Hyvä vs Breeze vs Luma comparison helps decide between them.
Hosting and infrastructure (9, 23)
A CDN for static and media files helps every visitor far from your origin. HTTP/2 or HTTP/3 and Brotli or gzip compression are usually configuration changes. If the server itself is undersized, no amount of tuning will compensate; the Magento hosting guide has a checklist for evaluating capacity.
A sensible order of work
- Measure the baseline (field and lab, server and browser).
- Confirm the quick configuration items: 1–4, 12, 14, 21, 23.
- Fix cacheability (5) and warm the cache (13).
- Profile and fix server code and extensions (6, 10, 19, 20).
- Fix images, fonts and third-party scripts (7, 8, 17, 18, 25).
- Decide on JavaScript strategy or a frontend change (11, 15, 16).
- Measure again with field data after a few weeks; lab scores alone can mislead.
Frequently asked questions
Why is my Magento store slow even with Varnish?
Usually because many pages are not being cached (uncacheable blocks, cookies or query strings that bypass cache), or because the slowness is in the browser, from JavaScript and images, not on the server.
Will a PageSpeed score of 100 make my store fast?
Not necessarily. Lighthouse is a lab test on one simulated device. Google's Core Web Vitals use field data from real visitors, which is what to optimize for.
Should I upgrade Magento to improve speed?
Upgrades bring supported PHP and service versions, which helps, but they are rarely the main fix on their own. Upgrade for support and security, and treat performance as a separate, measured project.
Get help with the heavy lifting
Mistri's Magento performance optimization work follows the same order: measure, fix cacheability and server time, then tackle the frontend, with each change verified against field data.
Sources
Performance best practices overview (Adobe Experience League); Optimize resource files (Adobe Experience League); Use Valkey for page cache (Adobe Experience League); Web Vitals (web.dev).
