Why Your Magento Store Is Slow (and the 7 Fixes That Work)
Why your Magento store is slow — and the seven fixes that work
Your Magento store is slow for one or more of seven reasons: slow server response, a heavy theme, render-blocking CSS and JavaScript, unoptimised images, too many extensions, layout shift, or the absence of edge delivery — and each has a specific, verifiable fix. Magento's reputation for slowness is really a reputation earned by default Magento: the engine is capable, but the typical configuration buries it under a heavy theme, sprawling extensions and untuned assets.
The deepest of these fixes — a headless front end — is how the AgenticEcom Suite storefront is built, but the other six work on any Magento store this week.
Diagnose before you spend
Ten minutes of measurement saves weeks of guessing. Run your homepage, a category page and a product page through PageSpeed Insights and note both the field data at the top — what real visitors experienced over the previous 28 days, which is the number Google actually judges — and the lab diagnostics below, which are the map of what to fix. Test all three page types, because they fail differently: homepages die on hero images and third-party tags, category pages on product-grid images and layout shift, product pages on gallery weight and configurable-product JavaScript. Then check raw server response from the command line:
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://www.yourstore.co.uk/
That number is your time to first byte (TTFB). Use this table to map symptoms to causes:
| Symptom | Likely cause | Fix number |
|---|---|---|
| TTFB over ~600ms | No full-page cache hit, weak hosting, stalled indexers | 1 |
| Page arrives fast but paints late | Render-blocking CSS/JS from the theme | 2, 3 |
| "Largest Contentful Paint element" is an image | Oversized or badly formatted images | 4 |
| Slow admin, slow everything, odd delays | Extension sprawl | 5 |
| Content visibly jumps while loading | Layout shift | 6 |
| Fast for you, slow for overseas customers | Single origin, no edge delivery | 7 |
1. Slow server response (TTFB)
If the server takes a second to start replying, nothing downstream can save the page. Confirm production mode with bin/magento deploy:mode:show — developer mode on a live store is a common and expensive mistake. Switch full-page caching to Varnish under Stores → Configuration → Advanced → System → Full Page Cache, put cache and sessions on Redis (set in app/etc/env.php via bin/magento setup:config:set), and verify every cache is enabled with bin/magento cache:status. Check cron is running: stalled indexers force Magento to compute prices and catalogue data live on every request. Finally, be honest about hosting — an oversold shared server caps everything else you do, and no software tuning compensates for contended CPU. A useful sanity check: if TTFB is fast for a cached page but slow the moment you add something to the basket, the bottleneck is PHP and database work, which points at hosting, Redis and extension sprawl rather than the frontend.
2. A heavy theme
Luma ships a large CSS and JavaScript payload, most of which a given page never uses, and every kilobyte costs parse time on a mobile CPU. A leaner theme helps; a step change comes from replacing the theme layer entirely with a headless front end that serves pre-rendered HTML and loads JavaScript only for the components that genuinely need it.
3. Render-blocking CSS and JavaScript
Stylesheets and scripts that must load before the browser can paint stall the entire render. Turn on minification — visible under Stores → Configuration → Advanced → Developer in developer mode, or directly in production: bin/magento config:set dev/js/minify_files 1, bin/magento config:set dev/css/minify_files 1, then bin/magento cache:flush. Leave built-in JavaScript bundling off unless you have measured a benefit; the single huge bundle it produces usually delays first paint. Then work through third-party tags — analytics, chat, heatmaps, retargeting — and defer or remove anything that does not pay its way.
4. Unoptimised images
Images are usually the largest assets on the page and the most common Largest Contentful Paint element, which makes them the highest-leverage single fix on most stores. Serve WebP or AVIF rather than JPEG or PNG, resize to the dimensions the layout actually displays instead of letting the browser scale down a full-size upload, lazy-load below the fold with loading="lazy" — never on the LCP image itself, which is one of the most common self-inflicted regressions — and give every image explicit width and height so the browser reserves its space. One caution: watch out for image extensions that convert formats but re-process the whole gallery on every cache flush; measure before and after installing anything.
5. Too many extensions
Every third-party module adds code, database queries, observers and risk, and the cost compounds quietly: five modules each adding 100 milliseconds have cost you half a second nobody can point to. List what is installed with bin/magento module:status, audit ruthlessly, and remove — not just disable in config — anything you no longer use. Prefer a small set of well-built modules from one vendor that tests them together over a sprawl of cheap ones that have never met.
6. Layout shift
Content that loads late and shoves the page around frustrates customers and fails the CLS threshold of Core Web Vitals. Reserve space for everything that arrives after first paint: width and height attributes on images, fixed-height containers for promo banners and review widgets, and font loading configured so text does not reflow when the web font lands. Each shift is individually visible in the PageSpeed Insights diagnostics, which makes this the most mechanical of the seven fixes.
7. No edge delivery
If every visitor hits one origin server, distance becomes latency: a shopper far from your data centre waits for a long round trip on every request, and no amount of origin tuning changes the speed of light. The fix is serving cached pages and assets from a CDN edge close to the customer — the model described in Magento on Cloudflare.
The pattern behind the seven
Look back over the list: fixes 2, 3, 4, 6 and 7 are all things a modern headless architecture handles by default. Pre-rendered HTML eliminates the render-blocking theme payload; an edge image CDN handles formats and sizing; static delivery from the edge removes the geography problem; and a properly built front end reserves layout space by design. You can chase each fix separately on a traditional theme and get a genuinely faster store — or change the architecture once and inherit most of them. A live client store built this way with the AgenticEcom Astro storefront passes all three Core Web Vitals in Google's field data on a catalogue of over 1,000 products, measured July 2026. The target thresholds and how they are judged are in Magento Core Web Vitals.
Where to start on Monday
Run the diagnosis above, then take the fixes in order — server response first, because nothing else shows its true effect until TTFB is healthy, then images, then the JavaScript layer. If after fixes 1–6 the theme is still the bottleneck, that is the signal the architecture, not the tuning, is the constraint. The Astro storefront exists for exactly that point: a finished headless front end where the remaining fixes are the default state rather than an ongoing project.
FAQ
Why is Magento so slow by default?
The engine is capable; the default configuration is not. A heavy Luma theme, render-blocking assets, unoptimised images, extension sprawl and single-origin hosting bury Magento's performance. Each cause is identifiable and fixable, starting with server response and images.
What is the single biggest Magento speed fix?
For most stores it is server response — production mode, Varnish full-page cache, Redis and working cron — because nothing else registers until the server answers quickly. After that, image optimisation usually moves the visible loading experience most.
How do I find out which problem my store has?
Run PageSpeed Insights on your homepage, a category page and a product page, and measure TTFB with curl. High TTFB points at caching and hosting; a late paint despite a fast response points at theme CSS and JavaScript; an image named as the LCP element points at image optimisation.
Will going headless fix my Magento speed?
It addresses most of the causes at once: a headless front end ships pre-rendered HTML with minimal JavaScript from the edge, which removes the theme payload, the render-blocking problem and the geography problem together. A live client store built this way passes all three Core Web Vitals in Google's field data (measured July 2026). Server-side hygiene — caching, cron, hosting — still matters for the backend APIs.
Do extensions really slow Magento down?
Yes, cumulatively. Each module adds code, queries and event observers on every request, so ten mediocre modules can cost more than one heavy one. Audit with bin/magento module:status and remove what you do not use rather than merely disabling it.