Case study: cutting retail LCP to 1.2s and lifting mobile conversion 11%
A mid-market retailer with a 3.4 second mobile LCP. Six weeks, no redesign, no re-platform — and a conversion result the finance team could sign off.
Key takeaways
- Third-party scripts accounted for more than half of the original blocking time.
- No redesign and no platform change were required to reach a 1.2 second LCP.
- Mobile conversion rose 11% and revenue per session 8.4% over the following quarter.
What did the engagement change?
Mobile Largest Contentful Paint fell from 3.4s to 1.2s at the 75th percentile across product and category templates. Mobile conversion rose 11% and revenue per session 8.4% in the quarter after rollout, with no redesign and no platform migration.
- 3.4s
- LCP before
- 1.2s
- LCP after
- +11%
- Mobile conversion
- +8.4%
- Revenue per session
Where the time was actually going
The team expected the answer to be images. It was tags. Eleven third-party scripts loaded on every page, four of them blocking render, and two of those belonged to tools nobody in the room could name an owner for.
Removing the unowned tags and deferring the rest accounted for roughly 1.3 seconds before a single line of application code changed.
What each change contributed
| Change | LCP saved | Effort |
|---|---|---|
| Removed unowned third-party tags | 0.8s | 2 days |
| Deferred remaining tags off critical path | 0.5s | 3 days |
| Responsive images and modern formats | 0.6s | 4 days |
| Static rendering for category templates | 0.4s | 5 days |
| Font loading and preconnect fixes | 0.2s | 1 day |
How the result was proven
Rollout was staged by template. Product pages shipped first, category pages a fortnight later, and field data was segmented by cohort throughout so the comparison was against untouched templates in the same weeks rather than against a different season.
That staging is why the conversion number survived the finance review. It was not a year-on-year comparison with a performance story attached.
Half the work was removal, not optimisation. The fastest thing a page can do with a script is not request it.
Keeping the gain after the engagement ended
Performance work regresses by default, because every new tag and every new hero component costs milliseconds that nobody is accountable for. Six weeks of gains can disappear in one quarter of ordinary feature delivery.
Three things kept it. A performance budget enforced in the build, so a pull request that pushes the bundle past its ceiling fails rather than being noticed later. A tag governance rule requiring a named owner and a review date before any third-party script is added. And field data on the same dashboard as conversion, reviewed monthly by the trading team rather than by engineering alone.
Twelve months later the site was still under 1.5 seconds at the 75th percentile, having shipped two major feature releases in between. The budget is what did that, not the original optimisation work.
FAQFAQ
Frequently asked questions
About the author
Tom builds the front end: rendering strategy, performance budgets and accessible interfaces that hold up under real network conditions. He writes about treating Core Web Vitals as a revenue metric rather than a lint rule.
- Core Web Vitals
- Next.js and React
- Web accessibility
- Frontend architecture
