Headless vs traditional ecommerce: what each costs and when headless pays off
Most online stores do well on a platform theme. A few need what only a separate front end can give, and the arithmetic here shows where that line sits for a store like yours.
Headless vs traditional ecommerce: which should your store choose?#
Traditional ecommerce is the right choice for most stores with one storefront, and headless pays off only when several front ends or deep integrations need what a theme cannot give.
However, both shapes are mature, and the choice is not about quality. Shopify, BigCommerce, WooCommerce and Adobe Commerce can all run either way. In each case the catalogue, cart and checkout stay on the platform. So the real question is who owns the storefront. Then comes what that ownership lets you build.
In practice, three questions settle most cases. First, how many storefronts, brands or sales channels will you run in the next 3 years? Second, how many outside systems must the store talk to while orders happen? Then, do you have a team that can own a front end, or a plan to hire one? If the answers are one, few and no, stay traditional. If they are several, many and yes, read on for what headless costs and must earn.
Storefronts and channels
How many storefronts, brands or sales channels will you run in the next 3 years?
Outside systems
How many outside systems must the store talk to while orders happen?
A team for the front end
Do you have a team that can own a front end, or a plan to hire one?
What is headless e-commerce?#
Headless e-commerce splits the storefront shoppers see from the commerce engine behind it, so the two talk only through an API instead of sharing one platform theme.
On a traditional store, one platform holds the catalogue, the cart, the checkout and the theme that draws every page. On a headless store, the platform keeps the catalogue, cart and checkout. A separate front end then asks for them over an application programming interface (API). An API is a set of documented requests and answers. Any headless e-commerce platform works this way, whether it began with themes or not.
For example, WooCommerce's developer docs, read in October 2026, describe a Store API for cart, checkout and product features. They add that "the Store API is unauthenticated and does not provide access to sensitive store data". Shopify's headless docs make the same split. You can use Hydrogen, Shopify's headless toolkit, or call Shopify's APIs from your own stack. Also, BigCommerce says its GraphQL Storefront API "makes it possible to power a headless storefront".
Because that front end is yours, it can be a web shop, a mobile app or a kiosk. All of them read one catalogue. Also, the word headless covers content as well as commerce. For the content side, see the headless CMS guide and how it sits among the types of CMS.
How do headless commerce vs traditional commerce compare on cost, speed and upkeep?#
Traditional commerce wins on time to launch, upkeep and cost, headless commerce wins on design freedom, channels and integrations, and neither wins on page speed by default.
Side by side, headless vs traditional commerce comes down to seven lines.
| Line | Traditional (platform theme) | Headless (your own front end) |
|---|---|---|
| Build cost | A theme set up and styled; the smaller build in the worked example | A front end built from scratch; about four times the traditional build in the worked example |
| Monthly running cost | The platform plan, apps and a share of one person's time | The same platform plan, plus front-end hosting and a full-time owner |
| Time to launch | Shorter: the theme already renders every page | Longer: every page, the cart view and search are built first |
| Page speed | Set mostly by the theme and its apps | Set by your build; it can beat a theme or fall behind it |
| SEO control | Titles, URLs and redirects through the platform's settings | Full control of markup, and the duty to render pages crawlers can read |
| Team skills | Platform admin and theme edits | Front-end developers who own a codebase |
| Who maintains what | The platform maintains the storefront code and hosting | Your team maintains the storefront, its hosting and its cart code |
Source: the worked example below, on BigCommerce, Vercel and BLS figures read in October 2026. Speed rows: HTTP Archive's 2025 Web Almanac. The build-cost row is illustrative.
The last line decides most cases. On a theme, the platform ships fixes, security updates and checkout changes for you. Once the store goes headless, those jobs move to your team. In particular, cart and payment flows become your code. The cart and payment intent guide shows what that work involves.
Adobe says this plainly in its headless architecture playbook, dated 27 June 2023. It notes that many merchants feel unready for headless because such builds "require heavy reliance on developers". That is not a reason to avoid headless. Instead, it is the cost to plan for.
Is headless ecommerce faster or better for SEO?#
Not by default: HTTP Archive's 2025 Web Almanac, published 15 January 2026, counts 76% of Shopify mobile origins with good Core Web Vitals and 35% of WooCommerce origins.
Core Web Vitals are Google's three field measures of a page: load speed, response speed and how still it stays. Hosted platform themes already pass them more often than most stacks. So speed alone rarely justifies a rebuild.
Show data table
| Item | Value |
|---|---|
| Shopify | 76% |
| Squarespace Commerce | 69% |
| Wix eCommerce | 66% |
| WooCommerce | 35% |
| Magento | 35% |
Hosted themes lead on mobile: 76% of Shopify origins pass against 35% of WooCommerce and Magento.
Show data table
| Item | Value |
|---|---|
| Shopify | 76% |
| BigCommerce | 55% |
| Magento | 36% |
| WooCommerce | 33% |
The same order holds on desktop, with BigCommerce at 55% between Shopify and Magento.
Why do hosted themes do well? The platform controls the theme code, the image service and the hosting. It tunes all three across every store at once. A headless front end hands all three to you. As a result, it can beat a theme when a team measures and tunes it. Without that work, it falls behind.
Search works the same way. A theme gives you titles, URLs, redirects and a sitemap through settings. A headless front end gives you full control of the markup. With it comes the duty to render pages that crawlers can read. The Almanac also notes that "Headless implementations reduce platform detectability". That is why headless stores are hard to count in field data at all. So no honest source can say headless ranks better; the build decides.
Which Core Web Vital separates fast stores from slow ones?#
Largest Contentful Paint: HTTP Archive's 2025 Web Almanac, published 15 January 2026, puts good desktop INP at 99% or more on leading platforms, while good LCP runs from 45% on WooCommerce to 92% on Shopify.
Largest Contentful Paint (LCP) times how fast the main image or heading appears. Interaction to Next Paint (INP) times the response to a tap or click. Cumulative Layout Shift (CLS) measures how much the page jumps while it loads. Google's web.dev guide, updated 31 October 2024, sets good LCP at 2.5 seconds or less.
In short, platforms differ on how fast the main content loads, not on how fast pages respond. So load speed is what any rebuild must win.
Show data table
| Dimension | Shopify | BigCommerce | Magento | WooCommerce |
|---|---|---|---|---|
| Good LCP | 92% | 91% | 59% | 45% |
| Good INP | 99% | 99% | 99% | 99% |
| Good CLS | 82% | 60% | 55% | 68% |
| Good CWV | 76% | 55% | 36% | 33% |
INP is good on 99% of desktop origins on every platform, while good LCP runs from 45% on WooCommerce to 92% on Shopify.
The Almanac's own summary of WooCommerce is short: "WooCommerce has scale, but not automatic speed". In practice, a slow LCP usually comes from the hero image, heavy apps and scripts that block the first paint. Therefore, measure LCP on your top pages before any move, and again after. If a rebuild does not improve that number, it has not bought speed.
How do Shopify, WooCommerce, BigCommerce and Magento stores go headless?#
Each platform keeps its backend and swaps the front end: Shopify through Hydrogen, WooCommerce through its Store API, BigCommerce through its GraphQL Storefront API, and Magento through PWA Studio.
Shopify. Shopify's Hydrogen docs for version 2026-10 were read on 30 October 2026. They say "Hydrogen is one way to build a headless storefront on Shopify". Hydrogen is a toolkit that handles the cart, variant selection, collection filtering and analytics. It works inside frameworks that run server code, such as Next.js, React Router, Nuxt, Astro and SvelteKit. Those frameworks keep routing, rendering and the interface. The docs' examples deploy a React Router app to Oxygen, Shopify's hosting for Hydrogen storefronts. They deploy a Next.js template to Vercel, a hosting platform. Shopify's Hydrogen fundamentals page, read in October 2026, adds that "Oxygen is available at no extra charge on paid Shopify plans". Also, the Shopify Plus pricing page offers a "React-based headless stack at no extra cost". So on Shopify, the hosting line can fall away while the team line stays.
WooCommerce. A WooCommerce headless ecommerce build keeps WordPress and WooCommerce as the backend. A separate front end then calls the Store API. WooCommerce's docs, read in October 2026, say the API lists products, fills the cart, fetches shipping rates and turns a cart into an order. They also say customer sessions are cookie-based. Because of that, a front end on another domain has to handle sessions with care.
BigCommerce. BigCommerce's developer docs, read in October 2026, offer starter apps, APIs and SDKs for a custom build. Its GraphQL Storefront API uses GraphQL, a query language where the front end asks for exactly the fields it needs. The same API also works inside a Stencil theme, BigCommerce's own theme system. As a result, a store can move one page at a time.
Magento and Adobe Commerce. Adobe's headless playbook, dated 27 June 2023, names PWA Studio for building a progressive web app. That is a site that installs and behaves like an app. Adobe also says its GraphQL APIs make headless builds faster to develop than its REST APIs. Finally, it says a merchant can mix routes rather than move all at once.
What does a headless store cost over three years?#
In this illustrative worked example, a BigCommerce Performance store costs $189,944 over 3 years built traditionally and $598,604 headless, with every line and assumption shown in the table.
The assumptions, stated once. First, the headless front end runs on Vercel Pro. Vercel's pricing page, read on 30 October 2026, lists it at $20 per month for one developer seat. Second, the platform is BigCommerce Performance. BigCommerce's pricing page, read on 30 October 2026, lists that plan "starting at $1,499 per month, billed annually". Third, a developer-year is the BLS median annual wage for software developers in May 2025, $135,980.
Then the team, which is where the two stores differ. In the worked example, the traditional build takes a quarter of a developer-year at the BLS May 2025 median, $33,995. After launch, a quarter of one developer's time looks after the theme each year. Over the 3 years, at that BLS median, that adds $101,985. Meanwhile, the headless build takes one developer-year at the same BLS median, $135,980. After launch, one full-time developer owns the front end each year. Over the 3 years, at that BLS median, that adds $407,940. Hosting the headless front end adds 36 months at Vercel's $20, or $720.
The example leaves out usage above Vercel's included credit, apps, payment fees and agency margins. Those raise both totals, and the headless total more. So the premium here is a floor.
| Line | Traditional | Headless |
|---|---|---|
| Platform fee (36 x $1,499) | $53,964 | $53,964 |
| Front-end hosting (36 x $20) | $0 | $720 |
| Build | $33,995 | $135,980 |
| Team, 3 years | $101,985 | $407,940 |
| Total | $189,944 | $598,604 |
Show data table
| Item | Value |
|---|---|
| Core | 29$ a month |
| Growth | 79$ a month |
| Scale | 299$ a month |
| Performance (starting at) | 1,499$ a month |
The Performance plan the example uses starts at $1,499 a month, against $29 for Core.
In short, the same store costs about three times as much headless, and every line of the gap can be checked.
Why does team time, not the platform fee, decide the bill?#
Both stores pay the same $53,964 platform fee in this illustrative worked example, so the $408,660 gap over 3 years is almost all the developer time headless needs to build and run.
That fee is 36 months of BigCommerce's Performance plan as priced on 30 October 2026. The premium also grows with every year the store runs. That is because the team line repeats, while the build happens once.
Show data table
| Item | Value |
|---|---|
| Traditional, 3 years | 189,944$ |
| Headless, 3 years | 598,604$ |
| Traditional, 5 years | 293,910$ |
| Headless, 5 years | 907,020$ |
Headless costs $598,604 over 3 years against $189,944 traditional, and the gap widens over 5.
$408,660
Over 3 years
$613,110
Over 5 years
The premium grows from $408,660 over 3 years to $613,110 over 5, because the team line repeats while the build happens once.
| Option | US$ more for headless, illustrative worked example |
|---|---|
| Over 3 years | $408,660 |
| Over 5 years | $613,110 |
Source: arithmetic from BigCommerce and Vercel pricing and the BLS median wage, 2026
In the worked example, on the same BigCommerce, Vercel and BLS May 2025 figures, the premium reaches $613,110 over 5 years. That is three quarters of a developer-year more, year after year, plus a much bigger first build in the worked example. Because of that, the premium depends on who you already employ. For instance, some stores already pay front-end developers for an app or a marketing site. They pay only the share of that time the storefront takes. Likewise, a store that would hire for headless alone pays the whole line.
So before comparing platforms, count people. A cheaper plan saves little if the team line doubles. Also, a pricier plan costs little if the team line stays flat.
When does the headless premium pay back?#
In this illustrative worked example, headless pays back on revenue alone only if it lifts sales 2.27% at 5,000 orders a month, or 11.35% at 1,000.
Counting revenue alone, on an assumed $100 average order, the worked example's store takes in $18,000,000 over 3 years. That is 5,000 orders a month for 36 months.
On the BigCommerce, Vercel and BLS May 2025 figures above, the three-year premium of $408,660 is 2.27% of that. So headless pays back when it lifts sales by more than that share. Since revenue grows with orders, the lift needed falls as volume rises.
In short, a large store needs a small lift, while a small store needs a lift few rebuilds deliver.
Show data table
| Stage | Value |
|---|---|
| 20,000 | 0.57% |
| 10,000 | 1.14% |
| 5,000 | 2.27% |
| 2,500 | 4.54% |
| 1,000 | 11.35% |
The lift needed climbs from 0.57% at 20,000 orders a month to 11.35% at 1,000, so the smaller the store, the higher the bar.
Your headless payback
Put in your orders a month, average order value and developer cost; the defaults are the worked example's 5,000 orders, $100 and the BLS May 2025 median of $135,980.
Extra sales headless must add per $100 of sales over 3 years to pay back (the lift in percent)
$2.27
- Three-year headless premium
- $408,660
- Three years of revenue at these inputs
- $18,000,000
Arithmetic from BigCommerce and Vercel pricing (read 30 October 2026) and the BLS May 2025 median software developer wage. Modelled, not measured.
This calculator is an estimate, not financial advice. Also, it counts revenue, not profit. Say your gross margin is 40%. Then the store keeps 40 cents of each extra dollar, and the real lift needed is two and a half times higher. In short, test your own orders a month and team cost before you trust any general rule.
When does a headless backend such as commercetools make sense?#
An API-first backend such as commercetools fits when several front ends share a single catalogue and checkout, and it prices its licence by orders rather than by a share of sales.
The platforms above started with themes and added APIs. An API-first backend starts with the APIs and has no theme at all. HTTP Archive's 2025 Web Almanac, published 15 January 2026, groups commercetools and Medusa this way. They "provide the commerce backend as a service, while the merchant owns the frontend experience and hosting."
The commercetools pricing page, read in October 2026, describes an order-based model. That is in place of one based on gross merchandise value, the total value of goods sold. The page prints no list price, so any cost model needs a quote for the licence. In practice, this base suits many brands, regions or channels on one catalogue. There, a theme would be rebuilt many times over. For one storefront, it adds the full team line from the worked example with nothing in return. The Almanac also notes that many headless builds "still rely on SaaS backends under the hood". That is the route most stores take.
When is headless the wrong fit for an online store?#
Headless is the wrong fit when one storefront on a theme covers your plans, nobody in-house owns a front end, or page speed is the only reason to move.
| Case | The sign | Do this instead |
|---|---|---|
| One storefront covers your plans | One storefront on a theme covers your plans | Stay on your platform and spend on the theme, the catalogue and checkout tests instead |
| The front end has no owner | Nobody in-house owns a front end | Stay traditional, or start with a platform's own starter, such as Shopify's Hydrogen on Oxygen |
| Speed is the only reason | Page speed is the only reason to move | Measure LCP on your top product and category pages first, then fix the largest image, trim apps and defer scripts |
One storefront covers your plans. Stay on your platform and spend on the theme, the catalogue and checkout tests instead. The worked example's team line is the money you keep.
The front end has no owner. A headless store with no owner gets slower and riskier every quarter. Instead, stay traditional, or start with a platform's own starter, such as Shopify's Hydrogen on Oxygen. That removes the hosting line but not the developer. Adobe's playbook says it plainly: these builds "require heavy reliance on developers".
Speed is the only reason. Measure LCP on your top product and category pages first. Then fix the largest image, trim apps and defer scripts that block the first paint. Since LCP is where platforms split in the Almanac's field data, that is where a theme has room to improve.
What should you write down before choosing?#
List the storefronts, channels and integrations your business expects over the next 3 years, then test headless vs traditional ecommerce against that list rather than this year's budget.
Next, add who will own each piece and what it costs per year. Then run the calculator above with your own orders a month and team cost. If the lift it asks for looks out of reach, the theme is your answer for now.
For the content side of the same choice, read the headless CMS guide and the overview of CMS types. If headless wins, the cart and payment intent guide shows the checkout work your team will own. The ecommerce development and headless CMS development pages describe how we approach both routes. Finally, each platform's own docs, linked above, are enough to start either route on your own.