Hydrogen or Liquid: Which Should You Actually Build a Shopify Store On

Disclosure: I spent four years building Liquid themes at Debutify, finishing as CDO in August 2026. I no longer have a commercial stake in that market, which makes this easier to write honestly. I have also shipped React applications for years and I have built on Hydrogen.

The short answer

Build on Liquid unless you have a specific, articulable reason not to. For the large majority of stores, Liquid with a well built theme is faster to ship, cheaper to run, easier to hire for, and produces a better result than a headless build attempted without a dedicated frontend team.

Build on Hydrogen if you have in house React engineers who will still be there in two years, your storefront needs genuine application behaviour rather than pages with a cart, or you are pulling content and data from systems Liquid cannot reach cleanly.

The honest failure mode is not "we chose wrong technically". It is "we built a headless storefront and then the developer who understood it left".

What each one actually is

Liquid is Shopify's server side template language. Shopify renders your HTML on their infrastructure and sends it to the browser. You write templates, sections, and snippets, and the platform handles caching, CDN, scaling, and the checkout.

Hydrogen is Shopify's React framework, built on Remix, for building a storefront as a React application that talks to the Storefront API. You deploy it to Oxygen, Shopify's hosting for Hydrogen, and you own the frontend entirely.

The important structural difference is not React versus templates. It is who is responsible for the rendering layer. On Liquid it is Shopify. On Hydrogen it is you, including the caching strategy, the performance budget, the error states, and the parts of ecommerce that are boring but load bearing.

The performance claim, examined

The main argument for headless is speed. The claim deserves scrutiny because it is often made loosely.

A well built Hydrogen storefront can be very fast. Streaming server rendering, granular caching, and client side navigation between pages produce a genuinely snappy experience, and the second page view in a session feels dramatically better than a full page load.

But compare like with like. A clean Liquid theme with no apps also scores in the high 80s or 90s on mobile. Shopify's own infrastructure is fast, their CDN is excellent, and server rendered HTML with minimal JavaScript is a genuinely strong performance baseline.

Where the headless advantage becomes real is when the store needs a lot of interactivity, because that is where Liquid pushes you into shipping increasing amounts of custom JavaScript and you gradually recreate a frontend framework badly.

Where the headless advantage evaporates is the same place the Liquid advantage evaporates: apps. A Hydrogen store still needs reviews, analytics, and email capture, and those still arrive as third party scripts. I have profiled headless storefronts scoring in the 40s on mobile for exactly the same reason Liquid stores do. The rendering architecture does not protect you from 800KB of vendor JavaScript.

So the honest framing is: Hydrogen raises your ceiling and does nothing for your floor. If your store is slow because of apps, going headless will not fix it, and it will cost you six months.

The costs nobody puts in the proposal

You now own things Shopify was doing for you.

Caching strategy. On Liquid, Shopify caches rendered pages and you barely think about it. On Hydrogen you make explicit decisions about what is cached where, for how long, and how it invalidates when a price changes. Get it wrong and you either serve stale prices, which is a genuine commercial problem, or you cache nothing and your origin is slow.

Error and empty states. Every one of them, hand built. Out of stock, invalid discount code, payment declined on return from checkout, product removed while in cart. Liquid themes have these because the theme author already hit them.

SEO fundamentals. Structured data, canonical URLs, hreflang for multi region, pagination semantics, sitemap correctness. A good Liquid theme ships all of this. On Hydrogen it is your code, and getting product structured data subtly wrong is an expensive mistake that shows up as a slow decline in rich result eligibility rather than an error.

The merchant loses the theme editor.

This is the one that bites hardest in practice and it is chronically underestimated in the planning phase.

On Liquid, a merchant can rearrange sections, swap a hero image, launch a campaign banner, and reorder a homepage without a developer. That capability is the difference between a marketing team that can move and a marketing team that files tickets.

On Hydrogen, unless you deliberately build a content management layer, every visual change is a code change, a review, and a deploy. Teams underestimate how much of a store's weekly operation is small content edits. Six months in, the marketing team is frustrated, the developer is doing banner changes, and somebody proposes integrating a headless CMS, which is another system, another cost, and another thing to maintain.

