Hydrogen vs Liquid: when headless pays for itself

Most “should we go headless?” conversations start with a symptom: the store feels slow, a designer wants something the theme can’t do, or an agency has recommended it. The useful question is narrower. What exactly can’t the theme do, and is that worth owning a separate application for as long as the storefront exists?

What actually changes when you go headless

With a Liquid theme, Shopify renders every page from Liquid templates, with JSON configuration files that merchants change in the theme editor, and hosts the result. Merchants rearrange sections and change settings in the theme editor. Apps add features through theme app extensions, whose assets are served from Shopify’s CDN and which don’t edit theme code.

With Hydrogen, the storefront is a React Router application with Shopify’s components, utilities and CLI on top. It reads products, collections and carts from the Storefront API, and it runs on Oxygen, Shopify’s hosting for Hydrogen, or on another JavaScript runtime you choose. Shopify stays the system of record; everything between the API and the browser becomes code your team owns.

When headless pays for itself

Headless earns its cost when the storefront itself is the product: the thing a theme would have to be bent out of shape to deliver. The signals we look for:

• An experience a theme can’t express cleanly: a configurator, an app-like browse flow, heavy client-side state, or motion that is part of the brand rather than decoration.
• Content and commerce from several systems in one frontend, where a theme would need workarounds for each source.
• A frontend shared across surfaces, for example web and a native app reading the same components or data layer.
• Developers who will stay. A Hydrogen storefront needs someone to upgrade it, watch its caching and fix it when an API version moves on.

For a working example of what that looks like, Snow / Motion is a Hydrogen showcase built by Lintel’s founder on Shopify’s sample products: collections and product specs are driven by metafields, secondary data is streamed after the first response, and motion loads only when it helps.

When it doesn’t

• The problem is speed and nothing else. Shopify’s own advice for a slow store starts with an up-to-date, optimised theme such as the Horizon family, fewer sections per template, and checking whether each app is worth what it costs in load time. A headless build can be fast, but not automatically: it depends on how it is built and cached. See performance and technical SEO for the theme-first route.
• The store relies on apps that live in the theme. Reviews, bundles, loyalty widgets and page builders usually arrive as app blocks. Headless, each one needs an API or a headless SDK from its vendor, and a developer to integrate it.
• The merchandising team edits pages every week. The theme editor is a real product. Replacing it with a CMS or metaobject-driven sections is work, and a worse editor is a hidden cost that lands on the team every day.
• Nobody will own the code after launch. An unmaintained Hydrogen app drifts behind its framework and the Storefront API. A theme left alone ages more gracefully.

The costs that show up later

Hosting is rarely the deciding cost: Oxygen is available at no extra charge on paid Shopify plans (not on Agentic plans). The costs that matter are people’s time:

• Caching is your job. Hydrogen caches Storefront API requests by default (each sub-request revalidates after one second and can be served for up to a day), and offers CacheShort, CacheLong, CacheNone and custom strategies. Personalised data must never be cached in a shared cache, and whole pages need their own headers. Get this wrong and you either lose speed or leak one visitor’s data to another.
• Upgrades. Shopify ships a new API version every quarter and supports each for at least 12 months. Hydrogen ships its own releases on top of that. Budget upgrade work every year, not once.
• Platform direction. On 30 June 2026 Vercel and Shopify announced they are rebuilding Hydrogen from the ground up as an open-source, runtime-agnostic project that can be used with frameworks such as Next.js, Nuxt and Svelte. The announcement gave no migration timeline for current Hydrogen apps. A build started today should keep its data layer (queries, caching, content model) separate from framework code, so a later move is a port rather than a rewrite.

How to decide, in order

1. Write down the specific things the current theme can’t do. If the list is only “faster”, stop and audit the theme first.
2. Check each item against a modern Online Store 2.0 theme with custom sections. Many “theme limits” are really old-theme limits.
3. List every app with a storefront presence and find out whether it has an API or headless support.
4. Decide who edits content, and how, after launch. If the answer is “the theme editor”, headless needs a replacement plan.
5. Estimate yearly ownership: upgrades, caching, monitoring and the developer who does them.
6. If headless still wins, prototype the hardest template first (usually product or collection) before committing to the whole store.

If headless is the answer, the next choices are where it runs, covered in hosting Hydrogen on Oxygen or Workers, and how to move without losing search traffic, covered in the Liquid-to-Hydrogen checklist.

Questions to ask whoever recommends headless

If an agency or developer has recommended Hydrogen, these questions separate a considered recommendation from a default one:

• Which specific requirement can’t the theme meet? The answer should name a feature or template, not “flexibility” or “performance”.
• What happens to each app we use on the storefront? Expect a list with an integration plan per app, not “most apps work”.
• How will our team change a homepage banner after launch? If the answer is “raise a ticket”, count that cost.
• What is cached, for how long, and what is never cached? A clear answer means caching was designed, not left at defaults.
• Who upgrades Hydrogen and the Storefront API version, and how often? It should be a named person or a line in a retainer.
• How does this plan survive the Hydrogen rebuild? Given the June 2026 announcement, an honest answer admits uncertainty and explains how the code is structured to limit it.

Where Lintel stands

Lintel builds on Liquid by default and recommends headless only when the list above says it pays. We know the Hydrogen side first-hand: this website is a Hydrogen app served from Cloudflare Workers, and Snow / Motion is the founder’s Hydrogen showcase on sample data. Neither is a client storefront, and we say so. What they give us is first-hand knowledge of the parts of a headless build that a theme handles for you.