Two seconds, and what it was worth

The brief

A retail client came to us with a storefront that took just over four seconds to reach Largest Contentful Paint on a mid-tier mobile device, and a checkout conversion rate they suspected — correctly — was being quietly taxed by that load time. The brief was simple to state and took real work to deliver: get the site fast, without changing the merchandising or design the marketing team had already committed to. We rebuilt the front end on Next.js with a focus on measurable performance, and by launch, LCP on that same test device was under two seconds.

What actually moved the number

The biggest single win was moving from client-side rendering to server-rendered and statically generated pages wherever the content allowed it. The old storefront shipped a large JavaScript bundle that had to download, parse, and execute before the product grid rendered anything at all. Rendering product and category pages on the server with Next.js meant the browser received meaningful HTML on the first response. This one architectural change accounted for close to half of the total LCP improvement.

Image handling was the second largest contributor, and the least glamorous. The old site served full-resolution product photography and let the browser scale it down, which meant a phone on a mediocre connection was downloading multi-megabyte images to display a 400px-wide thumbnail. Moving to responsive images with properly sized variants, modern formats served conditionally, and lazy loading below the fold cut the average page weight substantially.

Third-party scripts were the surprise. The old storefront was carrying six separate third-party tags, several of which were blocking render while they loaded. We audited each one, removed two that were no longer in active use, and deferred the rest so they loaded after the page's own critical content rather than competing with it.

What didn't move the needle, and what it was worth

What did not move the needle as much as expected: further micro-optimizing the JavaScript bundle size once we were already server-rendering the critical path. There is a point of diminishing returns where shaving additional kilobytes off a bundle that is no longer blocking first paint stops being worth the engineering time, and we hit that point relatively early.

The business result, six weeks after launch: checkout conversion rate on mobile improved by a double-digit percentage relative to the pre-rebuild baseline, measured against the same traffic mix and holding the merchandising constant. That is the number that made the performance work worth funding, and it is the reason we present web performance engagements to clients in conversion and revenue terms, not just Lighthouse scores.

If your site's load time is costing you conversions and you want a concrete, prioritized list of what would actually move it, that is exactly the kind of engagement our web team scopes as a short, fixed sprint. Reach out and we will start with a real measurement of where your time is going.