Magento performance is solvable. Every site we have audited since 2019 was reaching mobile Lighthouse 70-plus by the end of the engagement, regardless of starting score. The hard part is not finding the bottlenecks. The hard part is the discipline of measuring, fixing, and not letting them creep back.
This guide covers the Core Web Vitals targets that matter, the common causes of poor Magento scores, and the order of operations we follow on a performance engagement.
What you are actually measuring
Google's Core Web Vitals replaced the older "load time" metric with three signals that map closer to user experience:
- LCP (Largest Contentful Paint): when the biggest element above the fold becomes visible. Target: under 2.5 seconds on mobile. Industry leaders: under 1.5 seconds.
- INP (Interaction to Next Paint): how long interactions block the main thread. Target: under 200ms. Replaced FID in March 2024.
- CLS (Cumulative Layout Shift): how much content jumps around during load. Target: under 0.1. Sites with banners loading after first paint often blow this.
Lighthouse Performance is an aggregate score (0-100) weighted across these three plus a few supporting metrics. A score of 90 on mobile is the cutoff for "fast" in Google's classification.
Where Magento stores typically score
- Untouched Luma store: 30 to 55 mobile.
- Luma with optimization: 55 to 75 mobile.
- Hyvä default: 80 to 92 mobile.
- Hyvä with heavy third-party modules: 65 to 82 mobile.
- Hyvä properly maintained: 85 to 95 mobile.
Note the overlap. A well-tuned Luma can beat a poorly-maintained Hyvä. The platform sets the ceiling; discipline determines where within the ceiling you actually land.
The order we fix things
Performance work has a strict order of operations. Do the lower steps before the higher ones; doing them out of order wastes effort.
1. Server response time
TTFB (Time to First Byte) is the floor. Nothing else matters if the server takes 2 seconds to respond. Target: under 600ms TTFB for cached pages, under 1.2s for uncached.
Common Magento TTFB issues:
- Redis or Varnish full-page-cache misconfigured (TTL too short, cache not warming).
- PHP version below 8.1 (each minor PHP release after 8.0 ships meaningful performance gains).
- Database queries not indexed properly on the catalog or order tables.
- Module event observers running synchronously on every request.
Fix TTFB first. The rest of the audit depends on it.
2. Render-blocking resources
After TTFB, look at what's blocking the browser from painting. Three culprits dominate:
- Synchronous JavaScript in the head. Especially analytics, tag managers, A/B tooling loaded without async or defer. Move to post-paint.
- External fonts loaded synchronously. Use
font-display: swaporfont-display: optional. Preload critical fonts. - Unminified critical CSS. Magento ships megabytes of CSS in the default build. Hyvä's Tailwind output is closer to 30KB. Either way, inline the critical path.
3. Image pipeline
Images account for 50-70 percent of page weight on a typical Magento product page. Wins available:
- Modern formats. WebP saves 25-35 percent vs JPEG at equivalent quality. AVIF saves another 20-30 percent but has thinner browser support. Serve WebP with a JPEG fallback.
- Intrinsic dimensions. Always declare width and height. Prevents layout shift. Reduces CLS to near zero on product pages.
- Lazy load below the fold. Use the native
loading="lazy"attribute. Eager-load only the hero image and above-fold thumbnails. - Responsive sizes. Don't serve a 3200×3200 hero image to a 375-wide mobile viewport. Use the
srcsetattribute with breakpoints.
4. Third-party scripts
Almost every Magento store carries a tail of analytics scripts: GA4, GTM, Meta Pixel, TikTok Pixel, Hotjar, LiveChat, Klaviyo, and so on. They add up.
The rule we apply: every third-party script must justify its main-thread cost. Audit the list. Each one should answer:
- What decision does the data we get from this script drive?
- How much main-thread time does it cost?
- Could the same data come from a server-side equivalent?
Most stores can cut their third-party JS by 40-60 percent without meaningfully losing data. Use Google Tag Manager server-side or Customer.io's server pipeline to replace browser pixels.
5. JavaScript bundle size
Magento's default frontend ships hundreds of KB of Knockout, RequireJS, jQuery, and module-specific code. Hyvä ships ~30KB of Alpine.js. The difference is roughly 5x in JavaScript parse and execution time.
If you are on Luma and not migrating to Hyvä, the JavaScript wins are limited. Audit module-loaded JS specifically. Often a third-party module is loading its full library on every page, when it only fires on product pages.
The Magento-specific traps
Cache hit rate
Magento's Varnish or Redis full-page cache should hit 95-plus percent of catalog requests. If your cache hit rate is below 80 percent, your TTFB is bottlenecked.
Common cause: cache invalidation on every product price update, triggered by a module that updates prices too aggressively. Fix: debounce price updates and use tag-based invalidation.
Catalog product view rendering
Product pages can take 500ms to 2s to render server-side because of related-product queries, custom attribute rendering, and image path resolution. Profile with Blackfire or New Relic. The 80-20 rule applies: usually one block dominates the render time.
Customer-section AJAX
Magento makes a customer-section AJAX call on every page load to get cart count, customer name, and a few other fragments. This request often blocks interaction even though the page is visually ready.
Optimize by reducing the response payload, batching customer-section requests, or pre-rendering cart state in the page HTML.
What it costs
Performance engagements are usually billed by milestone:
- Audit: £1,500 to £3,500. Reference-store measurement, third-party module analysis, deliverable report.
- Quick wins: £4,000 to £8,000. Image pipeline, lazy-loading, deferred analytics, font display. Typical lift: 10 to 25 Lighthouse points.
- Deep work: £8,000 to £25,000. Cache rebuild, module refactoring, custom optimizations, Hyvä migration consideration. Typical lift: another 15 to 30 points.
Past Lighthouse 90 mobile, further wins cost increasingly more per point. Most stores stop at 85-90 because the next 5 points cost as much as the first 20.
FAQ
How much can performance really move conversion?
Industry studies (Akamai, Google, Cloudflare) converge on roughly 1 percent conversion lift per 100ms of LCP improvement, up to about 2.5 seconds. Past that, the curve flattens. For a £1M store, each 100ms is worth ~£10,000 annually.
Is Hyvä always the right answer?
No. Hyvä gives you a higher performance ceiling but the migration cost is real. For stores already at 70+ Lighthouse, the gap to Hyvä's 85+ is 15 points, worth maybe £30,000-50,000 annually for a mid-market store. Whether that justifies a £20,000 migration depends on the timeline you measure over. We have a detailed guide on the Hyvä migration trade-off.
What about Core Web Vitals on desktop?
Desktop almost always scores 20-30 points higher than mobile on Lighthouse. Mobile is the harder target and the one Google ranks you on for mobile-first indexing. Focus mobile first; desktop usually follows.
How often should we audit?
Continuous monitoring (PageSpeed Insights or Web Vitals API) on every release. Full audit annually, or after any major change (theme migration, new payment integration, big catalog import).
Quick wins to start tomorrow
- Add
loading="lazy"to all below-fold images on category and product pages. - Move analytics scripts to load after page interactive (not in the head).
- Add
font-display: swapto all custom font declarations. - Enable WebP delivery via your image CDN or a Magento extension.
- Audit your Redis cache TTLs and hit rate; raise TTLs if traffic patterns allow.
Each of these is 1 to 4 hours of work and typically moves Lighthouse by 5 to 15 points cumulatively.
For a full audit on your store, the Magento Health Check service delivers a written report and prioritized fix list within 5 business days.