Shopify Hydrogen vs Next.js: Which Headless Stack Should You Choose in 2026?

If you are reading this, you have already decided headless is on the table. The remaining question is which stack to commit to. Shopify pushes Hydrogen as the official path. The wider React ecosystem keeps pulling teams toward Next.js. Both will ship a fast storefront. They are not interchangeable.

This post is the long version of an argument we have with founders and CTOs every month: where each framework actually wins, where it bites you 6 months in, and how we pick one over the other when scoping a Sentinu engagement.

The short answer

If your storefront is "Shopify catalog plus marketing pages plus checkout", with no other commerce backend in the picture, Hydrogen is the right default in 2026. The Storefront API integration, the caching primitives, and the Oxygen edge runtime are tuned for exactly that shape of project.

If you have a heterogeneous backend (a separate PIM, a marketplace layer, multi-region inventory pulled from an ERP, a marketing site that significantly outweighs the store, or an existing Next.js codebase), Next.js is the right default, with Shopify acting as one data source among several.

Everything below is the reasoning behind those two sentences.

What Hydrogen actually is in 2026

Hydrogen is Shopify's React framework, currently built on top of Remix (and therefore on top of React Router v7's data APIs). It ships with:

• A typed storefront client wired to the Shopify Storefront API
• Streaming SSR with route-level loaders
• A cache layer (CacheLong, CacheShort, CacheNone, custom strategies) tied to the runtime
• First-party deployment on Oxygen, Shopify's V8 isolate edge platform
• Cart and checkout helpers that handle the awkward stateful parts of commerce
• An optional Customer Account API integration for headless customer auth

The key thing to understand: Hydrogen is not just "Next.js with a Shopify SDK pre-installed". It is opinionated about how you talk to the Storefront API, how you cache GraphQL responses, and how you deploy. Those opinions are mostly correct for a Shopify-first project, and they cost you flexibility when the project is not Shopify-first.

// Hydrogen route loader: typed, cached, edge-runtime native
export async function loader({ context, params }) {
  const { product } = await context.storefront.query(PRODUCT_QUERY, {
    variables: { handle: params.handle },
    cache: context.storefront.CacheLong(),
  });

  if (!product) throw new Response(null, { status: 404 });
  return { product };
}

That cache: CacheLong() line is the entire point. You are not writing your own ISR logic, your own SWR, your own Redis layer. You are using a runtime that understands "this is a product page, here is how Shopify wants it cached".

What Next.js gives you that Hydrogen does not

Next.js (App Router, 15+) is platform-agnostic. Shopify is just one of N possible data sources. That neutrality is exactly the feature and the bug.

What you gain:

• Any data source, any auth provider, any CMS, any CDN
• A massive ecosystem of patterns, middleware, and hosting options (Vercel, Cloudflare, AWS, self-hosted Node)
• Server Components, Server Actions, Partial Prerendering, and the most active rendering R&D in the React world
• A larger hiring pool (every React dev knows Next, fewer know Hydrogen)

What you give up:

• You write the Shopify integration layer yourself. Cache invalidation on product updates, webhook-driven revalidation, Storefront API rate-limit handling, draft vs published content, none of it is free. We have seen teams spend two sprints rebuilding what CacheLong() gives you in Hydrogen.
• Cart and checkout state. Hydrogen has helpers. In Next.js you are managing the cart ID cookie, the Storefront API cart mutations, and the redirect-to-Shopify-checkout dance manually.
• Customer Account API integration. Doable in Next.js, considerably more work.

Head to head on the things that actually matter

Rendering and performance

Both frameworks can ship sub-second LCP storefronts. The question is how much work it takes to get there.

In practice both can hit a green Core Web Vitals profile. The difference shows up in maintenance, six months later, when someone needs to invalidate the homepage hero after a marketing edit. In Hydrogen it is a webhook plus a cache tag. In Next.js it is the same idea but you are wiring it yourself.

SEO and crawlability

This is the most common objection we hear from founders considering headless: "Won't Google struggle with a React storefront?" No, if you do it correctly. Both frameworks render server-side by default. Both produce HTML that Googlebot can crawl on the first pass without executing JavaScript.

Where the SEO risk actually sits:

• Hreflang and international routing. Hydrogen has a clear pattern using nested routes per locale. Next.js gives you middleware-based locale routing. Both work, both can be misconfigured.
• Canonical handling during migrations. This is where stores actually lose traffic. Neither framework rescues you from a bad redirect map.
• Structured data. Same effort in either framework, you write the JSON-LD yourself.
• Sitemap generation. Hydrogen has a route convention. Next.js has app/sitemap.ts. Both are fine.

If you are migrating from a Liquid theme, the SEO risk is in the redirect strategy and the URL structure, not in the rendering framework. We cover that in our Shopify migration guide.

Hosting and deployment

This is the most underrated part of the decision.

Hydrogen runs best on Oxygen. Oxygen is integrated with the Shopify admin, it does deployment previews per branch, and the runtime is V8 isolates so cold starts are not a thing. You can technically deploy Hydrogen elsewhere, but you lose the cache plumbing and you are off the supported path. For a Shopify-first project, that lock-in is acceptable because the platform you are locked into is the same platform your checkout runs on.

