Hydrogen vs. Liquid: when headless is the right call (and when it isn't)

"Should we go headless?" gets asked in roughly half the Plus discovery calls we run. Half the time, the merchant is ready for it. Half the time, the right answer is to stay on Liquid. The cost of choosing wrong, in either direction, is six to eighteen months of wasted engineering.

We have shipped 40+ Liquid themes and 12 Hydrogen builds in the last three years. The shape of when each wins is now legible enough to write down. This is the decision framework we use in kickoff calls — seven questions, a cost reality the agencies don't always put in the proposal, and an honest read on what each platform layer is good at in 2026.

What Hydrogen actually is in 2026

Three things to be precise about up front, because misunderstandings here cost real money.

Hydrogen is a Remix-based React framework — Shopify migrated it from a custom Vite stack to Remix in late 2023, which simplified routing and data loading enormously. It's not a static site generator; it's server-side rendered (SSR) at the edge, with selective hydration of interactive components.

Hydrogen runs on Oxygen, Shopify's hosting platform. Oxygen is global — your storefront serves from Cloudflare Workers behind Shopify's CDN — and it deploys via the Shopify CLI or a GitHub integration. It's not Vercel or Netlify; you don't choose your host. You can technically run a Hydrogen build on other infrastructure, but you give up the deployment integration with Shopify Plus and the merchant admin's preview links.

The data layer is the Storefront API reference — a public GraphQL API that anyone can query — and the Customer Account API for logged-in flows. There is no privileged "Hydrogen knows things Liquid doesn't" data path. Anything you can render in Hydrogen, you can render in Liquid via the same API. The difference is what you do with the data, not which data you can reach.

This last point matters because some headless evangelism implies that Hydrogen unlocks data Liquid can't see. It doesn't. Hydrogen unlocks the ability to compose React components with the Storefront API in ways that Liquid + theme JS can't easily match.

The seven questions that decide it

We walk through these seven in order during kickoff. The merchant gets a yes/no on each; we tally and recommend. Four-or-more yeses puts Hydrogen on the table. Two-or-fewer means stay on Liquid; one or two yeses don't justify the cost shift.

Question one: do you have custom UX requirements that you genuinely can't build with Shopify sections + theme JS? "Genuinely" is the operative word. A Liquid theme with thoughtful section design and a few hundred lines of JavaScript can do almost anything a typical e-commerce site needs. Things that pass the "genuinely" bar: real-time configurators (think Tesla's online-build experience), 3D product viewers integrated with cart logic, multi-step product builders that need to query inventory live, custom shopping experiences for restaurants or marketplaces. Things that don't: animated mega-menus, parallax heroes, fancy product galleries.

Question two: does sub-60-second content freshness matter? If you're running flash sales, real-time inventory displays, or AI-driven recommendations that need to refresh per-user, the Hydrogen + Storefront API + edge cache pattern wins. Liquid theme caches at section level and revalidates on a fixed schedule; Hydrogen can revalidate per request or per response with `Cache-Control` headers.

Question three: do you need multi-region SSR with locale-aware routing? Shopify Markets handles most international cases on Liquid (currency, language, tax). The cases where Hydrogen wins: when you need genuinely different storefront layouts per region (different category structures, different brand positioning, different navigation), or when locale-routing decisions need to happen at the edge based on signals Liquid can't easily access (cookie preferences, user-agent inspection, A/B test cohorts).

Question four: do you need Lighthouse 95+ mobile, with confidence? Both platforms can hit 95+ mobile, but the disciplines differ. Liquid hits it through ruthless app management, image optimisation, and JS budget enforcement. Hydrogen hits it through fine-grained loader splitting, route-based code splitting, and selective hydration. If your team is already disciplined on Liquid perf, the theme performance playbook gets you there. If your team isn't, Hydrogen's tooling makes the discipline easier to enforce — at the cost of the underlying React complexity.

