Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
Headless ecommerce means separating the storefront that shoppers see from the commerce backend that handles products, carts, checkout and orders. The two talk through APIs, so you can build the frontend with any technology and change it without touching the backend. On Adobe Commerce, headless pays off when you need a content-rich or multi-channel experience your theme cannot deliver and you have the team to run two applications. It usually does not pay off for a single-brand store whose main goal is speed, because a modern theme such as Hyvä gets most of that benefit with far less work.
This guide explains how headless works on Adobe Commerce, when it pays off and when it does not, what it means for cost and team, and the three main routes: PWA Studio, Commerce Storefront on Edge Delivery Services, and a custom React or Next.js frontend.
How headless works on Adobe Commerce
In a standard ("coupled") Magento store, the same application renders HTML pages and runs the commerce logic. In a headless setup:
- The backend (Adobe Commerce or Magento Open Source) keeps the catalog, pricing, cart, checkout, customers and orders, and exposes them through APIs.
- The frontend is a separate application that calls those APIs and renders pages, often from a CDN or edge network.
- Other services, such as a headless CMS, search or reviews, can feed the same frontend.
Adobe describes its GraphQL API as the implementation for headless storefronts and mobile apps, because it returns exactly the fields a page asks for. REST remains useful for integrations and bulk operations. Our comparison of Magento GraphQL vs REST explains where each fits.
Headless is one step toward composable commerce, where the backend itself is split into separate services. You can go headless without going fully composable; our composable commerce explainer covers the difference.
When headless pays off, and when it does not
| Situation | Headless pays off? | Why |
|---|---|---|
| Content-led brand with rich editorial pages, campaigns and storytelling | Often yes | A headless CMS and modern frontend give editors freedom the theme layer cannot |
| Several channels from one backend: web, app, kiosks, marketplaces | Yes | One API serves every channel |
| Several brands or sites with very different designs on one backend | Often yes | Each frontend evolves independently |
| In-house frontend team already working in React or Next.js | Yes | The skills exist; Magento theming would be the bottleneck |
| Main goal is a faster store | Usually no | Hyvä or performance work delivers most of the gain at a fraction of the effort |
| Many extensions with storefront features | Usually no | Most extensions have no headless frontend; each must be rebuilt |
| Small team, no dedicated frontend developers | No | Two applications to build, host, secure and upgrade |
| Heavy B2B workflows on Adobe Commerce | Depends | Quotes, approvals and requisition lists must be rebuilt or come from ready components |
Cost and team implications
Headless rarely lowers the total cost of a store. It moves cost from theme work into application work. Expect these changes:
- Two codebases: the Magento backend still needs upgrades and patches, and the frontend has its own dependencies, builds and security updates.
- Features you rebuild: things Magento renders for free, such as layered navigation, customer account pages, promotions display and extension widgets, need frontend work.
- SEO responsibility: server-side rendering, metadata, structured data, canonicals and redirects become your frontend team's job.
- Preview and content workflows: merchandisers need preview and scheduling across both systems.
- Hosting: frontend hosting and CDN on top of Magento hosting.
- Skills: React or Next.js, GraphQL and caching expertise, alongside Magento backend skills.
A typical headless team includes a Magento backend developer, two or more frontend developers, someone owning DevOps for both applications, and a product owner who can make decisions across them. If you cannot staff that, in-house or through a partner, a coupled store is the safer choice.
The three Adobe Commerce routes
| Factor | PWA Studio | Edge Delivery Services storefront | Custom React or Next.js |
|---|---|---|---|
| What it is | Adobe's open-source React toolkit and Venia reference storefront | Adobe's Commerce Storefront: drop-in components plus document-based authoring on Edge Delivery Services | Your own frontend built on Magento GraphQL, often with a headless CMS |
| Adobe's direction | Still documented and released (v14.5.1, May 2026); Adobe's newer storefront documentation centers on Edge Delivery | Adobe's current storefront direction for SaaS and Optimizer | Independent of Adobe's storefront roadmap |
| Backends | Adobe Commerce and Magento Open Source | Cloud Service and Optimizer include it; PaaS needs an added Optimizer licence; Open Source not supported | Any edition with GraphQL |
| Ready-made features | Venia components for catalog, cart, checkout and account | Drop-ins for cart, checkout, product details, discovery, account, wishlist and B2B flows | Whatever you build or source |
| Main trade-off | Smaller ecosystem and slower pace of new features | Licensing and Adobe's block model | Maximum freedom, maximum build and maintenance effort |
PWA Studio
PWA Studio is Adobe's React-based toolkit for progressive web app storefronts, with the Venia reference storefront. As checked in November 2026, Adobe's PWA Studio documentation carries no deprecation notice, and the GitHub repository is active (latest release v14.5.1, May 2026). Adobe's newer storefront documentation, however, centers on Edge Delivery Services. For existing PWA Studio stores, the questions are how much custom code you carry and when to plan a move; our article on PWA Studio alternatives compares the options.
Commerce Storefront on Edge Delivery Services
Adobe's Commerce Storefront serves pages from Edge Delivery Services, with content authored in documents and commerce features delivered by drop-in components that call Commerce APIs. Adobe lists B2C drop-ins (cart, checkout, order, payment services, product details, product discovery, recommendations, user account, authentication, wishlist and personalization) and B2B drop-ins (company management, purchase orders, quotes, quick order and requisition lists). It is the storefront for Adobe Commerce as a Cloud Service and Adobe Commerce Optimizer, and it can serve PaaS stores with an added Optimizer licence.
Custom React or Next.js
A custom frontend gives full control of design, routing and content sources, and lets you combine Magento with any CMS or search service. It also means owning every feature, plus performance, accessibility and SEO, for the life of the store. Choose it when your requirements genuinely exceed the ready-made options and you have a frontend team committed for the long term.
Questions to answer before going headless
- What specific capability does the current storefront block? Name it.
- Which extensions have storefront features, and how will each be replaced?
- Who will own the frontend after launch, and is that team funded?
- How will merchandisers preview and schedule content and promotions?
- Which route fits your edition and licence: PWA Studio, Edge Delivery or custom?
- How will you protect SEO during the move: rendering, redirects and structured data?
- Can you phase it, for example content pages first, then category and product pages?
FAQ
Is headless faster than Hyvä?
Not necessarily. A well-built headless frontend can be very fast, and so can a well-built Hyvä store. Speed depends on caching, images, scripts and hosting more than architecture.
Is headless bad for SEO?
Not if pages are rendered on the server or at the edge with complete HTML, metadata and structured data. Client-only rendering is where problems start.
Can we go headless gradually?
Yes. Many teams start with content or landing pages and move commerce pages later. Adobe also offers a bridge for sharing sessions between Luma and Edge Delivery pages during a gradual move.
Next step
If the table points toward headless, the first job is choosing the route that fits your edition and team. Mistri's headless Adobe Commerce service covers architecture and API work, and our headless PWA storefront design service covers the frontend experience.
Sources
Headless Adobe Commerce architecture (Adobe Implementation Playbook); Commerce Storefront architecture (Adobe Experience League); Commerce Storefront drop-ins introduction (Adobe Experience League); Commerce Storefront supported backends (Adobe Experience League); GraphQL API for Adobe Commerce (Adobe Developer); PWA Studio documentation (Adobe Developer); magento/pwa-studio releases (GitHub).
