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

- URL: https://sevsolutions.com/blog/hydrogen-vs-liquid-when-to-go-headless
- Published: 2026-01-02T03:33:47.000Z
- Updated: 2026-10-27T12:00:00.000Z
- Category: Speed & conversion
- Tags: Headless, Hydrogen, Performance, Shopify, Shopify Plus

Forty-plus Liquid themes, twelve Hydrogen builds. The seven questions we ask to decide whether your store should stay on a Shopify theme or go headless, and the real costs most agencies leave out of the proposal.

## The short version

- Hydrogen is Shopify's toolkit for headless stores. Your developers build the storefront in a web framework, such as React Router or Next.js. Shopify runs the products, cart and checkout behind it.
- Shopify says a headless store costs more to build and run than a theme. We see a Hydrogen build cost roughly three times a clean Liquid theme build (Liquid is Shopify's theme language). It takes 4-6 months, against 6-10 weeks.
- It pays off when your store needs what a theme can't do, like a live product configurator, and you have the budget and developers for it. Speed alone isn't a reason: both can score 95+ on Google's mobile speed test.
- Answer the seven questions below. Four or more yeses put Hydrogen on the table. Two or fewer mean stay on your theme. For a written recommendation, [talk to us](https://sevsolutions.com/contact).

If your store is running into the limits of its theme, you may be asking whether to go headless. We hear "Should we go headless?" 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, either way, is six to eighteen months of wasted engineering.

We have shipped 40+ Liquid themes and 12 Hydrogen builds in the last three years. When each one wins is now clear enough to write down. This is the decision framework we use in kickoff calls. It has seven questions, the costs agencies don't always put in the proposal, and an honest read on what each option is good at.

## What Hydrogen actually is

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

Hydrogen is Shopify's headless toolkit. Its current version, 2026-10, isn't tied to one framework. Its core handles the parts of a storefront that are specific to Shopify, like the cart, product options, collection filters and the pages that apps and checkout depend on. It leaves routing, rendering and the interface to the framework your developers use. Shopify offers two starter templates, React Router 7 and Next.js (Vercel's "Vercel Shop"), and the Hydrogen repository has examples for Astro, Nuxt, SolidStart and SvelteKit. Both templates are built with React, a JavaScript library for building user interfaces. They render each page on the server (SSR: the server builds the page's HTML), then hydrate it (the browser's JavaScript makes the page interactive). Shopify now calls Hydrogen 2026-04 and earlier "Legacy Hydrogen".

Where it runs depends on the framework. The React Router template deploys to Oxygen, Shopify's own hosting for storefronts. Its environments, preview deployments and settings are managed in the Shopify admin, and it deploys from GitHub or from your own build pipeline. The Next.js template deploys to Vercel, and a storefront built on another framework can run wherever that framework already deploys, such as Node, Cloudflare Workers or Deno. So you do choose your host now; Oxygen is the choice that keeps hosting, previews and deploys inside Shopify.

The data layer is the [Storefront API reference](https://shopify.dev/docs/api/storefront) — a public GraphQL API, an interface any program can query for store data — 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 plus a theme's JavaScript can't easily match.

## The seven questions that decide it

![Seven questions and where a yes points: custom UX you can't build with sections (Hydrogen); content that must be fresher than 60 seconds (Hydrogen); multi-region server rendering with locale routing (Hydrogen, or Liquid with Markets); a Lighthouse mobile score over 95 (either, with discipline); a React-fluent team (Hydrogen); theme apps you depend on (Liquid); and a year-one budget sized for a custom React build (Hydrogen is feasible).](https://sevsolutions.com/posts/hydrogen-vs-liquid-when-to-go-headless-decision-tree.svg)

Figure: If 4+ are 'yes', Hydrogen is on the table. If 2 or fewer, stay on Liquid

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 (the content blocks merchants arrange in the theme editor) + theme JavaScript? "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 (an edge cache keeps copies of pages on servers near the shopper). Liquid theme caches at section level and revalidates on a fixed schedule; Hydrogen can revalidate per request or per response with `Cache-Control` headers, the instructions that say how long a copy may be kept.

Question three: do you need multi-region SSR with locale-aware routing, sending each shopper to their own language and country's version? Shopify Markets, Shopify's tools for selling to other countries from one store, 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 a 95+ mobile score on Lighthouse, Google's page-speed test, with confidence? Both platforms can hit 95+ mobile, but the disciplines differ. Liquid hits it through ruthless app management, image optimization, and JS budget enforcement. Hydrogen hits it through fine-grained loader splitting, route-based code splitting, and selective hydration: each page loads only the data and code it needs. If your team is already disciplined on Liquid perf, the [theme performance playbook](https://sevsolutions.com/blog/shopify-theme-performance-2026) 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. Both of Shopify's Hydrogen templates are React apps, so a Hydrogen build on either one requires React 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 sized for a custom React build? Hydrogen builds cost meaningfully more than Liquid theme builds. The reasons compound: the engineering team is more expensive (React, plus server rendering and hosting), the QA (testing) 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 comparable-feature Hydrogen build come in at roughly three times a clean Liquid theme build. If the year-one budget can't cover that, Hydrogen is hard to justify even when the other answers favor it.

## Performance: where each wins

![Liquid and Hydrogen render paths compared: Liquid serves cached HTML from the edge (TTFB ~80ms, no hydration), Hydrogen's React Router template renders on Oxygen (TTFB ~140ms, hydrates a React tree), both use the Storefront API for cart and checkout, and JS bundles run ~120kB on an average Liquid store and ~90kB on a disciplined Hydrogen build.](https://sevsolutions.com/posts/hydrogen-vs-liquid-when-to-go-headless-render-paths.svg)

Figure: Liquid wins TTFB by ~60ms. Hydrogen wins on dynamic + interactive depth

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 (time to first byte: how long until the page starts arriving) 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 personalized content (recommendations based on browse history, customer-specific pricing, locale-detected currency), Liquid has to either skip caching (hurting TTFB) or hydrate the personalization in the browser (hurting LCP, how fast the main content shows). Hydrogen renders the personalized 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 their framework's loader-split pattern (React Router's loaders, on that template), server components where appropriate, and selective hydration — keep this to 80-120kB.

INP (the interaction metric: how quickly the page responds to a tap or click) 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 (the slowest 5% of visits) 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. In Hydrogen 2026-10, your framework owns routing and rendering, so each page's `Cache-Control` headers are yours to set. 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, which tell Google the main URL of a page, 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 (search listings with extras like price and ratings) on every one.

Liquid's SEO advantage: Shopify ships sensible canonical, schema (structured data for search engines), 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 (a kit for developers). 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 Shopify's checkout. [checkout extensibility](https://shopify.dev/docs/api/checkout-ui-extensions) (Shopify's app-based way to customize checkout) runs identically on both, so the Net-30 invoice terms, custom fields, and checkout rules built with Shopify Functions transfer 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 customized 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

![Spend per year compared with a Liquid build's first year (1×): Liquid 1× in year one, then about ⅓× in years two and three; Hydrogen about 3× in year one, then about 1× in years two and three.](https://sevsolutions.com/posts/hydrogen-vs-liquid-when-to-go-headless-cost-comparison.svg)

Figure: Hydrogen front-loads cost. The break-even depends on the ROI of the bespoke UX it enables

The cost shift is real and merchants underestimate it consistently.

Year-one Liquid theme build: the baseline. A competent custom theme on a Plus store includes design, development, content migration, app installation and configuration, and a 30-day post-launch support window. Year-two and year-three maintenance: roughly a third of the build cost 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: roughly three times the Liquid build for the equivalent feature scope. Higher engineering hourly rates, longer build cycle (typically 4-6 months vs 6-10 weeks for Liquid), bespoke replacements for theme apps, and a more involved DevOps setup (building, hosting and deploying the site). Year-two and year-three: each about what the whole Liquid build cost in year one. 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 average order value, or AOV, by 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 gray zone — exactly three yeses — is the hardest call. We split it on the cost question: if a year-one budget sized for Hydrogen is committed 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](https://sevsolutions.com/blog/shopify-theme-performance-2026) and our [guide to Shopify's checkout](https://sevsolutions.com/blog/shopify-checkout-cro-what-moves-the-needle). Most of what they cover applies to Hydrogen too; it just looks 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](https://sevsolutions.com/contact). 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](https://sevsolutions.com/services/custom-themes) (Liquid) or [app development services](https://sevsolutions.com/services/app-development) (Hydrogen + custom integrations); the [performance + CRO services](https://sevsolutions.com/services/performance-cro) page covers what the post-launch optimization discipline looks like across both.