When we took on the Verdant storefront rebuild, the site loaded its largest content element in 6.1 seconds on a mid-range Android handset over a typical 4G connection. The team knew it was slow. What nobody had done was put a number on it.
The arithmetic
Verdant was spending about $60,000 a month on paid acquisition, with roughly 70% of that traffic landing on mobile. Their bounce rate on mobile product pages was 61%.
Industry research puts the drop-off between a one-second and a six-second load somewhere around 90% for mobile bounce rate. We were conservative and modelled a 25% improvement in the mobile bounce rate from getting under two seconds.
That alone accounted for roughly $9,000 a month in recovered traffic value, before any conversion-rate effect. The rebuild paid for itself inside five months.
Where the seconds actually went
An audit rarely finds one big problem. It finds eleven small ones:
- Render-blocking third-party scripts — four analytics and personalisation tags in the document head, loaded synchronously.
- Unoptimised hero imagery — 1.8MB JPEGs served at full resolution to every device.
- No image dimensions — causing layout shift that pushed cumulative layout shift to 0.31.
- A 400KB JavaScript bundle — most of it a carousel library used on one page.
- Server-rendered on a single region — every request travelling to a datacentre thousands of kilometres from the customer.
None of these is interesting on its own. Together they were the entire problem.
What we changed
The rebuild moved the storefront to Next.js with static generation for product pages and edge rendering for personalised sections. Images went through the framework's optimisation pipeline, served as AVIF with explicit dimensions. Third-party scripts moved behind a consent-gated, deferred loader.
The measurable outcome:
- Largest contentful paint: 6.1s → 1.2s
- Cumulative layout shift: 0.31 → 0.02
- Total JavaScript shipped: 412KB → 96KB
- Mobile conversion rate: +112%
The conversion lift is larger than the performance work alone would explain — checkout changes shipped in the same period. But the performance floor is what made the rest of the funnel work worth doing.
The part that matters after launch
Sites get slow again. Someone adds a tag, a marketing team embeds a heavy widget, a dependency doubles in size.
We enforce a performance budget in the build pipeline. If a pull request pushes the bundle past its ceiling, the build fails. It is a blunt instrument, and it is the only thing we have found that actually holds.