Short answer: if you're doing under ₹15–20 crore a year, running a catalogue under about 5,000 SKUs, and your storefront content lives inside Shopify, stay on Liquid. The Hydrogen vs Liquid debate gets framed as old versus new, and that framing costs merchants money. Liquid with Online Store 2.0, properly built, will beat 80% of the headless storefronts we've been asked to audit. Hydrogen earns its keep in a narrow band: high traffic, deep catalogue, content that Shopify was never designed to hold, and an in-house engineering team that will still be there in eighteen months.
Here's how we work out which side of the line a store sits on.
What actually differs between Hydrogen and Liquid
Liquid renders on Shopify's servers. You write templates, Shopify does the caching, the CDN, the scaling, the theme editor, the app injection points. You never think about hosting. When traffic triples on the first day of a Diwali sale, that's Shopify's problem.
Hydrogen is a React framework built on Remix. You query the Storefront API, you render on Shopify's Oxygen hosting (bundled with paid plans, though the terms have shifted once already, so check before you budget), and you own everything above the API. Cart logic, routing, caching strategy, image handling, error states, SEO tags. All yours.
Checkout stays Shopify's in both cases. So Razorpay, COD, UPI, GST-compliant invoicing, Shop Pay: none of that changes. People assume going headless means rebuilding checkout. It does not, and that's the single most useful thing to know about this decision.
The real difference is who is responsible for the storefront. On Liquid, Shopify is. On Hydrogen, you are.
The traffic threshold, with arithmetic
The main case for Hydrogen is speed, and speed only pays when there's enough volume for milliseconds to compound into rupees. So put a number on it.
Take a store doing ₹12 crore GMV a year at a 1.8% conversion rate and 45% gross margin. Suppose a Hydrogen rebuild takes LCP from 2.6s to 1.4s and you believe that buys a 3% relative lift in conversion. That's generous; nobody can promise it, and half the studies quoted at you in sales decks are measuring correlation. But run with it.
3% of ₹12 crore is ₹36 lakh in incremental revenue. At 45% margin, ₹16.2 lakh of contribution a year.
Now the other side. A serious Hydrogen build, one with a design system, proper cart state, international routing and CMS integration, lands somewhere between ₹20 lakh and ₹50 lakh depending on how much of your merchandising logic is bespoke. Add a retained front-end developer, because a React storefront with no maintainer decays fast. Say ₹6–10 lakh a year, minimum, and that's if you can hire well.
Payback lands around year two or three, on optimistic assumptions, before you count the six months your merchandising team spends unable to ship a landing page without a ticket.
Now run the same sum on a Liquid speed programme. Compress and resize images properly, kill four abandoned apps, defer the review widget, drop the two web fonts you don't use, move the hero out of a slider. That work costs ₹3–7 lakh and typically recovers most of the LCP gap. Not all of it. Most. At which point the ₹16 lakh a year is largely available without a rebuild.
Our rough line: below roughly ₹25 crore in annual revenue, the speed argument for Hydrogen does not survive contact with a spreadsheet. Above ₹75 crore, it usually does, because at that point 200ms is a full-time engineer's salary in gross profit and you probably already have the engineer.
The catalogue threshold
Liquid gets genuinely uncomfortable past about 25,000–30,000 variants when the merchandising is complex. Not because of page speed, because of the querying. Collection pages with eight filter dimensions, availability logic per location, price bands that change with metal rates or size, personalised sort orders. You end up fighting Liquid's 50-item loop limits and paginated collection objects, and you start doing client-side work that undoes your own speed gains.
Signals we look for:
- More than about 20,000 SKUs where each has genuinely different attributes, not colour variants of the same shirt
- Filtering that has to combine inventory, metafields and third-party data in one query
- Search that needs to understand synonyms, vernacular spellings and misspellings, not just substring matching
- Collection pages that a merchandiser needs to reorder daily by hand
Two of those, Liquid plus a good filter and search layer handles fine. All four at once, on a catalogue that's growing, and the Storefront API starts looking like the honest answer.
The trap here is thinking a headless rebuild solves catalogue navigation. It doesn't. It gives you the freedom to solve it, and then someone has to build the solution. Most stores with a filter problem have a filter problem, not an architecture problem.
The content threshold, which nobody budgets for
This is where Hydrogen wins arguments we didn't expect it to win. If your storefront has to pull from sources Shopify doesn't own, the fight against Liquid gets expensive fast.
Concrete cases we've hit: a beauty brand with 400 ingredient pages and a nested taxonomy that Shopify pages and metaobjects could technically model but nobody could maintain. An appliance retailer that needed live service-centre availability by pincode on the PDP. A multi-brand group running four storefronts off one catalogue with different editorial teams and different content models. A publisher-plus-commerce hybrid where two thirds of the pages had no product on them at all.
If your content team lives in Sanity or Contentful and your merchandising team lives in Shopify admin, Hydrogen lets both be first-class. Liquid makes one of them a second-class citizen. Metaobjects have narrowed the gap considerably since 2023 and are now good enough for most brands. Good enough, not good enough for everyone.
Rule of thumb: if more than a third of your storefront's pages are content rather than commerce, and that content has real structure, the content case for headless is stronger than the speed case.
What you give up when you leave Liquid
The theme editor. This gets underweighted in every headless pitch and it is the most common reason we're called in to help a merchant walk it back.
On Liquid with sections everywhere, a marketing manager builds a festive landing page on a Tuesday afternoon. On Hydrogen, unless someone has built an authoring layer on top, they file a request. Multiply that by every campaign, every collection banner, every A/B test. Teams slow down and blame the agency.
You also lose the app ecosystem as a plug-and-play thing. Theme app extensions and app blocks don't exist in Hydrogen. Reviews, loyalty, wishlists, upsells, WhatsApp widgets, COD verification flows: each one becomes a custom integration against whatever API the vendor offers, and some vendors offer nothing usable. Sit down with your app list before you commit. If eleven of your fourteen apps inject through the theme, price the rebuild of eleven integrations, not one storefront.
And you take on hosting-shaped worry you didn't have. Oxygen is solid, but caching strategy is now your design decision. Get it wrong before a big sale and you'll find out on the day.
Liquid, done properly, is faster than most headless builds
We've audited Hydrogen storefronts with 3s LCPs. React does not make a page fast; it moves the fast/slow decision from Shopify's engineers to yours. A Liquid theme with clean section markup, one preloaded hero image at the right dimensions, native lazy loading below the fold, no app scripts in the critical path and the Section Rendering API doing the cart and filter updates will hit 1.5s LCP on 4G in Indian metros. We do this regularly, and it costs a fraction of a rebuild.
Before anyone signs off on headless for speed reasons, get a real measurement of where the time is going. Run it in the field, not just in Lighthouse. Our Shopify speed optimization work almost always starts with the same finding: three to five apps and an oversized hero account for most of the damage. If you want to watch the numbers yourself over a few weeks rather than take an agency's word for it, SwiftStore scans the store, fixes what it can and tracks the score so you can see whether the trend is real.
The unwelcome version: most stores asking about Hydrogen have a theme with four years of accumulated app residue in it, and no architecture will fix that. A clean rebuild in Liquid gets them 90% of the way for a quarter of the money.
The Indian context most Hydrogen pitches skip
If you're selling in India, your conversion problems are frequently not front-end problems. COD RTO at 25–35%, prepaid discount mechanics, pincode-level serviceability, GST invoicing, delivery-date promises that need to be honest. Those are logic and operations, and they live equally well in either architecture.
Festive peaks are worth a specific mention. Liquid on Shopify's infrastructure absorbs a 10x traffic spike without you doing anything. On Hydrogen you are responsible for cache hit rates on Oxygen, and a cold cache on collection pages during a flash sale behaves differently from a warm one. Not a reason to avoid headless. A reason to load-test in September, not October.
The decision rule we use
Go Hydrogen if at least three of these are true:
- Annual revenue north of ₹50–75 crore, or equivalent in AED, USD or GBP
- An in-house front-end engineer who will still be employed by you next year
- Substantial structured content in an external CMS that your team actually uses
- Catalogue and merchandising logic that Liquid's loops and pagination genuinely can't express
- Multiple storefronts sharing one catalogue with divergent design and content needs
- A marketing team that is comfortable filing tickets, or budget to build an authoring layer
Stay on Liquid if you're growing fast, your team ships campaigns weekly, your app stack is deep, or your engineering headcount is zero. There's no shame in it. Some of the fastest, highest-converting stores we work on are Liquid, and a few of them run more revenue than the headless builds they were told they needed.
Worth naming the middle path too: Liquid storefront, headless only for the pieces that need it. A React-rendered configurator, a bespoke search results page served through the Storefront API, a content hub on a subpath. You take the specific win and keep the theme editor. We do more of these than full rebuilds, and clients are happier with them a year later. If you're on Plus and weighing the full move, the trade-offs are worth walking through with someone who has shipped both, which is most of what our Shopify Plus engagements start as.
Where to start
Pull three numbers before your next architecture meeting: field LCP on your top-selling PDP, the count of apps injecting scripts into the theme, and the percentage of your storefront pages that contain no product. Those three tell you more about whether Hydrogen is worth it than any framework comparison will.
If you'd rather have someone else pull them, our free store audit covers exactly that, and we'll tell you when the answer is to stay put.