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.
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.
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.
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:
