WordPress Performance Engineering
Mobile Lighthouse 50 to 85 on a live WooCommerce site, regression-gated
Context
A busy WordPress and WooCommerce site was paying for front-end weight it did not need: mobile Lighthouse performance sat at 50, with a 6.5 s Largest Contentful Paint, 790 ms of Total Blocking Time and a 5.3 s Speed Index on an emulated mid-range device. Main-thread long tasks and render-blocking resources dominated the critical rendering path, and every second of it was being paid by real visitors on real phones.
The constraint that shaped the work: this is a live commerce site. Speed gains that break the cart, the checkout or the layout are negative progress. So every change shipped through a regression gate, visual integrity, store function, layout stability, and the result had to hold as a stable median, not a one-time benchmark screenshot.
The Challenge
- 790 ms of Total Blocking Time meant the main thread was busy when users tried to interact, script execution had to move, not just minify.
- Page caching on a WooCommerce site is a minefield: cart, checkout and account state must never be served from cache, while everything else should be.
- The 6.5 s LCP pointed at render-blocking resources delaying the hero content, the fix is sequencing, which is exactly where careless optimization breaks layouts.
- Every optimization plugin default assumes a brochure site; a commerce site needs deliberate cache-vary and exclusion rules.
Scope and Approach
-
01
Critical-path audit
Profiled the critical rendering path to isolate what actually blocked paint and where main-thread time went, render-blocking CSS and JS, long tasks, oversized media, so the work targeted measured bottlenecks rather than folklore fixes.
-
02
Cache architecture
Configured LiteSpeed page caching deliberately for a dynamic WooCommerce site: cache-vary and exclusion rules around cart, checkout and account state, sane TTLs, and purge behavior aligned with content changes, instead of defaults that either miss constantly or serve a stale cart.
-
03
Defer, minify, unblock
Deferred non-critical JavaScript off the initial evaluation path and minified and combined CSS to collapse render-blocking requests, driving Total Blocking Time from 790 ms to zero and pulling the LCP element forward from 6.5 s to 4.0 s.
-
04
Regression-gated iteration
Every change passed a visual and store-function check before the next one shipped: layout intact, cart intact, checkout intact, CLS held near 0.01 throughout. Speed never shipped at the cost of function.
-
05
Stability verification
Confirmed the final state as a stable median on the emulated mid-range device profile, mobile performance 85, Speed Index 2.3 s, with Accessibility, Best Practices and SEO green alongside.
Architecture flow
Technical Deep Dive
TBT to zero is a sequencing story
Total Blocking Time collapses when script execution stops competing with first paint. Deferral moved the work after the user sees content; the scripts still run, the user no longer waits on them. The metric falling from 790 ms to 0 ms is the measurable form of "the main thread belongs to the user now".
Commerce-aware caching
The cache layer had to know what must never be cached: cart fragments, checkout, account pages, logged-in state. Getting the exclusion and vary rules right is why the site got page-cache speed without a single stale-cart incident during the engagement.
CLS as the regression canary
Cumulative Layout Shift held near 0.01 through every change, deliberately watched as the early-warning signal, because layout shift is usually the first symptom when deferral or minification breaks something subtle.
The mid-range device is the honest yardstick
Desktop scores flatter every site; the emulated mid-range mobile profile is where real customers live and where the 50 was measured. Optimizing and reporting against that profile keeps the numbers meaningful, an 85 there implies comfortable desktop performance, never the reverse.
What the remaining 15 points cost
Pushing past 85 on this site means structural surgery, theme replacement, plugin diet, content redesign, with revenue risk attached. The engagement stopped at the point where marginal gain crossed marginal risk, and said so explicitly. Knowing where to stop is part of the engineering.
Engineering Decisions
Configuration and snippets over plugin stacking
The gains came from configuring one cache layer correctly and adding targeted snippets, not from stacking optimization plugins that fight each other and multiply the debugging surface.
One change per iteration
Serialized changes with a regression check between each. Slower in wall-clock, but when something misbehaved the cause was always the last change, the debugging economics pay for the discipline.
Results
- Mobile Lighthouse performance from 50 to 85 on an emulated mid-range device.
- LCP cut from 6.5 s to 4.0 s, Total Blocking Time from 790 ms to 0 ms, Speed Index from 5.3 s to 2.3 s.
- CLS held near 0.01 throughout, zero layout or checkout regressions across the whole pass.
- Accessibility, Best Practices and SEO all green alongside the performance work.
- Stable medians on a live commerce site, not a one-time benchmark.
Have a system that needs
this kind of work?
Tell me what is breaking or what you need built. I will reply with how I would approach it and what I would check first.