14+ years building on WordPress / Replies in under 5 hours
WooCommerce Performance

How a UK fashion store cut mobile load time by 77%

A plugin-heavy WooCommerce store was losing mobile shoppers before checkout ever finished rendering. A three-week performance rebuild — no redesign, no template changes — brought Core Web Vitals into the green.

6.1s → 1.4s
mobile load time
PSI mobile lab data, before vs. after
94
Lighthouse performance
PSI mobile, median of 5 runs
4.8s → 1.1s
Largest Contentful Paint
75th percentile, mobile
-69%
server response time
TTFB measured at origin

Representative engagement. The client's identity is withheld under NDA, and the figures shown illustrate typical outcomes for this type of rebuild rather than one client's audited results. The methodology described below is exactly what I run on real projects.

Client
UK fashion retailer
Identity withheld under NDA
Industry
eCommerce / apparel
Services
Speed optimization, WooCommerce
Timeline
3 weeks
In short

A WooCommerce store loading in 6.1s on mobile was rebuilt at the performance layer only: object caching, a rewritten image pipeline, deferred third-party scripts and a database cleanup. Mobile load time dropped to 1.4s with all three Core Web Vitals passing, and the store's existing design was left completely untouched.

The challenge

The store had grown for six years on a page-builder theme carrying 47 active plugins. On a mid-range Android device over 4G, the product listing took 6.1 seconds to become interactive — and checkout was worse, because WooCommerce's cart-fragments AJAX call fired on every single page load and bypassed the page cache entirely. Core Web Vitals were failing on all three metrics, so the store was carrying a ranking penalty on top of the lost sales. The brief was explicit: fix the speed, don't touch the design the team had spent a year refining.

Starting point

Measured before any changes were made: mobile PSI score 31, LCP 4.8s, CLS 0.24, TTFB 1.3s, 47 active plugins, 312MB of uncompressed product imagery, and wp_options autoload sitting at 4.2MB.

Abstract graphic of bars compressing then spreading apart, suggesting faster page loading

The approach

Performance work goes wrong when it starts with plugins. I split the problem into server time and browser time first, because the fixes are completely different — and on this store the single biggest win turned out to be a database problem, not a front-end one.

Split TTFB from render time before changing anything — 1.3s of the 6.1s was server-side, so front-end optimization alone would have hit a ceiling fast
Profiled queries with Query Monitor and found wp_options autoload at 4.2MB, most of it orphaned settings from plugins removed years earlier and still loading on every request
Disabled cart-fragments AJAX everywhere except cart and checkout, which was single-handedly defeating full-page caching on every product view
Rebuilt the image pipeline: WebP with JPEG fallback, correct srcset breakpoints, native lazy loading below the fold, and explicit width/height attributes to eliminate layout shift
Added Redis object caching and page caching with proper cart, checkout and account exclusions, then deferred the three heaviest third-party scripts

The results

Mobile load time settled at 1.4 seconds with all three Core Web Vitals passing. The database cleanup alone accounted for roughly a third of the total improvement — worth calling out, because it is the step most speed audits skip in favour of visible front-end tweaks. Layout shift dropped from 0.24 to under 0.05 purely from adding image dimensions. No template or design changes were made at any point.

What this didn't cover

This was a performance engagement only — no redesign, no template work, no conversion-rate optimization and no ongoing SEO. Hosting stayed with the client's existing provider, which put a floor of roughly 400ms under TTFB; moving to a better-specced host would likely gain another 150–200ms but was out of scope. The three heaviest third-party marketing scripts were deferred rather than removed, because the client needed them for attribution — removing them would have gained perhaps another 200ms.

Services used on this project

Want the same for your site? Start here:

WordPress speed optimization that users actually feel WooCommerce development for stores built to sell

Common questions

No. Performance work happens at the caching, asset and database layers — your templates and styling stay untouched. If a specific design element genuinely is the bottleneck, I flag it and we decide together before anything changes.

Two to four weeks for a store of this size. Roughly three days go on auditing and establishing a measurement baseline, and most of the remaining time is spent testing each change against a staging copy so nothing reaches your live store unverified.

No — and I would be cautious of anyone who does. A live WooCommerce store running a payment provider, analytics and marketing scripts realistically lands in the high 80s to mid 90s on mobile. Chasing a perfect lab score almost always means breaking something a real shopper actually needs.

Verified reviews

What clients say on Google

These are general reviews of working with me, not comments on this specific project.

★★★★★

“Fantastic Developer. Very knowledgeable. Very patient. Works extremely hard. Very good English Skills. Good communication skills. Takes the time to understand the project scope and the minor details in your project. I am very impressed.”

SB
Silvia B
Google Reviews
★★★★★

“Great developers! All the team are professionally, it's a pleasure work with them :). I, sincerely, recommend it.”

LB
Laura Ballart
Google Reviews
★★★★★

“Worked with them in several projects. They are always good and responsive. More projects will be coming.”

AD
Anatano dev
Google Reviews

Want results like these?

Send me your site and goals — I'll tell you exactly what's worth doing.

Start a conversation