What Hydrogen and Oxygen actually are
Hydrogen is Shopify's official React-based framework for building headless storefronts. Oxygen is Shopify's managed edge hosting layer built specifically to run it. Together they let you replace the Liquid theme layer with a custom React frontend while Shopify continues to own products, inventory, customers, checkout and payments. If you are considering going headless on Shopify, this is the first-party path.
Hydrogen is an opinionated toolkit built on React Router (having moved from Remix), with pre-built components and hooks for carts, product pages, search and filters, all pre-wired to Shopify's APIs. It supports server-side rendering, edge deployment, Storefront API integration, Shopify Functions and checkout extensions. Oxygen is free to use for Hydrogen apps and is the fastest route to deployment, but it is not the only one. You can host Hydrogen elsewhere, and you can build a headless Shopify store without Hydrogen at all.
The December 2025 Winter Edition added first-party Storefront MCP support on Oxygen. That is the first genuinely new reason to reconsider Hydrogen in about eighteen months. More on that below.
The architectural trade-off in plain terms
Headless splits the storefront from the commerce backend. Instead of one system doing both, you build and run a custom frontend that talks to Shopify through APIs. That change is not neutral. It buys you specific things and costs you specific things.
What you gain
Full control over the user experience across every channel. You can build interactive product configurators, 3D or AR pages, blended editorial-plus-commerce experiences, native app frontends that share code with the web, and custom search and filter UIs that Liquid struggles to match. You get modern React tooling, component reuse, and a build pipeline your engineers already understand. On Oxygen, edge rendering and cache control move closer to the shopper, and you decide exactly what JavaScript ships.
What you take on
A frontend to maintain forever. Shopify's own guidance is explicit: headless requires dedicated engineering resource and ongoing maintenance, while a traditional theme keeps the front and back end in one system with faster launches and simpler customisation. You become the owner of image optimisation, CDN configuration, bundle discipline, cache invalidation and API call efficiency. On a Liquid theme, Shopify's CDN and image pipeline handle most of this at massive scale, at no extra cost to you. On headless, they are your problem.
Performance is not free
Hydrogen storefronts can be faster than Liquid themes, but the gain is entirely dependent on implementation. Shopify's own documentation stresses this. Building on Hydrogen does not automatically make a store faster; it gives your team the tools to make it faster if they are disciplined.
The maintenance burden nobody quotes you
This is the part most agencies leave out of the pitch. The Shopify Storefront API deprecates versions on a rolling window, which means your Hydrogen frontend has a hard upgrade cadence baked into it. Every year, someone has to update queries, test regressions and redeploy. That engineering time will not appear in the initial build quote.
A Liquid theme absorbs most Shopify platform changes passively. New checkout features, new admin capabilities, new app compatibility: most of it just works. On headless, every platform evolution needs someone to look at it, decide whether it affects the storefront, and act. App compatibility sits in the same bucket. Many Shopify apps ship a Liquid snippet you drop into a theme. On headless, those apps either need replacing, integrating through their API, or dropping entirely.
The honest framing: going headless converts a large chunk of platform maintenance from Shopify's problem into yours. If you have a small marketing team and no in-house engineers, you are not saving money by going headless. You are shifting an ongoing cost onto an agency retainer or a permanent developer hire.
When headless Shopify genuinely makes sense
We build Shopify stores across the range, from lean DTC launches to nine-figure Plus operations, and the pattern is consistent. Most stores should not go headless. Some absolutely should.
Where traditional Shopify breaks down
A standard Shopify theme with ten apps installed rarely scores above 50 on mobile Lighthouse. Each app injects JavaScript, adding weight to every page load. Shopify's storefront customisation also has hard ceilings. You cannot fully control checkout on non-Plus plans, you cannot easily build interactive 3D product pages, and you cannot merge a content-heavy editorial site and store into one unified high-performance experience without significant compromise. For most stores, none of this matters. For a fast-growing brand where a hundred milliseconds shifts conversion measurably, it matters a great deal.
The two million dollar GMV rule of thumb
Practitioner commentary in the Shopify ecosystem converges on a rough revenue threshold: stores doing under roughly two million dollars a year in GMV rarely see the return on investment work out for headless. This is not a Shopify-published figure, it is a rule of thumb, but it lines up with what we see. Below that scale, the engineering cost of maintaining a custom frontend usually outweighs any conversion or performance gain, especially compared to a well-built Liquid theme with clean app hygiene and a solid design system.
Headless Shopify makes strong sense when at least two of these are true:
- Your GMV is comfortably above the two million mark and performance improvements have a measurable revenue impact at your scale.
- You have UX requirements Liquid genuinely cannot deliver, not just aesthetic preferences.
- You have access to a competent frontend engineering team, in-house or through a delivery partner, on an ongoing basis.
- You are planning AI-native or multi-channel experiences that need programmatic access to storefront data.
If only one of those is true, a well-optimised Liquid theme almost always wins on total cost of ownership. The brands Shopify likes to feature on Hydrogen, Allbirds, Kotn, Gymshark, all meet several of these criteria and had specific experience requirements Liquid could not deliver.
Most Shopify stores under two million dollars in annual GMV should not go headless. The ROI maths rarely works until you are hitting specific conversion ceiling problems.
Get plain-English guides like this in your inbox.
One short email a month. WordPress, Shopify, SEO, no fluff. Unsubscribe in one click.
We never share your email.
Hydrogen vs. Next.js: which to choose
If you have decided headless is right, the next question is Hydrogen or Next.js. Both are React-based. Both talk to the Storefront API. The difference is how much glue code you own.
Hydrogen is built specifically for Shopify. Carts, products, checkout callbacks, customer accounts and search all have first-class SDK support. You do not build adapters. When Shopify releases something new, like Storefront MCP, Hydrogen usually gets it first with sensible defaults. If your commerce stack is entirely Shopify, Hydrogen materially simplifies the codebase.
Next.js is more mature as a general framework and has a larger ecosystem outside commerce. It wins when you have significant non-Shopify data sources, a large existing Next.js codebase, an engineering team already fluent in it, or a multi-platform commerce reality where Shopify is one backend among several. You will own the Storefront API integration in full, and you will host on Vercel, Cloudflare or similar rather than Oxygen.
Our default recommendation for a Shopify-only headless build in 2026 is Hydrogen on Oxygen. It removes several categories of work, the SDK is genuinely good, and the hosting is tuned for the framework. We only reach for Next.js when a client's wider stack pulls us there. The same logic we apply to headless WordPress with Next.js: when it is worth it applies here in reverse: use the first-party framework unless you have a concrete reason not to.
The AI-native storefront case (new in 2026)
The Winter 2026 Edition landed first-party Storefront MCP support on Oxygen. This is the genuinely new development that changes the decision for a subset of brands.
MCP, the Model Context Protocol, is how AI agents read live application state. On a Hydrogen storefront hosted on Oxygen, AI shopping assistants, conversational commerce interfaces, personalisation agents and product discovery tools can query live store data in real time rather than working off scraped or stale snapshots. Inventory, pricing, promotions, customer state: all available to the model at the moment of the conversation.
You can build equivalent capability on Next.js against the Storefront API, but you will build and maintain the MCP bridge yourself. That is not trivial, and it is exactly the kind of infrastructure that becomes a liability the moment Shopify ships a breaking change.
If you are seriously planning conversational commerce or agentic personalisation over the next two years, Hydrogen plus Oxygen is now the lowest-friction path. If AI-native shopping is not on your roadmap, this is not a reason to switch. But it is the clearest new argument for the framework since it launched.
A practical decision checklist
Here is the short version we walk through with clients considering the move. If you want to see how we actually deliver Shopify and e-commerce development work across both traditional and headless setups, the pattern below is what drives the recommendation.
Check GMV. If you are under roughly two million dollars annually, default to a well-built Liquid theme and revisit in a year. If you are above, keep going.
Identify the specific UX or performance problem you cannot solve on Liquid. Write it down in one sentence. If you cannot, headless will not fix a vague dissatisfaction with your current theme. A theme rebuild will probably do the job cheaper.
Confirm engineering capacity. Not just for the build, but for the next three years. Storefront API upgrades, dependency updates, app replacements, MCP evolution: all of it needs a hand on the wheel.
Decide on your CMS. Marketing teams need to edit content without opening a pull request. Pick Sanity, Contentful or similar upfront and integrate it during the build, not after.
Choose Hydrogen on Oxygen unless you have a specific reason to pick Next.js. If your stack is Shopify-only and your team is small, Hydrogen removes categories of work you would otherwise inherit.
Plan the migration carefully. If you are moving from another platform in the same project, treat it as two projects: the platform migration and the headless build. Bundling them multiplies risk, and SEO regression can wipe out a year of paid acquisition. Our WooCommerce to Shopify migration: an SEO-safe playbook covers the pattern. If you are still weighing platforms, Shopify Plus vs WooCommerce for high-volume stores is the sensible first read before you commit to a headless direction on either.
One thing we do differently
For clients hovering around the decision threshold, we usually build a lean proof of concept: one product template and one collection page on Hydrogen, deployed to Oxygen, alongside the existing Liquid store. It exposes the real maintenance shape and lets the team feel the workflow before committing to a full replatform. It also makes the trade-off concrete instead of theoretical.
Headless Shopify with Hydrogen is a serious, mature option in 2026, and Oxygen plus MCP has made the first-party path more compelling than it has ever been. It is still the wrong choice for most stores and the right choice for a growing minority. The difference is whether you are running toward a specific problem Liquid cannot solve, or running away from vague dissatisfaction with your current setup. Only the first justifies the ongoing cost.
If you want a second opinion on whether headless makes sense for your store, see our recent work and get in touch. We will tell you honestly whether a theme rebuild would serve you better, because most of the time it will.
