The challenge: a beautiful storefront nobody could load
A London-based luxury retail group had a genuinely well-designed storefront built on a templated commerce platform, and a Lighthouse performance score of 34. On mobile connections, which made up the majority of their traffic, the homepage took roughly four seconds to become interactive, and product pages with the platform's default high-resolution imagery frequently took longer. For a luxury brand, slow is a brand problem as much as a technical one: a storefront that stutters while loading undercuts the premium positioning the product photography is trying to build, and the retailer's own analytics showed a clear correlation between page load time and cart abandonment on exactly the highest-value product pages.
The platform itself wasn't broken. It was a commerce platform doing what those platforms generally do: shipping a large, generic client-side bundle designed to support every merchant's theme customization needs, whether or not a given storefront actually used them. Every plugin the retailer had installed over several years, reviews, upsell widgets, a size-guide tool, added its own script to a page that was already struggling, and no one owned the accumulated weight because each addition had been individually reasonable at the time.
The approach: headless Next.js, not a faster version of the same platform
Rather than optimizing within the constraints of the existing templated platform, we rebuilt the storefront headless: Next.js 15 on the frontend, decoupled from a headless CMS that now serves only the content and product data the storefront actually needs, with the legacy commerce platform's checkout and inventory logic retained behind the scenes through OmniCommerce rather than ripped out and rebuilt from zero, since the retailer's operations team depended on workflows already built around it. This meant the rebuild could focus engineering effort on the part of the stack actually causing the performance problem, the storefront rendering layer, without also re-training the operations team on an entirely new backend mid-project.
Product and category pages are server-rendered by default rather than hydrated client-side, since the actual interactive surface area on a product page (add to cart, size selector, image zoom) is small relative to the mostly-static content around it. Images are served through an edge CDN with per-device sizing rather than the platform's original one-size-fits-all high-resolution exports, and the storefront's JavaScript bundle was audited route by route rather than optimized as one global bundle, since a homepage and a checkout page have almost nothing in common in terms of what interactivity they actually need on first load.
Implementation: rebuilding around real inventory, not a demo catalog
The team built the new frontend against a snapshot of the retailer's real (non-live) product catalog rather than seed data, specifically because luxury retail catalogs have irregular structure, products with a dozen variant options next to products with none, that a clean demo dataset never surfaces. This caught several edge cases in the original component design early, before they became production bugs during the actual cutover.
One decision made mid-project was to keep the legacy platform's checkout flow entirely unchanged during the initial launch, rather than rebuilding checkout at the same time as the storefront. Checkout carries the most business risk of any e-commerce page, and separating "make the browsing experience fast" from "touch the payment flow" let the performance rebuild ship and prove itself without also introducing checkout-related risk in the same release. Checkout-specific performance work followed as a second phase once the storefront rebuild had been running cleanly in production.
Results: Lighthouse 34 to 100, four seconds to 0.4
The rebuilt storefront scores 100/100 on Lighthouse performance, up from the original platform's 34, measured on the same representative set of pages (homepage, category listing, product detail) under equivalent mobile network conditions. Time to interactive dropped from roughly four seconds to 0.4 seconds on the homepage, a ten-fold improvement that's directly attributable to the combination of server rendering, route-level bundle discipline, and edge-served, properly sized imagery rather than any single change on its own.
For a luxury retailer, the more meaningful downstream signal was behavioral rather than technical: with the load-time barrier removed, the retailer's own product-page engagement and cart-completion metrics improved in the weeks following launch, consistent with the correlation their original analytics had already shown between speed and abandonment, this time moving in the other direction.