Question five: do you have a React-fluent team in-house, or budget to hire one? This is the question that gets misrepresented most often. Hydrogen requires React + Remix fluency. Not "we used React once on a side project" fluency — production fluency. Loader patterns, error boundaries, hydration edge cases, suspense boundaries, the cache strategy. If your team is Liquid-only, you're either hiring or training. Both take 3-6 months before you ship reliably.

Question six: how dependent are you on Shopify theme apps? This is the underrated headwind. Theme app extensions — the way most Shopify apps integrate with the storefront — work in Liquid by default. They don't work in Hydrogen. If your store depends on a reviews app, a recommendation app, a sticky-cart app, an upsell app, a bundle app, you need to either replace each one with a Hydrogen-compatible alternative (often the Headless variant of the same vendor's product, sometimes a different vendor entirely), or rebuild the integration custom. Audit your installed apps before committing to Hydrogen. We have seen merchants discover, in week three of a Hydrogen build, that their reviews data has no clean export path.

Question seven: is your year-one build budget at $250K or above? Hydrogen builds cost meaningfully more than Liquid theme builds. The reasons compound: the engineering team is more expensive (React + Remix + edge), the QA cycle is more expensive (more surface area), the migration of theme-app integrations is bespoke per app, and the post-launch maintenance is steeper. We see a clean Liquid theme build at $80-120K; a comparable-feature Hydrogen build at $250-400K. If the year-one budget is below $250K, Hydrogen is hard to justify even when the other answers favour it.

Performance: where each wins

Liquid wins on first-byte time. The Liquid render path is straightforward: Shopify's edge serves a cached HTML page directly to the user, no SSR overhead. TTFB on a well-tuned Liquid theme runs 60-120ms globally. Hydrogen on Oxygen runs 100-180ms TTFB on the same edge — the SSR step adds 30-60ms.

Hydrogen wins on dynamic rendering and interactive depth. If your page has personalised content (recommendations based on browse history, customer-specific pricing, locale-detected currency), Liquid has to either skip caching (hurting TTFB) or hydrate the personalisation client-side (hurting LCP). Hydrogen renders the personalised content at the edge in the SSR pass and ships full HTML to the user.

The hydration cost is the trade-off. Liquid pages don't hydrate — there's no React tree to attach. Hydrogen pages do, and a careless Hydrogen build can ship 200kB+ of JavaScript that has to download, parse, and execute before the page is interactive. Disciplined Hydrogen builds — using Remix's loader-split pattern, server components where appropriate, and selective hydration — keep this to 80-120kB.

INP (the interaction metric) splits between them. Liquid stores have the harder INP problem because their interactivity is provided by uncoordinated theme JS bundles plus app scripts. Hydrogen's INP is more predictable because the React tree is one coordinated structure with explicit hydration boundaries — but it's not automatically better. We have seen Hydrogen stores with worse P95 INP than Liquid because of unbounded loader fan-out on slow connections.

SEO: server-render parity, but cache discipline

Both platforms server-render. Both can produce identical HTML to the search-engine crawler. Both can be configured to do this badly.

The most common Hydrogen SEO mistake is cache discipline. By default, Hydrogen routes have aggressive `Cache-Control` headers. If you set them too aggressive on a product page, the price stale-bug bites: the cached page shows an outdated price, the user adds it to cart at the cached price, the checkout shows the actual price, and the user feels bait-and-switched. The fix is route-level cache configuration. Product pages cache for 60 seconds. Collection pages cache for 300 seconds. Account pages don't cache at all.

The other mistake is canonical handling. Liquid themes emit canonical tags from the theme partial. Hydrogen has to emit them from the route component, which means every route author has to remember to do it. We have audited Hydrogen builds where 30% of product pages were missing canonicals, costing rich-result eligibility on every one.

Liquid's SEO advantage in 2026: Shopify ships sensible canonical, schema, and meta defaults. The default theme is competent. A merchant on Liquid who never touches the theme code still has decent SEO. A merchant on Hydrogen who never touches the route code has whatever the build framework happened to ship.

Apps + checkout: what doesn't port

