Page Load Cut From 4.2s to 1.8s.
Mobile Score From 54 to 91.
$68,000 Additional Revenue in Year One.
An Australian outdoor and lifestyle retailer's Magento store was haemorrhaging mobile conversions. Their audience was 74% mobile. Their mobile PageSpeed score was 54. Their cart abandonment rate was climbing every month. The upgrade wasn't optional — but the performance transformation is what made it pay for itself 8 times over.
A Mobile-First Audience on a Store Built for Desktop. Four Years Ago.
This outdoor and lifestyle retailer had built their Magento store in 2020 on version 2.4.3. At launch it was fast. Over 4 years, it had accumulated 58 active extensions, a large product catalogue with 12,000+ SKUs spanning 6 categories, and a homepage image slider that loaded 8 uncompressed hero images on every page visit. Nobody had touched the performance configuration since the initial build.
The problem was measurable and getting worse. Their Google Analytics showed 74% of sessions were mobile, but mobile conversion rate was 1.9% compared to 4.8% on desktop — a gap that widened every quarter. Session recordings showed mobile visitors abandoning product pages after the first scroll, with heatmaps showing almost zero engagement below the fold on mobile. The store was technically working. It was commercially failing on mobile.
The trigger for contacting us was a Google Search Console notification: Core Web Vitals failing on mobile for 89% of URLs. The store owner knew this was affecting search rankings. What he didn't know was exactly how much revenue the slow performance was costing him — until we showed him the calculation.
Every Core Web Vital Failing on Mobile. Here's What We Measured.
Before touching a single line of code, we ran a complete performance baseline across 12 representative URLs — homepage, category pages, product pages, and checkout. This gave us an objective before-state to measure improvements against. Every Core Web Vital was failing Google's threshold on mobile.
The 6 Performance Bottlenecks — Ranked by Revenue Impact
Our performance audit identified 6 distinct bottlenecks. We ranked them by revenue impact — not by technical severity — so the highest-value fixes were prioritised first. This is the order we tackled them.
No full-page cache (Varnish) configured — TTFB 2.8 seconds
Magento's full-page cache was installed but never configured. Every page request hit PHP and MySQL from scratch. 2.8-second TTFB meant the browser was waiting nearly 3 seconds before receiving a single byte of HTML. This alone explained the mobile abandonment pattern.
Fix: Varnish configured → TTFB dropped to 0.3s · Biggest single improvementHero image slider — 8 uncompressed JPEGs, 14.2MB total, no lazy loading
The homepage slider loaded all 8 hero images on initial page load. The largest was 3.8MB — a 6000×3000px photograph served at full resolution to mobile devices displaying it at 390px width. No WebP, no lazy loading, no preloading of the first image. This was the primary cause of the 8.4-second LCP.
Fix: WebP conversion + lazy load + preload first image → LCP 8.4s to 1.9s6 extensions loading render-blocking JavaScript on every page
A live chat extension, a product review widget, a loyalty points module, a recently viewed tracker, a size guide popup, and a social sharing bar were each loading full JavaScript bundles synchronously in the page head. Combined, they added 680ms of render-blocking time — meaning the browser couldn't display anything until all 6 scripts had downloaded and executed.
Fix: Deferred + async loading → INP 680ms to 94ms · 3 extensions replaced with lighter alternativesAll 12,400 product images served as PNG — no WebP, no responsive sizing
Every product image was served as full-size PNG regardless of the device or viewport requesting it. A mobile visitor viewing a product thumbnail was receiving a 2400×2400px PNG when the visible thumbnail was 200×200px. Total image payload on a typical category page: 18.4MB.
Fix: WebP + responsive srcsets → avg category page image payload 18.4MB to 1.2MBPHP 7.4 on end-of-life — 35-40% slower than PHP 8.3
Magento 2.4.3 was running on PHP 7.4 which reached end of life in December 2022. PHP 8.3 delivers 35-40% faster execution for Magento-style workloads through JIT compilation improvements and optimised internal functions. The upgrade to 2.4.8 allowed the PHP upgrade which alone contributed 22% of the total speed improvement.
Fix: PHP 7.4 → 8.3 via Magento 2.4.8 upgrade → 22% server execution speed improvementElasticsearch 7 — degraded performance and approaching end of support
Magento 2.4.3 used Elasticsearch 7, which was running with a sub-optimal index configuration — the reindex was running in real-time rather than scheduled, adding latency to every search and product filter interaction. Magento 2.4.8 uses OpenSearch 2.x which resolved this alongside a corrected index schedule.
Fix: Elasticsearch 7 → OpenSearch 2.x + scheduled reindex → search response 1.4s to 0.2sHow We Upgraded and Optimised in 5 Phases Over 6 Weeks
Week 1: Performance baseline + full audit
Ran Core Web Vitals measurements across 12 representative URLs. Conducted full extension compatibility audit for 2.4.8. Identified 6 performance bottlenecks ranked by revenue impact. Produced performance optimisation specification and presented revenue impact calculation to client — showing that the mobile conversion gap was costing approximately $5,600/month in recoverable revenue.
📋 Deliverable: Performance spec + revenue impact reportWeeks 2–3: Magento 2.4.8 upgrade on staging
Built staging environment mirroring production infrastructure on Cloudways Sydney. Resolved 14 extension compatibility issues found in audit. Upgraded PHP from 7.4 to 8.3. Migrated from Elasticsearch 7 to OpenSearch 2.x with corrected index configuration. Ran first performance baseline on staging — PHP upgrade alone improved TTFB by 22% before any other optimisation.
⚡ PHP 7.4 → 8.3: 22% server speed improvement immediatelyWeek 3–4: Performance optimisation layer
Configured Varnish full-page cache with correct TTL rules (TTFB dropped from 2.8s to 0.3s immediately). Converted all 12,400 product images to WebP with responsive srcsets — ran automated conversion using ImageMagick batch processing. Added preload hint for first hero image. Implemented lazy loading on all below-fold images. Replaced 3 heavy extensions with lightweight alternatives. Deferred and async-loaded remaining JavaScript bundles.
🖼️ Image payload: 18.4MB → 1.2MB · TTFB: 2.8s → 0.3sWeek 4–5: CLS fixes and checkout optimisation
Fixed all 0.48 CLS score by adding explicit width/height attributes to all images and reserving space for dynamically-loaded elements. Optimised the checkout flow specifically — deferred non-critical scripts, preloaded critical checkout fonts, and reduced checkout page weight from 4.2MB to 0.8MB. Checkout load time reduced from 5.1 seconds to 1.4 seconds.
🛒 Checkout load: 5.1s → 1.4s · CLS: 0.48 → 0.04Week 6: Production deployment + post-launch monitoring
Zero-downtime deployment using maintenance mode during off-peak window (3am AEST Sunday). Total downtime: 47 minutes. Ran full Core Web Vitals verification immediately post-launch — all 6 metrics passing. Submitted updated sitemap to Google Search Console. Set up 30-day post-launch monitoring dashboard. Mobile PageSpeed score confirmed at 91 within 24 hours of deployment.
✅ Mobile score 91 · All CWV passing · Zero rollback requiredSix Months After Launch — The Numbers That Matter
74% of sessions getting a broken experience
Google Search ranking improvement within 6 weeks
💰 Revenue Impact — 6 Months Post-Launch
The performance upgrade paid for itself in month 3. By month 6 it had returned 8× its cost.
What Every Magento Store Owner Should Know About Performance
Upgrade alone does not fix performance
The Magento version upgrade contributed roughly 25% of the total speed improvement — primarily through PHP 8.3 and better caching architecture. The other 75% came from the optimisation layer. Both are required.
TTFB is the most impactful single fix
Configuring Varnish full-page cache correctly turned a 2.8-second server response into 0.3 seconds. This one change improved every other metric because faster TTFB means the browser starts rendering sooner. Fix TTFB first.
Images are almost always the biggest payload problem
The move from uncompressed PNG to WebP with responsive srcsets reduced category page image payload from 18.4MB to 1.2MB — a 93% reduction. Most Magento stores have never done this conversion and are serving mobile visitors desktop-resolution images.
Slow mobile = lost Google rankings AND lost conversions
Google's Core Web Vitals directly influence search rankings. This store saw a 28% increase in organic mobile traffic within 6 weeks of launch — not from any SEO work, but from Google rewarding the improved CWV scores. Performance is SEO.
Measure revenue impact before you start — not after
Presenting a revenue impact calculation before the upgrade begins changes the conversation from cost to investment. Every 0.1s of improvement is worth approximately 0.7% in conversion rate. Quantifying this upfront gets project approval faster and sets realistic expectations.
Extension audits have more performance impact than most developers realise
3 of the 6 render-blocking scripts were from extensions the store owner didn't know were still active. Replacing them with lightweight alternatives or removing them entirely cut INP from 680ms to 94ms. Extension bloat is invisible until you measure it.