Next.js runs anywhere. Vercel is the path of least resistance and the one Next is engineered against. Cloudflare Workers is increasingly viable. Self-hosted Node behind a load balancer works but you give up a lot of the framework's edge-aware features. AWS via OpenNext is workable but you are now maintaining infrastructure code.

The real question is: do you want one vendor (Shopify, via Oxygen and the Storefront API) or two (Shopify for commerce, Vercel/Cloudflare for the frontend)? Two vendors is more leverage and more surface area to maintain.

Developer experience and hiring

Honest take, six months of running both stacks in production:

• Hydrogen onboarding: a Shopify-experienced React dev is productive in a week. A pure React dev with no Shopify context needs two to three weeks to understand the cache model and the Storefront API.
• Next.js onboarding: any modern React dev is productive immediately on the framework. The Shopify integration code is what they need to learn, and that code is your team's responsibility.
• Hiring market: Next.js wins on raw volume of available engineers. Hydrogen wins on quality of fit for a Shopify project.

When Hydrogen breaks down

It is a fair framework, not a perfect one. Cases where we have moved a project off Hydrogen or recommended against it:

• The storefront is one consumer of many for a commerce backend that is not just Shopify
• Content significantly outweighs commerce (a media brand with a small shop attached)
• The team has zero Shopify context and a hard deadline that does not allow ramp-up
• You need rendering features Hydrogen does not yet expose cleanly (very specific PPR patterns, exotic streaming requirements)
• You need to deploy on infrastructure your security team controls, with no Oxygen option

When Next.js breaks down

Equally fair. Cases where Next.js is the wrong choice for a Shopify storefront:

• You are rebuilding the Hydrogen primitives by hand because no one wants to maintain a custom cache layer
• The team is small and you are spending more time on plumbing than on product
• You want predictable per-request costs and Oxygen's pricing is materially better for your traffic shape
• You want Shopify support to be able to actually help when something breaks on the runtime

A decision framework we actually use

When scoping a headless project at Sentinu, we score four axes from 0 to 3 and let the total decide:

1. Shopify centrality: is Shopify the only commerce backend (3), one of two (1), or one of many (0)?
2. Team Shopify fluency: deep (3), familiar (1), none (0)?
3. Content vs commerce balance: mostly commerce (3), balanced (1), mostly content (0)?
4. Infrastructure constraints: Oxygen acceptable (3), neutral (1), forbidden (0)?

Score 8 or higher: Hydrogen. Score 5 or lower: Next.js. The middle band (6 to 7) is where the actual conversation happens, and where the answer usually depends on hiring plans and how much custom integration the rest of the business already has.

What we ship at Sentinu

Both, with a strong default toward Hydrogen for Shopify-first projects. Recent engagements:

• A D2C apparel brand on Hydrogen + Oxygen, sub-800ms LCP across all PDPs, hreflang across three locales
• A B2B industrial parts catalog on Next.js + Shopify Plus, because the PIM was the source of truth and Shopify was downstream
• A migration from a Liquid theme to Hydrogen for a brand whose dev team had two Shopify-experienced engineers and a hard Core Web Vitals deadline

We do not have a religious preference. We have a checklist, and the checklist usually decides before the founder finishes describing the project.

FAQ

Is Hydrogen production-ready in 2026?

Yes. The Remix-based version is stable, deployed across thousands of Shopify Plus stores, and the cache and Customer Account APIs have matured significantly. The earlier "v1" Hydrogen built on Vite-only patterns is deprecated, do not start a new project on it.

Can I run Hydrogen on Vercel instead of Oxygen?

Technically yes, in practice you are off the supported path and you lose Oxygen's integrated cache. For a serious project we would either commit to Oxygen or use Next.js. The middle path is the worst of both worlds.

Does Next.js give better SEO than Hydrogen?

No. SEO performance comes from rendering strategy and discipline, not the framework choice. Both ship server-rendered HTML by default. Both can be misconfigured.

What about Shopify Hydrogen v2 versus v1?

Hydrogen v2 (Remix-based, now React Router v7 era) is the only version we recommend starting on today. v1 is end of life. If you are on v1, plan a migration on the next quarterly cycle.

Will Shopify keep investing in Hydrogen?

Hydrogen is the official React framework, Oxygen is a first-party Shopify product, and the storefront-focused launches at Shopify Edition events keep pointing at the same stack. The risk of Shopify abandoning it is low. The risk of the framework evolving and forcing migration work is real, the same as any actively developed framework.

How long does a Hydrogen build take versus a Next.js build for the same scope?

In our experience, a Hydrogen project for a Shopify-first store is about 15 to 25 percent faster to ship than the equivalent Next.js project, mostly because you are not writing the Shopify integration layer. That gap closes if the team has heavy Next.js experience and no Shopify experience.

Where to go next

If you are evaluating a headless rebuild, the two pieces worth reading after this are our Headless Shopify service overview for the engineering approach, and our Shopify speed optimization page for how we measure the wins after launch.

If you would rather skip the reading and have a thirty-minute architecture conversation, that is what we are here for.