The single biggest gotcha. Hydrogen does not run Liquid theme app extensions. The reviews app you installed via the Shopify App Store, the bundles app, the search app — none of them render in Hydrogen out of the box.

Three patterns work, in order of preference. First, check if the app vendor ships a "Headless" or "Hydrogen-compatible" SDK. The big vendors (Klaviyo, Yotpo, Algolia) do; the long tail mostly doesn't. Second, replace the app with a Storefront API equivalent — most app functionality is data-fetching that the Storefront API can do natively. Third, rebuild the integration as a Hydrogen route component. We have done all three on Hydrogen builds; the third is the most expensive but unavoidable for niche apps.

Checkout is its own conversation. The checkout itself is Shopify-hosted regardless of which storefront layer you use — both Liquid and Hydrogen send users to checkout.shopify.com (or your custom domain). checkout extensibility runs identically on both, so the Net-30, custom field, and Functions-based checkout work transfers cleanly. The post-purchase page is also identical.

The pre-purchase cart is where the platforms diverge. Liquid theme cart drawers are a section + JS pattern with mature cart-app integrations. Hydrogen cart components are React, with fewer pre-built integrations but more flexibility. If you want a heavily customised cart UX (multi-step bundle builders, real-time discount preview, saved cart state across devices), Hydrogen wins. If you just want a competent cart drawer, Liquid is faster to ship.

Cost reality

The cost shift is real and merchants underestimate it consistently.

Year-one Liquid theme build: $80-120K for a competent custom theme on a Plus store. This includes design, development, content migration, app installation and configuration, and a 30-day post-launch support window. Year-two and year-three maintenance: $25-50K each, mostly to keep up with Shopify platform changes (theme app extension migrations, checkout extensibility updates, Online Store 2.0 evolution).

Year-one Hydrogen build: $250-400K for the equivalent feature scope. Higher engineering hourly rates, longer build cycle (typically 4-6 months vs 2-3 for Liquid), bespoke replacements for theme apps, and a more involved DevOps setup. Year-two and year-three: $80-120K each. The maintenance burden stays high because Hydrogen ships breaking updates more frequently than Liquid does.

The break-even on cost alone is somewhere around year four to five. If the merchant is going to use Hydrogen for less than three years, the cost rarely makes sense. If they're going to use it for five-plus years and the bespoke UX it enables drives meaningful revenue lift, it can pencil out.

The "meaningful revenue lift" caveat matters. We have seen Hydrogen builds that recovered their cost in year one through a single revenue feature that wasn't possible on Liquid (a configurator that lifted AOV 18%, a real-time inventory display that cut returns 22%). We have also seen Hydrogen builds that delivered no measurable revenue lift over the Liquid version they replaced — which is the failure mode merchants don't talk about publicly.

The decision matrix we use

For each kickoff call, we walk through the seven questions on a shared screen, ask the merchant to commit a yes or no, and tally. Four or more yeses and the merchant has a strong case for Hydrogen. We then dig into the specific yeses to confirm — is the React fluency really there? Is the budget really committed? Has the merchant audited their app dependencies?

Two or fewer yeses and we recommend Liquid, often with the caveat that we revisit the decision in 18 months. Most stores grow into Hydrogen rather than starting there.

The grey zone — exactly three yeses — is the hardest call. We split it on the cost question: if year-one budget is committed at $250K+ AND the React fluency is in place, Hydrogen. Otherwise, Liquid with explicit roadmap items for the things Liquid can't do, deferred to a future Hydrogen migration.

For the layer underneath this decision — Shopify Plus performance discipline that applies to either platform — see the theme performance playbook and checkout CRO study . The 80/20 wins documented there apply to Hydrogen too; they just look different in the implementation.

If you're trying to make this call for your store and want a real walk-through rather than a sales pitch, talk to us . We do these as 1-2 hour conversations with the merchant's tech lead and head of growth, no commitment. The deliverable is a written recommendation. We package the implementation under custom themes services (Liquid) or app development services (Hydrogen + custom integrations); the performance + CRO services page covers what the post-launch optimisation discipline looks like across both.