If your Magento 2 store is slow, Google already knows. So do your customers — 1 in 4 visitors abandons a page that takes more than 4 seconds to load. On mobile, that window narrows further.
Slow Magento 2 sites aren’t just frustrating. They cost you rankings, conversions, and ad spend. A store that Google scores poorly for Core Web Vitals pays higher effective CPCs and ranks lower in organic results simultaneously. It’s a double hit most owners don’t connect.
The good news: Magento 2 performance issues are diagnosable. This guide walks you through a practical audit — what to check, what the numbers mean, and when the problem is bigger than a quick fix.
Start Here: Your Baseline Check
Before you dig into code or configuration, get a number to work from.
Google PageSpeed Insights (pagespeed.web.dev) is your first stop. Run your homepage and your highest-traffic product/category page. You’re looking at two scores: mobile and desktop. The mobile score is the one that matters for rankings.
Core Web Vitals — the metrics Google uses:
| Metric | What it measures | Good score |
|---|---|---|
| LCP (Largest Contentful Paint) | How fast the main content loads | < 2.5 seconds |
| INP (Interaction to Next Paint) | How responsive the page is to clicks | < 200ms |
| CLS (Cumulative Layout Shift) | Whether elements jump around as page loads | < 0.1 |
If you’re scoring below 50 on mobile PageSpeed, or your LCP is above 4 seconds, you have a performance problem that’s actively costing you. If you’re in the 50–89 range, there are improvements worth making. 90+ is where you want to be.
GTmetrix (gtmetrix.com) gives you a more detailed waterfall view — useful for identifying which specific requests are blocking page load. Run the same pages here for a second opinion.
The Six Most Common Magento 2 Performance Killers
In my experience auditing Magento 2 stores, the same issues come up again and again. These are the culprits worth checking first.
1. Unoptimised images and no WebP
Images are the single biggest contributor to slow LCP scores on most Magento 2 stores. The problem isn’t just file size — it’s format. If your store is still serving JPEGs and PNGs without WebP conversion, you’re serving files 25–35% larger than necessary to every browser that supports WebP (which is all of them now).
Check: open Chrome DevTools → Network tab → filter by Img. Sort by size. Any image over 150KB on a product page is a candidate for compression. Any image not in WebP format on a store built after 2021 is an oversight.
2. Too many third-party extensions
Every Magento extension that loads on the frontend adds JavaScript. Enough of them and you have a JS execution time problem that drags INP scores down and pushes LCP up. This is particularly acute on older stores that have accumulated extensions over several years without auditing what’s still in use.
Check: GTmetrix waterfall view → sort by duration → identify third-party requests. Extensions loading 100KB+ of JS on every page load are the usual suspects.
3. Poor hosting configuration (and shared hosting)
Magento 2 is resource-intensive. It’s not a platform you can run meaningfully on shared hosting — the response times are too slow and the server configuration (PHP-FPM, Redis, Varnish) rarely matches Magento’s requirements out of the box. If you’re on shared hosting, this is likely the root cause of your speed issues, not your theme or extensions.
Check: Time to First Byte (TTFB) in PageSpeed Insights. Over 600ms TTFB = server problem, not front-end problem. No amount of image optimisation fixes a slow TTFB.
4. JavaScript and CSS not minified
Magento 2’s built-in production mode handles JS and CSS merging and minification. If your store is still running in developer mode — which happens more often than it should on live stores — you’re loading unminified assets. The difference in page weight can be dramatic.
Check: Magento Admin → System → Cache Management. If Full Page Cache isn’t enabled, that’s a problem. Verify via bin/magento deploy:mode:show — should be production on a live store.
5. Full Page Cache misconfiguration
Magento’s Full Page Cache (FPC) is one of the most effective performance tools in the platform when it’s working correctly. When it isn’t, every page request hits the server cold — no cached response, maximum load time.
Check: PageSpeed Insights → “Reduce server response times” recommendation. If it’s flagging consistently, FPC may not be working as intended. Varnish on top of FPC is the correct production setup for any store with meaningful traffic.
6. Heavy theme — Luma vs Hyvä
The default Luma theme is Magento 2’s original frontend — it was designed in 2015 and built around technologies that predate modern performance standards. If you’re still on Luma (or a heavily customised Luma child theme), your Core Web Vitals ceiling is limited regardless of other optimisations.
Hyvä Theme is the current standard for performance-focused Magento 2 development. It strips out RequireJS and jQuery in favour of lightweight Alpine.js and Tailwind, cutting front-end weight dramatically. Stores that migrate from Luma to Hyvä typically see 40–60% LCP improvements without changing a line of back-end code.
If your performance audit reveals that you’re already doing everything right on images, extensions, hosting, and caching — but still failing Core Web Vitals — the theme is almost certainly the bottleneck.
The Hidden Performance Killer — Feed Health
One area that rarely appears in Magento performance guides but absolutely belongs in your audit: product feed health.
If you’re running Google Shopping or Microsoft Shopping ads, your product feeds are making HTTP requests to your server on Merchant Centre’s schedule. A slow or misconfigured feed doesn’t just cost you ad performance — it’s putting load on your server and can pull resources away from serving actual customers.
What to check:
- Google Merchant Centre → Diagnostics: Look for crawl errors, timeout responses, or slow feed fetch times. If GMC is timing out when fetching your feed, your server is struggling under the request load.
- Linnworks feed sync frequency: If you’re using Linnworks for order and inventory management, check that your feed sync schedule matches your update cycle. Batch-daily updates on price-sensitive products mean your ads are running on stale data — and that’s a wasted spend problem on top of a performance problem.
- Product count discrepancy: Compare the item count in your Magento catalogue against the count in your live feed. A significant discrepancy (more than 5%) usually means feed errors are suppressing products — a data quality issue with performance and commercial consequences.
This is a detail most performance audits skip. It’s also something our ecommerce consultancy service addresses as part of a full Magento setup review — because performance and feed infrastructure are connected, not separate problems.
How to Run Your Magento 2 Performance Audit (Step by Step)
Here’s a structured walkthrough — roughly in order of effort:
Step 1: Run PageSpeed Insights on 3 pages
Homepage, top-selling category page, and a representative product page. Note the mobile score and all three Core Web Vitals. If LCP > 4s on any of them, flag it.
Step 2: Check TTFB
PageSpeed Insights will flag if your TTFB is above 600ms. A high TTFB points to server/hosting issues, not front-end problems. Fix server before fixing front-end.
Step 3: Run GTmetrix waterfall
Identify the largest requests and the slowest-loading assets. Look for patterns — are third-party scripts loading first? Are images above the fold loading last?
Step 4: Audit images
Chrome DevTools → Network → filter Img → sort by size. Any uncompressed image over 150KB gets flagged. Check whether WebP is being served (look at the Content-Type in the response headers).
Step 5: Check deploy mode and FPCbin/magento deploy:mode:show → should be production. Admin → System → Cache Management → Full Page Cache should be enabled and showing hits, not misses.
Step 6: Check for extension bloat
GTmetrix → waterfall → third-party requests. Count how many external JS files are loading and from where. If you can’t name the extension behind each file, you have an audit item.
Step 7: Check feed health
Google Merchant Centre → Diagnostics. Note any feed errors, fetch timeouts, or disapprovals that could indicate server stress or data quality issues.
Step 8: Record your findings
Document each issue with a severity (critical/moderate/minor) and an estimated fix effort. This gives you a prioritised action list — and if you’re getting a quote from a developer, it’s a clear brief.
When to DIY and When to Call in a Specialist
Some of this you can tackle yourself. Some of it you shouldn’t.
DIY-able:
- Image optimisation (tools like Squoosh or TinyPNG, or a Magento image optimisation extension)
- Identifying the issues (that’s what this audit is for)
- Disabling extensions you know you don’t use
- Checking GMC feed diagnostics
Bring in a specialist for:
- Hosting configuration changes (PHP-FPM workers, Varnish setup, Redis configuration)
- FPC issues — these are easy to misdiagnose and worse to break
- JS/CSS pipeline problems
- Theme migration (Luma → Hyvä is a development project, not a config change)
- Any changes to your production environment that affect checkout
The honest version: most Magento 2 performance problems I see are fixable. But they’re fixable by someone who knows the platform deeply — not by following a generic WordPress speed guide adapted for Magento.
Performance issues also affect your SEO directly. A slow site loses rankings and Quality Score — which means your SEO investment works less efficiently when the technical foundation isn’t solid. It’s one of the first things I check when a client’s organic traffic has plateaued without an obvious content explanation.
The Fastest Route to Green Core Web Vitals on Magento 2
If your audit reveals that you’re doing everything right — images are optimised, hosting is solid, FPC is running — but you’re still failing Core Web Vitals, the answer is almost always the theme.
Migrating from Luma to Hyvä is the single most impactful performance change available to a Magento 2 store today. It’s not a patch — it’s a rebuild of the front-end on a leaner architecture. The performance difference is measurable and consistent.
If you’ve run through this audit and want an expert view on where your store stands, get in touch. I’ve done this for a lot of Magento stores and can usually identify the root cause quickly.