A/B Testing for Headless Commerce — How It Works on Hydrogen, commercetools, Saleor & Custom Stacks

Headless commerce is now the default for serious mid-market and enterprise D2C brands. The frontend (React, Vue, Astro, custom) lives separately from the commerce backend (Shopify, commercetools, Saleor, BigCommerce). You get performance, design flexibility, and a clean developer experience. You also get a different relationship with A/B testing tools, because most of them were built assuming you have a theme.

This page explains the architectural difference between testing on a theme-based store and testing on a headless storefront, walks through how integration works on each major stack, and shows what changes when you decide between client-side and server-side experimentation. It's an explainer, not a tool ranking.

What changes when you go headless

If you've ever installed an A/B testing tool on a Shopify Liquid theme or a WooCommerce site, the workflow was simple. Paste a snippet into the theme header, save, done. That workflow assumes three things, all of which disappear on headless commerce.

There is no theme editor. Monolithic platforms ship with a known integration point: the theme header. On headless, your frontend is a custom application built in React, Vue, Next.js, Hydrogen, or another framework of your choosing. The testing snippet has to integrate into your application code or load from a CDN. It's a one-time decision your developer makes, but it's a decision, not a paste-and-go step.

The build pipeline is yours. Hydrogen builds with Vite. A commercetools storefront often uses Next.js. Saleor frontends are typically Next.js or Nuxt. Each project has its own bundler, dependency graph, and deployment target. A testing tool that ships a single drop-in script tag works everywhere. A tool that requires SDK installation and bundler configuration works on some stacks and not others.

Rendering happens differently. On a monolithic Shopify store, HTML is rendered by Shopify's servers. JavaScript runs in the browser, and client-side testing is the obvious choice. On headless, you might use server-side rendering (Next.js SSR), static site generation (Hydrogen, Astro), incremental regeneration, or pure client-side rendering. Each one shifts where variant assignment should happen. This becomes the central decision for headless A/B testing, and we cover it below.

How A/B testing works on each major headless stack

Shopify Hydrogen

Hydrogen is Shopify's React framework for headless storefronts, deployed on Oxygen. It uses Remix under the hood and renders server-side. For A/B testing, you have two paths:

• Client-side: Load the testing snippet in the root layout (root.tsx). Variant assignment runs in the browser after hydration. Works for any UI-level test (hero, PDP layout, CTA placement, trust badges). This is what most teams pick.
• Server-side: Use Hydrogen's loader functions to fetch variant assignments from your testing tool's API, then pass them as props to the rendered components. Zero flicker, higher implementation effort.

Note that Shopify's native A/B testing app does not work on Hydrogen. It's built for Liquid themes only.

commercetools (with any frontend)

commercetools is a headless commerce backend. The frontend is typically Next.js, Nuxt, or custom. The testing approach depends on the frontend, not on commercetools itself. Most teams drop a snippet into the frontend's HTML head and run client-side. Server-side is possible by calling the testing tool's API from your frontend's server functions.

Saleor

Saleor is an open-source headless commerce platform with a Next.js or React storefront reference implementation. The Saleor backend doesn't dictate the testing approach. Client-side via snippet in _app.tsx or root layout is the standard pattern.

BigCommerce headless

BigCommerce supports headless via its Catalyst Next.js reference storefront or any custom frontend. Same pattern as the others: client-side snippet in the Next.js root, optionally server-side via API for SSR variants.

Custom Next.js, Remix, Astro, SvelteKit

Any custom commerce frontend works the same way. Drop the testing snippet in the root component or layout. If you need server-side variants (typically for checkout pages where flicker is unacceptable), call the testing API in your server functions and pass results down as props.

Server-side vs client-side on headless: when to pick which

Headless gives you a real architectural choice between server-side and client-side testing. On a Shopify Liquid store the question barely applies. On headless it does.

Client-side testing works on every headless stack. Setup takes minutes (paste a snippet in the root layout), the visual editor stays available, and marketers can run tests without engineering involvement. Tools in this category include Varify.io, VWO, AB Tasty, and Convert. The tiny risk is flicker on slow networks, which a good anti-flicker implementation reduces to under 30 milliseconds.

Server-side testing works best on SSR or SSG stacks like Hydrogen, Next.js SSR, and Astro. The variant decision happens before HTML reaches the browser, so flicker is zero. The cost is implementation effort: every test requires SDK integration, deployment pipeline changes, and backend logic to route variants. Tools in this category include GrowthBook, Optimizely Full Stack, and LaunchDarkly Experimentation. This is the right path when you have engineering capacity and a checkout-critical or backend-logic test where flicker is unacceptable.

For about 80% of headless commerce A/B tests, client-side is the right pick. The exceptions are checkout-critical tests where flicker matters and tests of backend logic such as pricing engines or recommendation algorithms. For those, server-side or hybrid setups make sense. Our client-side vs server-side comparison has the full breakdown.

How Varify.io integrates with a headless storefront

Three reasons Varify.io fits headless commerce well.

• Single snippet, any frontend. An 11.5 KB JavaScript snippet added once in your root layout. Works on React, Vue, Astro, SvelteKit, Hydrogen, Next.js, and anything else that loads JavaScript in a browser. No SDK installation, no bundler config, no framework-specific package to keep updated.
• SPA-aware. Headless stores are typically single-page applications. Varify detects route changes in React Router, Next.js routing, and Hydrogen navigation, and it re-applies variants on the new page automatically. No manual SPA configuration required.
• Cookie-less, no consent gate. Variant assignment uses localStorage, which works regardless of consent banner state and regardless of Safari ITP. This matters for headless stores with high mobile traffic and EU customer base. See cookie-less A/B testing for the architecture details.

The typical integration on a Next.js or Hydrogen storefront looks like this:

// app/layout.tsx or root.tsx
<script
  async
  src="https://cdn.varify.io/snippet/YOUR_ID.js"
/>

That is the entire integration for most headless storefronts. Once the snippet is live, experiments are managed in the Varify dashboard, and no further code changes are needed for new tests.

For performance-critical pages where flicker is unacceptable, Varify also supports calling the assignment API from server-side code and injecting variant data into the initial HTML render. Most teams don't need this, and the client-side default is sufficient for the majority of tests.