You can build section like flexibility into Hydrogen with a CMS such as Sanity or Contentful. It is real work and it needs to be in the budget from the start rather than discovered in month four.

Apps mostly stop working.

This is the single largest practical cost and it is the one most likely to be discovered late.

Shopify apps that inject storefront functionality do it through script tags and theme app extensions, both of which target Liquid themes. On Hydrogen, an app either has a headless friendly API and SDK, in which case you integrate it manually with real effort, or it does not work at all.

Before committing to headless, list every app your store depends on and check each one for headless support. Merchants routinely discover in month three that their reviews app, their loyalty programme, and their upsell tool all need replacing or rebuilding. That is not a technical problem you can engineer around. It is a scope discovery that invalidates the original estimate.

Hiring changes.

Liquid developers are abundant and comparatively affordable, and the skill is learnable in weeks by anyone who knows HTML and CSS. React developers who also understand ecommerce specifics, cart state, inventory edge cases, checkout handoff, and international pricing are a much smaller pool and cost meaningfully more.

The question to sit with is not "can we build this". It is "who maintains this in two years". A Hydrogen storefront whose author has left is a much harder inheritance than a Liquid theme, because Liquid is constrained and legible while a React application can be architected in a hundred ways.

When Hydrogen is genuinely right

I do not want this to read as blanket discouragement, because for the right store it is clearly the better choice.

You have in house React engineers who are not going anywhere. This is the precondition. Everything else is secondary.

Your storefront is an application, not a catalogue. Complex product configurators, real time pricing that depends on user input, interactive design tools, data heavy comparison interfaces. When the storefront's job involves substantial state management, React earns its cost and Liquid becomes a fight.

You are aggregating multiple data sources. Products from Shopify, editorial from a CMS, inventory from an ERP, personalisation from your own service. Liquid can reach outside Shopify only awkwardly. A React app composing several APIs is doing exactly what it is designed for.

You need a component system shared with other surfaces. If you have a mobile app or a customer portal already in React and you want one design system across all of it, that is a real architectural argument.

Your team is already fluent in Remix. Hydrogen is Remix, so an experienced Remix team is not learning a new framework, only Shopify's data model.

When Liquid is right, which is most of the time

You sell a normal catalogue of products. Product pages, collections, cart, checkout. Liquid is purpose built for this and does it well.

Your marketing team needs to move without a developer. The theme editor is a genuine competitive advantage and giving it up should be a deliberate decision.

You depend on apps. As above.

You do not have dedicated frontend engineers. The most common headless failure is not a bad build, it is an unmaintained one.

Time to market matters. A good Liquid theme customised well gets you live in weeks. A headless build is months, and the gap is mostly spent rebuilding things Liquid gave you.

The middle path most people should consider

You do not have to choose the extremes.

A well built Liquid theme with targeted interactivity. Use Liquid for the pages, and add focused JavaScript where you genuinely need interaction: a fast cart drawer, a good variant picker, a filtered collection view. Modern Liquid with the Section Rendering API for partial updates covers a surprising amount of ground. This is where the large majority of stores should be, and it is where most of them are not because the interactivity gets bolted on badly.

Hydrogen for one surface. Some merchants build a Hydrogen application for a product configurator or a specific campaign experience and keep the main catalogue on Liquid. You get React where it pays and keep the theme editor everywhere else. This is underrated and it deserves more attention than it gets.

The question to actually ask

Not "which is better". Both are good at what they are for.

Ask: what can we not build on Liquid that our business needs?

If you can answer that specifically, with a real requirement rather than a performance aspiration, headless may well be right and you should plan properly for the app situation and the content management gap.

If the honest answer is "nothing specific, but headless is the modern approach", you are about to spend six months and a large budget rebuilding what you already have, and you will end up maintaining more software with a smaller pool of people who can maintain it.

The best performing stores I have seen are not the technically most sophisticated ones. They are the ones where the team could ship changes quickly, and that is much more often a Liquid theme than a headless build.