Shopify Hydrogen and Custom Storefronts: When to Leave Liquid

Hydrogen is a React framework for building Shopify storefronts against the Storefront API, deployable to Oxygen or elsewhere. It is a good framework. It is also the answer to a question many stores are not actually asking.

The three options

The bottom row is the one people forget. Checkout is always Shopify’s, on every plan below Plus, and even with Plus you are working inside defined extension points. Going headless does not give you checkout control — it gives you control of everything up to checkout, and then hands the customer off.

What you give up

The app ecosystem is the real cost. A large share of Shopify apps work by injecting scripts into a Liquid theme — reviews widgets, upsell tools, loyalty programmes, live chat, analytics overlays. On a headless storefront none of those install themselves. Each becomes either an API integration you build or a feature you drop.

Audit this before committing. List the installed apps, mark each as Storefront-API compatible, replaceable, or lost. Teams frequently find that the review widget and the subscription app are load-bearing for revenue, and that reimplementing them costs more than the performance gain was worth.

The second loss is merchant autonomy. Theme-editor changes become developer tickets. For a team with in-house engineering that is fine; for a merchandising team used to reordering sections themselves it is a significant downgrade.

What you gain, and when it is worth it

• A real performance ceiling. Liquid themes are frequently slow because of accumulated app scripts, not because Liquid is slow. Headless removes that accumulation — though only until you add third-party scripts back.
• Composition with non-Shopify content. If the storefront must combine products with editorial from a separate CMS, headless is the natural shape.
• Genuinely custom experiences — configurators, complex B2B flows, multi-brand storefronts on one catalogue.
• Shared component libraries across several properties.

The honest summary: if the motivation is “the site is slow”, audit the apps and images first. That fixes most stores at a fraction of the cost.

Storefront API basics

The Storefront API is public-facing and rate limited by request cost rather than count. Cart state lives in Shopify via the Cart API, which is what keeps checkout working.

const CART_QUERY = `#graphql
  query Cart($id: ID!) {
    cart(id: $id) {
      checkoutUrl                # hand-off point; always Shopify
      lines(first: 50) {         # always bound the page size
        nodes {
          quantity
          merchandise { ... on ProductVariant { id title price { amount currencyCode } } }
        }
      }
      cost { subtotalAmount { amount currencyCode } }
    }
  }`;

Two things to get right early. Never trust a price from the client — read it from the API, because a cart total assembled in the browser is a discount waiting to be found. And bound every connection with first:; unbounded queries are how you exhaust the cost budget.

Caching is the whole performance story

Product data changes rarely; inventory and cart change constantly. Caching them the same way gives you either stale product pages or no caching at all.

• Product and collection content — cache aggressively, invalidate on webhook.
• Inventory and pricing — short TTL, or fetch client-side after the page renders.
• Cart — never cached, always per-session.

Invalidate on products/update and collections/update webhooks rather than relying on time alone. Webhook delivery is at-least-once and occasionally missed, so keep a time-based backstop — the same reasoning as any event-driven pipeline, covered in Designing Resilient Multi-Platform Data Pipelines. The cache layering itself works exactly as described in Next.js Caching Explained.

Hydrogen or your own framework

Hydrogen ships Shopify-aware primitives — cart handling, analytics, SEO helpers, session management — and deploys to Oxygen with no infrastructure decisions. That is real value, and it is the default recommendation.

Choose your own Next.js build when the storefront is one part of a larger application, when you have existing infrastructure and deployment practice, or when the team’s React expertise is already committed to a different stack. You then reimplement what Hydrogen gives you, which is a known and bounded cost.

A defensible decision

• Standard catalogue, small team, apps doing real work — stay on Liquid. Fix images and audit scripts.
• Custom experience, in-house engineering, few app dependencies — Hydrogen.
• Storefront inside a larger product, or heavy editorial composition — custom front end on the Storefront API.
• Motivation is purely performance — audit first. It is usually apps and images, and both are cheaper to fix than a replatform.

Questions people actually ask

Does headless let me customise checkout?

No. Checkout stays on Shopify regardless of how the storefront is built. Plus accounts get extension points and checkout branding, but the checkout itself is not yours to replace. If checkout control is the requirement, Shopify is the wrong platform rather than Liquid being the wrong template layer.

Will my apps still work?

Apps that integrate through the Admin or Storefront API generally will. Apps that inject scripts into a Liquid theme will not, and that is a large share of the ecosystem. Audit every installed app before committing – this is the most common reason headless projects stall halfway.

Is Hydrogen faster than a Liquid theme?

It can be, because you control what loads. But a well-built Liquid theme with disciplined app usage frequently beats a headless build that has accumulated the same third-party scripts. The gain comes from removing weight, and headless only makes that possible – it does not do it for you.

Do I have to deploy Hydrogen on Oxygen?

No, though Oxygen is the smoothest path and removes infrastructure decisions. Hydrogen builds on Remix and can run elsewhere; you then take on caching, edge distribution and deployment yourself, which is the same trade described for self-hosting Next.js.

How do I keep merchandising self-service after going headless?

Drive layout from data the merchandising team can edit – collection metafields, or a separate CMS for page composition – rather than hard-coding sections in components. Without that, every layout change becomes a deploy, and the team that used to reorder sections themselves now files tickets.