The False Dichotomy of Brand vs Performance

For years, online stores had to choose between template themes that load quickly but look like everyone else’s, and fully custom builds that look distinctive but are heavy on mobile.

Headless commerce promises a way out. The storefront becomes a separate front end, built with a framework like Next.js, that talks to the commerce platform, product data and content management system through APIs. You get complete design freedom without giving up a proven checkout and inventory back end.

But headless is an architecture, not a performance guarantee. A badly built headless store can ship far more JavaScript than the theme it replaced, fetch its data in the browser and leave shoppers looking at loading spinners. The freedom that makes headless attractive is the same freedom that lets bloat in.

What the Vodafone Shop Rebuild Taught Me

In 2020, while working as a senior engineer at Kablamo, I was part of the team that rebuilt Vodafone Australia’s online shop: plans, the phone range, individual device pages, cart and checkout. The old shop was an Angular site. The new one was a server-rendered Next.js and React application, running alongside the new content platform Vodafone was moving its website onto. It launched in December 2020 and stayed in production until it was replaced in 2023.

Three lessons from that project still shape how we build storefronts.

Render the pages that sell on the server. Plan and device pages arrived as complete HTML, so shoppers saw products and prices straight away instead of waiting for the browser to assemble them. The new pages loaded in under a second, much faster than the site they replaced.

Give the shop a front end of its own. The shop ran alongside the content platform rather than inside it, which meant the buying journey could be built and tuned on its own terms.

Treat the whole journey as one product. Plans, devices, cart and checkout were built as one journey, so the experience did not change character halfway through a purchase. Shoppers do not care where one system ends and another begins.

Where the Bloat Creeps In

Most slow headless stores are not slow because of the framework. They get slow one reasonable-sounding addition at a time.

• Third-party tags. Analytics, heatmaps, chat, reviews, personalisation and A/B testing scripts all compete with the product page for the browser’s attention.

• Client-side data fetching. If product data is fetched in the browser after the page loads, the shopper sees an empty layout first.

• Interactivity everywhere. Most of a product page is static content. Only the parts people interact with, such as variant pickers, add to cart and the cart drawer, need JavaScript.

• Oversized images. Product photography is usually the heaviest thing on the page, and it is often sent to a phone at the same size as to a 4K monitor.

Tactical Engineering Takeaways

• Pre-render or server-render product, category and plan pages, so prices and stock are in the first response.

• Keep third-party scripts off the critical path, load non-essential tags after the page is interactive, and review the list regularly.

• Serve images as AVIF and WebP in responsive picture elements, sized for the device.

• Use optimistic UI for cart actions: update the cart immediately and confirm with the server in the background, so adding to cart feels instant.

• Set a performance budget for page weight, JavaScript size and load time on a mid-range phone, and check it on every release, not only at launch.

Do You Need Headless at All?

Headless is the right call when a brand needs a storefront that genuinely cannot be built within a theme, or when the shop has to integrate with systems a theme cannot reach. For many smaller stores, a well-built theme on a hosted platform will be faster to launch, cheaper to run and quick enough.

The honest answer depends on what the store needs to do, and part of our job is to say so before anyone writes code.