The brief was deceptively simple: make the store fast, everywhere, without asking the content team to relearn their jobs. The retailer’s existing storefront had accreted years of theme customisation and third-party plugins, each one adding weight to every page load. On a fast office connection it felt fine. On a mid-range phone on mobile data — the reality for most of its customers — it was slow enough to cost sales.
Why headless, and why static-first
Rather than optimise the old stack in place, we separated the storefront from the commerce engine. The pages a shopper actually reads — home, category, product — are built to static HTML ahead of time and served from a CDN close to the visitor, so they render almost instantly. Dynamic, per-shopper concerns — cart, inventory, checkout — talk to the commerce platform through an API, and only the interactive parts of a page ship JavaScript.
This is the pattern we reach for whenever performance and scale both matter: the fast path is fast by construction, and the slow, dynamic work is isolated to where it’s genuinely needed.
The critical path came first
We rebuilt listing, product and checkout around Core Web Vitals from the outset — image handling, layout stability, and interaction responsiveness treated as design constraints, not a post-launch audit. Multilingual support was built in from day one with proper hreflang, so opening a new EU market became a content task, not an engineering project.
The figures above are illustrative of the type of outcome this approach delivers; the specific client is not named. What generalises is the method: replatform to a fast-by-default architecture, rebuild the revenue-critical path around real performance metrics, and give the content team tools they already understand.
If a slow or hard-to-scale storefront is costing you conversions, that’s exactly the kind of work our web development and eCommerce teams take on. Tell us about it.