Headless Shopify with Hydrogen vs Next.js: A Migration War Story

A client came to us last year with a Shopify Plus store doing solid revenue and a Next.js storefront that had grown into a maintenance sinkhole. The ask sounded simple: "Should we move to Hydrogen?" The answer took a two-week audit, a proof of concept, and a very uncomfortable conversation about sunk costs.

This is what we learned running headless Shopify on both stacks in production, and how we'd advise you to choose in 2026.

The stacks, briefly

Both Hydrogen and Next.js sit on top of the Shopify Storefront API (GraphQL) and Customer Account API. They both do SSR, both support React Server Components, and both can be deployed to edge runtimes. From 10,000 feet they look interchangeable. They are not.

Hydrogen is Shopify's opinionated React framework built on Remix. It ships with a Shopify-aware caching layer, a useShopQuery-style data model, cart and customer primitives, and first-class deploy on Oxford — sorry, Oxygen — Shopify's worker-based hosting. You pay nothing extra for Oxygen if you're on Shopify.

Next.js is the general-purpose React framework you already know. You bring your own commerce primitives (or use a starter like the Vercel Commerce template), your own caching strategy, and you host it wherever — Vercel, Cloudflare, your own Kubernetes cluster. It's flexible. That flexibility is the whole story.

Where the split actually matters

On a greenfield build, Hydrogen gets you to a working PDP faster. On a store with an existing marketing site, a headless CMS, loyalty widgets, a custom search stack, and three years of Next.js middleware, ripping it out for Hydrogen is a rewrite disguised as a migration.

What we measured on the migration POC

We built the same three routes — home, collection, PDP — on both stacks against the client's real Storefront API data. Same design tokens, same Tailwind config, same product data.

Here's what shook out. Treat these as directional, not benchmarks:

• Cold TTFB from Oxygen (Hydrogen): consistently low, in the 90 – 180ms range from EU/US edges. Caching just worked because the framework knows what a product query is.
• Cold TTFB from Vercel Edge (Next.js): comparable when we tuned revalidate and unstable_cache tags properly. When we didn't, we saw 400 – 800ms because the app was hitting Storefront API on every request.
• LCP on PDP: roughly equivalent once both were tuned. The framework wasn't the bottleneck — the hero image and third-party scripts were.
• Bundle size: Hydrogen shipped ~15 – 25% less JS on the PDP out of the box, mostly because Remix's data loading pushes less to the client than a poorly written Next.js App Router page.

The interesting finding was not that Hydrogen was faster. It was that Hydrogen was harder to make slow.

Caching: the real reason to consider Hydrogen

Caching Storefront API responses correctly is the single hardest part of running headless Shopify. Get it wrong and you either serve stale inventory (bad) or hammer the API on every request (worse, because Shopify rate-limits and your Lighthouse score dies).

Hydrogen ships with CacheLong, CacheShort, and CacheCustom strategies wired into its query functions. You write:

const {product} = await storefront.query(PRODUCT_QUERY, {
  variables: {handle},
  cache: storefront.CacheLong(),
});

And you get sensible SWR behavior on Oxygen's edge cache, plus automatic cache tags for invalidation via webhooks.

In Next.js you can achieve the same thing, but you're writing it:

const product = await fetch(SHOPIFY_ENDPOINT, {
  method: 'POST',
  body: JSON.stringify({query: PRODUCT_QUERY, variables: {handle}}),
  headers: {'X-Shopify-Storefront-Access-Token': token},
  next: {
    revalidate: 3600,
    tags: [`product:${handle}`],
  },
}).then(r => r.json());

Then you're wiring up a webhook handler that calls revalidateTag() when a product updates. Then you're debugging why the tag didn't fire because Shopify's products/update webhook fires for variant changes but not metafield changes, so you need products/update and a metafield subscription. Then you realize your CMS content lives in Sanity so you need webhooks from there too.

None of this is hard. All of it is work that Hydrogen mostly did for you.

The tradeoff you're actually making

Hydrogen assumes your world is Shopify-shaped. If your PDP data comes from Shopify plus a headless CMS plus a PIM plus a reviews API, Hydrogen's cache primitives cover the Shopify part and you're back to hand-rolling the rest. At that point the DX advantage narrows considerably.

The Oxygen question

Oxygen is free with Shopify Plus. It's a global worker runtime, similar to Cloudflare Workers, and it's tightly integrated with Hydrogen deploys via the Shopify CLI. Push to your main branch, get a preview URL per PR, promote to production.

The catch: you can't run arbitrary Node.js on Oxygen. It's a worker runtime. No native modules, no long-running processes, careful with heavy dependencies. If your storefront has server-side logic that needs Node — say, a PDF generator for personalized products, or a heavy image transform — you're either moving that to a separate service or you're on Vercel/Cloudflare/your own infra.

Also: Oxygen is Hydrogen-only. You cannot deploy Next.js there. If you leave Hydrogen, you leave Oxygen, and now you're paying for hosting again.

When Next.js wins

We still put clients on Next.js. Here's when:

• The storefront is 30% of the site. If you're running a marketing site, a blog, a support portal, and a store on one codebase, Next.js is the sensible base. Hydrogen is a commerce framework; it's awkward for everything else.
• You have a non-Shopify data spine. Contentful, Sanity, Storyblok, a homegrown PIM, a search service like Algolia or Typesense doing the heavy lifting. Next.js treats Shopify as one API among many. Hydrogen treats it as the world.
• Your team already ships Next.js. The hiring pool is larger, the ecosystem is larger, the Stack Overflow answers are larger. Do not underestimate this.
• You need App Router features that Remix doesn't match. Parallel routes, intercepting routes, and the streaming model in Next 15+ are genuinely useful for complex commerce UIs like quick-view modals over collection pages.

When Hydrogen wins

• Greenfield Shopify Plus store, storefront is the whole product. You'll ship faster and your cache layer will be correct by default.
• Small team, no dedicated platform engineer. Oxygen removes an entire category of ops work.
• Design partners who need preview URLs per branch. Oxygen's PR previews are excellent and free.
• You're already deep in the Shopify ecosystem — Functions, Flow, Metaobjects, B2B — and you want your storefront to speak the same language.

The migration cost nobody talks about

The client I mentioned at the top? We advised them to stay on Next.js. Not because Hydrogen was worse, but because migrating meant:

1. Rewriting ~40 custom React components against Hydrogen's cart and customer primitives.
2. Rebuilding their middleware (geo-routing, A/B tests, bot filtering) for Oxygen's worker runtime.
3. Re-integrating Klaviyo, Gorgias, a reviews vendor, and their loyalty platform.
4. Retraining a team of six on Remix conventions.
5. Losing their Vercel analytics and observability setup.

Estimate: 4 – 6 months of engineering for a storefront that would be, at best, marginally faster. The correct move was to fix the caching in the existing Next.js app, which we did in about three weeks.

If they'd been greenfield, we'd have picked Hydrogen without hesitation.

Where we'd start

If you're evaluating this decision right now, do the two-week POC. Build one route — the PDP — on both stacks against your real data, with your real CMS, and your real third-party scripts. Measure TTFB, LCP, and total JS shipped. More importantly, count the lines of glue code you had to write for each. That number tells you more than any benchmark.

And if you want a second pair of eyes on the tradeoff before you commit, that's what we do. We'd rather talk you out of a migration than sell you one you don't need.