Headless Shopify on the Edge: When Hydrogen Beats Next.js, and When It Doesn't

Every headless Shopify project in 2026 starts with the same argument: Hydrogen on Oxygen, or Next.js on Vercel (or Cloudflare, or self-hosted)? Both ship fast storefronts. Both handle the Storefront API. The differences only show up around month three, when the marketing team wants a fifth locale and the caching strategy starts leaking.

We've shipped both stacks for merchants ranging from single-country DTC brands to multi-region catalogues with 40k SKUs. Here's what actually separates them once the demo is over.

The short version

Hydrogen wins when your team is small, your storefront is Shopify-native end to end, and you want the shortest path from Storefront API to a cached HTML response at the edge. Next.js wins when you have non-Shopify data sources, a design system shared with other properties, or an existing React team that already knows the App Router.

Everything else is nuance — but the nuance is where budgets die.

Rendering models: they look similar, they aren't

Both frameworks server-render React and stream to the browser. The difference is in where that server lives and how it caches.

Hydrogen runs on Oxygen, Shopify's global edge runtime, and leans hard on a built-in sub-request cache tied to the Storefront API. You annotate fetches with cache policies and Oxygen handles the rest:

const {product} = await storefront.query(PRODUCT_QUERY, {
  variables: {handle},
  cache: storefront.CacheLong(), // SWR-style, tuned for PDPs
});

Next.js gives you more knobs — fetch cache tags, revalidateTag, ISR, PPR, route segment configs — but you own the mental model. On Vercel that's fine. On Cloudflare Workers or a self-hosted node, you'll rebuild half of what Oxygen gives you for free.

What this means for TTFB

On cached PDPs, both stacks land in a similar range in our tests — comfortably under 200ms from major metros. The gap opens on cold cache and personalised pages. Hydrogen's sub-request cache is aggressive and Shopify-aware; it knows a productByHandle response is safe to hold. Next.js needs you to be explicit, and one careless cache: 'no-store' in a shared component will torch your hit ratio.

Checkout: the part everyone underestimates

Both stacks hand off to Shopify Checkout. Neither owns the payment flow, and that's a good thing — you inherit PCI scope, Shop Pay, local payment methods, and Checkout Extensibility for free.

Where they diverge is the handoff:

• Hydrogen uses the Cart API and redirects to checkoutUrl on the same Shopify domain family. Session continuity, discount codes, and buyer identity flow through cleanly because the SDK was built around it.
• Next.js needs you to wire the Cart API yourself (or via a community library). Every team we've audited has at least one subtle bug here — usually around buyer identity persistence when users bounce between locales or authenticated states.

If you're doing anything custom at checkout (B2B approvals, custom shipping logic, subscription upsells via Checkout UI extensions), the framework barely matters. What matters is that you build the storefront cart in a way that survives the redirect. Hydrogen nudges you toward that. Next.js lets you shoot yourself in the foot.

Developer experience and hiring

This is the least glamorous section and probably the most important.

Next.js is React's default. Every mid-level React engineer on the market has shipped an App Router project. Onboarding is measured in days. The ecosystem — auth, forms, analytics, feature flags — assumes Next.js exists.

Hydrogen is a smaller pond. The framework is solid and the docs are good, but you're hiring for "React engineer willing to learn Hydrogen" rather than "Hydrogen engineer". That's fine for a team of three. It's a real cost for a team of fifteen with quarterly turnover.

The Remix question

Hydrogen sits on Remix (now React Router 7), which means loaders, actions, and nested routing. If your team already thinks that way, Hydrogen feels natural. If they've spent two years internalising the App Router's Server Components and use() patterns, expect a two-week productivity dip.

Cost, honestly

Oxygen is included with Shopify Plus. That's a real line item — a mid-size Vercel Enterprise contract with the bandwidth and function invocations a headless storefront burns through isn't cheap, and neither is running your own Cloudflare setup with proper observability.

But "free with Plus" only matters if you're already on Plus. If you're on Shopify Advanced considering headless, Oxygen isn't on the table and the comparison changes. Next.js on Vercel, or Next.js on Cloudflare Pages, becomes the practical default.

We've seen teams pick Hydrogen purely for the Oxygen line item and regret it because their engineers weren't productive. We've also seen teams pick Next.js and burn the savings on a senior contractor to fix their cache strategy. Pick the stack your team can operate.

Where each stack actually breaks

A fair comparison needs the ugly parts.

Hydrogen's rough edges

• Third-party integrations feel bolted on. If your product data lives in Contentful, your reviews in Yotpo, your search in Algolia, and your loyalty in a custom service — Hydrogen works, but you lose the tight Shopify-only story that makes it shine.
• Oxygen lock-in is real. You can deploy Hydrogen elsewhere, but you give up the sub-request cache integration and half the value proposition.
• Preview environments for content editors are less mature than what Next.js + a headless CMS gives you out of the box.

Next.js's rough edges

• Caching is a footgun. The fetch cache, route cache, and full route cache interact in ways that surprise experienced engineers. PPR helps. It doesn't eliminate the problem.
• Storefront API rate limits hit harder because you're less likely to cache aggressively by default. Every headless Next.js project we've audited had at least one endpoint hammering Shopify unnecessarily.
• Checkout state drift — the cart bug mentioned earlier. Budget for it.

A decision framework that actually works

Ask four questions, in order:

1. Are you on Shopify Plus, and is your storefront Shopify-native (no heavy non-Shopify data)? If yes, start with Hydrogen. You'll ship faster.
2. Does your team already run Next.js in production for other properties? If yes, use Next.js. Consistency across your engineering org beats a marginally better cache story.
3. Do you need deep integration with a headless CMS, custom search, or a shared design system across web and mobile? Next.js has the better ecosystem here.
4. Is the team under five engineers with no headless experience? Hydrogen's opinionated defaults will save you from yourself. Take them.

If you answered yes to (1) and no to (2), Hydrogen. If you answered yes to (2) or (3), Next.js. Everything else is preference.

The migration path nobody talks about

One pattern we've used successfully: start on Hydrogen for the storefront, keep marketing pages on a headless CMS rendered by whatever the content team prefers, and route between them at the edge. You get Hydrogen's Shopify-native strengths on PDPs and collections, and you don't force your content team onto a stack they hate.

The reverse works too — Next.js for everything, with a small Hydrogen app powering a specific high-traffic funnel. Neither framework demands exclusivity, and edge routing makes the seam invisible to users.

Where we'd start

If we were greenfielding a headless Shopify Plus store tomorrow with a team of four, we'd pick Hydrogen, deploy to Oxygen, and spend the first sprint getting the cache annotations right on PDPs and collections. That's where 80% of the performance win lives.

If the team were ten engineers already shipping Next.js elsewhere, we'd stay on Next.js, invest a week in a shared Storefront API client with sane cache tags, and treat the cart-to-checkout handoff as a first-class module with its own tests. Skipping that step is how the bugs get in.

Either way, benchmark on real product pages with real catalogue depth before you commit. Demo storefronts lie. Your 40,000-SKU collection page tells the truth.

If you want a second opinion on which way to jump, our team has shipped both — talk to us about your storefront.