Headless frontend, explained

What a headless frontend is

A headless frontend is the storefront layer of a headless commerce system. It is a standalone web application, typically built in a modern JavaScript framework like Vue, Nuxt, React, or Next.js, that renders the shopping experience and communicates with the commerce backend exclusively through APIs.

The "headless" in headless frontend refers to the fact that the commerce backend has no head of its own. It does not render any HTML. It exposes API endpoints for products, pricing, cart, checkout, and orders, and the frontend application calls those endpoints and decides how to present the data. The frontend and the backend are two independent systems that happen to talk to each other.

This is in contrast to a traditional ecommerce theme. A Shopify Liquid theme, a Shopware Storefront template, or a Magento Luma theme all render inside the commerce platform itself. The frontend and backend are the same codebase. To change the checkout layout, you edit the same application that processes orders. A headless frontend lives entirely outside the commerce engine.

How a headless frontend works

A headless frontend in production has three components working together.

The frontend application

A Vue, Nuxt, React, Next.js, or similar application that owns routing, rendering, SEO, and the user interface. It holds no commerce data of its own. Every product, price, cart item, and order record is fetched from the APIs below it. On the Vue and Nuxt stack specifically, Nuxt handles server-side rendering by default, which means product pages and category listings return full HTML on first request — critical for SEO and Core Web Vitals.

The backend-for-frontend (BFF)

A server-side orchestration layer that sits between the frontend application and the commerce APIs. It composes data from multiple backend services into a single, optimized response for the storefront. A product detail page needs product data, pricing, inventory, and related content — the BFF fetches these from their respective sources and returns one response. It also handles caching, authentication, and any logic that should not run in the browser. The BFF is what makes a headless frontend fast. A frontend that calls commerce APIs directly from the browser, without a BFF, is slow and fragile.

The commerce APIs

The backend commerce engine — Norce, Shopware, commercetools, Shopify, Magento, or another platform — exposes REST or GraphQL endpoints that the BFF calls. The commerce engine owns products, pricing, inventory, cart, checkout, orders, and customer accounts. It does not care how the data is displayed. That is the frontend's job.

Headless frontend vs platform theme

The practical differences between a headless frontend and a platform theme matter more in delivery than in theory.

• Customization ceiling. A theme is limited by what the platform's frontend engine allows. CSS overrides, template modifications, and plugin hooks take you so far. A headless frontend is a first-class software application. Any UX pattern, animation, checkout flow, or content layout that can be built in a modern JavaScript framework is achievable.
• Deployment independence. A theme deploys as part of the platform. Every theme change may require a platform deploy. A headless frontend deploys independently, usually to an edge runtime like Vercel. Frontend changes reach production without touching the commerce backend.
• Performance profile. Platform themes render on the platform's server. Response times depend on the platform's infrastructure. A headless frontend served from Vercel's edge CDN can return cached HTML in milliseconds, independently of the commerce backend's response time.
• Engineering requirement. A theme can be managed by a developer familiar with the platform's templating language. A headless frontend requires frontend engineers with JavaScript framework experience. The engineering bar is higher and the team cost is higher.
• CMS flexibility. Most platform themes rely on the platform's built-in content tools. A headless frontend uses a dedicated headless CMS — Storyblok, Contentful, Sanity — with a proper editor experience and multi-channel content publishing.

What a headless frontend delivers for SEO

SEO is where headless frontend gets the most scrutiny, and rightly so. A client-rendered React or Vue application with no server-side rendering returns an empty HTML shell to Google's crawler. That is bad. A well-built headless frontend with server-side rendering or static generation returns full HTML, structured data, and Open Graph metadata on every request. That is at least as good as a monolithic platform, often better.

The specific requirements for a headless frontend to rank well:

• Server-side rendering on all indexable pages. Product detail, category listing, landing pages, blog — all need full HTML on first response. Cart, checkout, and account pages are not indexed and can be client-rendered.
• Canonical links and hreflang. Multi-market storefronts need correct canonical URLs and hreflang attributes on every page. These are straightforward in Nuxt and Next.js with the right SEO modules.
• Structured data. Product schema, breadcrumb schema, and organization schema should be server-rendered as JSON-LD. This is where headless frontends frequently outperform monolithic themes, which often have incomplete or missing structured data.
• Core Web Vitals. LCP, INP, and CLS are achievable at green thresholds on a well-built headless frontend. Image optimization, ISR for product pages, and minimal JavaScript bundles are the primary levers.

Headless frontend delivery models

There are three ways to get a headless frontend into production, each with a different cost and time profile.

Fully custom build

An agency or in-house team builds the storefront from scratch on a framework like Nuxt or Next.js, or on a headless commerce framework like Alokai or Hydrogen. Full control over every layer. Takes 4 to 9 months for a non-trivial storefront. Requires ongoing frontend engineering to maintain.

Frontend-as-a-service

A productized headless frontend — like Frntkey — ships a production-ready storefront with pre-built integrations. The merchant licenses the storefront rather than building it. Implementation takes 6 to 12 weeks. The FaaS provider maintains the core codebase. Best fit for serious headless projects on Norce or Shopware where the storefront requirements are standard rather than radically custom.

Platform-native headless

Shopify Hydrogen, Magento's PWA Studio, and similar tools provide a headless framework tied to a specific platform. The BFF layer is included. The storefront framework is prescribed. Less flexible than a fully custom build, faster to start. Tied to the platform vendor.

When a headless frontend is the right call

A headless frontend is the right delivery model when:

• The storefront experience is a genuine competitive differentiator. The UX, the checkout flow, the content integration, or the multi-channel reach needs to go beyond what a platform theme allows.
• The team can sustain the complexity. Either the engineering capacity is in-house, or the delivery partner has deep headless experience and will stay involved after launch.
• The commerce backend is API-first and exposes a clean API. Norce, Shopware 6, commercetools, Shopify, and Magento 2 with GraphQL all qualify. Platforms with limited or poorly documented APIs are harder to build against headlessly.
• Performance, multi-market support, or multi-channel publishing are real requirements, not aspirations.

A headless frontend is not the right call for a small single-market storefront with standard requirements and a small team. A well-built Shopify store or a Shopware store with the default Storefront will outperform a badly-built headless frontend on every metric that matters. Monolithic is not always the wrong answer.