The Truth About Shopify Headless Performance

Hydrogen has been pitched as the obvious next step for serious Shopify merchants. React-based, server-rendered, hosted on Shopify's own Oxygen edge platform, with all the modern primitives a Next.js team would expect. The marketing implies that if you're growing past a basic theme, headless is the upgrade path that makes your store faster.

So it's striking that Shopify's own performance team published numbers showing the opposite. In their Liquid vs headless analysis, they reported that Liquid storefronts pass Core Web Vitals at roughly 59.5%, while Hydrogen storefronts pass at around 35%. That is not a small gap. And it comes from the team that builds both stacks.

Figure: Real-user CWV pass rates from Shopify's September 2023 analysis. Liquid storefronts pass at roughly 59.5%; Hydrogen at around 35%.

A few caveats up front. The data underlying that post is from September 2023, so it's a snapshot rather than today's state, and Hydrogen has had time to improve since. Shopify also describes the comparison as "directional" - the Hydrogen bucket in CrUX mixes ecommerce and non-ecommerce sites, so it isn't a clean apples-to-apples cut. Even with those caveats, the gap is large enough to take seriously, and in our consulting work we've audited a fair number of headless Shopify builds where the gap matches what we see on the ground.

The simple version: headless is not automatically faster. In most real-world cases, a well-built Liquid theme outperforms a default-configuration Hydrogen build.

Why does Liquid win the average comparison?

Shopify's own explanation is that Hydrogen can be faster than Liquid, but only when merchants implement optimisations - full-page caching, sub-request caching - that Liquid gets for free out of the box. That matches what we see in audits. A few specific reasons the average Hydrogen store lags:

• Server-rendered HTML is hard to beat for LCP. A Liquid template renders on Shopify's infrastructure, ships HTML, and the browser paints. Hydrogen is also server-rendered, but it then has to hydrate React, request the Storefront API, and run sub-request caching logic. Every extra hop is an opportunity to slip.
• The Hydrogen JS payload is bigger than most teams realise. React, React Router 7, Hydrogen's runtime, the Storefront API client, plus whatever your team has bolted on. Even with code-splitting, the baseline cost is meaningfully higher than a Liquid theme that ships almost no JS. Shopify doesn't publish JS-size comparisons, so this is an observation from our own audits rather than a quote from their post.
• Oxygen cache misses are punishing. When sub-request caches are configured correctly, Hydrogen is fast. When they aren't, TTFB blows up because every page render is calling the Storefront API and waiting. Defaults are conservative, and most teams don't tune them. This is what Shopify means when they say Hydrogen requires a dedicated developer team to hit its potential.
• Third-party scripts hit harder. A Liquid store loading the same review widget and analytics tag has more main-thread headroom because the framework itself is using less. Hydrogen builds tend to feel sluggish under the same app load.

This lines up with what we found in our 80,000-store Shopify performance study - the fastest stores are consistently the ones doing less, not the ones with the most modern stack.

Where Hydrogen actually wins

The 35% number isn't the end of the conversation. Hydrogen pulls ahead in specific situations:

• Interaction-heavy storefronts. If your PDP is a configurator, a custom builder, or a high-frequency variant switcher, client-side state in React is genuinely easier than wrestling Liquid plus a wedge of jQuery. Shopify's own data shows both Liquid and Hydrogen perform well on INP, so this is more about developer experience and code maintainability than raw INP wins.
• Multi-source content. When your storefront pulls from Shopify plus a headless CMS plus a search vendor plus a personalisation engine, Hydrogen's data-fetching primitives handle this far more cleanly than Liquid's section model.
• Custom checkout-adjacent flows. Subscriptions, B2B portals, and account areas with complex business logic are easier to build and faster to iterate on.
• Teams who can actually tune Oxygen. A team that understands CacheShort, CacheLong, and createWithCache and uses them deliberately will get TTFB numbers that Liquid can't easily match. The catch is that most teams don't.

What this means in practice

The honest read of Shopify's data is that headless is a tool, not an upgrade. If your store is mostly catalogue, PDP, and checkout - which is most stores - Liquid is very likely to be faster, cheaper, and easier to keep fast. If your store has genuine application complexity, Hydrogen pays for itself, but only if your team treats caching and JS payload as first-class concerns from day one.

We'd push back on three common reasons we hear for going headless:

1. "Liquid feels dated." That's an aesthetic argument, not a performance argument. The data says the dated thing is winning.
2. "We want React for the dev experience." Fair, but be honest that you're trading user-facing speed for developer comfort. That trade is sometimes worth it. Often it isn't.
3. "We need to be on the modern stack for SEO." Core Web Vitals are a ranking signal. The data we have suggests Liquid is currently passing them more often. The modern stack is not winning that argument right now.

Key takeaways

• Shopify's own published numbers show Liquid passing Core Web Vitals nearly twice as often as Hydrogen (59.5% vs 35%). The data is from 2023 and Shopify calls it directional, but the gap is too big to dismiss.
• Shopify itself attributes the gap to merchants not implementing optimisations Liquid gets for free, rather than to inherent Hydrogen bloat. Either way, the practical outcome on the average store is the same.
• Hydrogen is faster than Liquid in specific cases, mostly interaction-heavy or multi-source builds, but only when the team actively tunes caching and JS payload.
• Most headless migrations we audit regress on LCP and INP versus the Liquid build they replaced. The marketing promise and the field data do not match.
• If you're considering Hydrogen, the question to ask is not "is React better than Liquid" but "does my store have enough application complexity to justify the performance tax?" For most merchants, the answer is no.

If you're weighing a headless migration, or you're already on Hydrogen and your Core Web Vitals are worse than they were on Liquid, we'd be happy to take a look. Get in touch.