A/B testing a static Next.js landing page: split URL, edge, and feature flags

A static Next.js landing page is built for one thing: to render as fast as possible, with no extra work for the browser. That is exactly what most mainstream visual A/B testing tools (Optimizely, VWO, the former Google Optimize) break: they load the original page, then rewrite the DOM in JavaScript once it reaches the client to display the variant. The visitor sees a split-second flicker — version A before version B — and every DOM rewrite after the initial render drags down the CLS score. On a site built for performance, that is counterproductive. Here are three methods that avoid this problem, and how to choose between them based on your technical resources.

Why classic visual tools are a problem on a static page

“No-code” A/B testing tools were designed for server-rendered dynamic sites (WordPress, Shopify), where modifying the HTML before it reaches the browser is complex. Injecting a script that rewrites the page after the fact was the easiest solution to bolt onto anything. On a pre-generated static page (generateStaticParams), that choice becomes a liability: you lose on one side what you optimised on the other. We cover this visual-shift mechanism in our article on Core Web Vitals CLS, and the broader impact of speed on conversion in our load speed guide.

Three methods for A/B testing a static landing page

1. Split URL testing: two pages, one edge redirect

This is the most reliable method for a static page: you build two full versions (/offer and /offer-b), and a middleware running at the edge (Vercel Edge Middleware, Cloudflare Workers) routes each new visitor to one or the other based on a cookie set on their first visit, so they always see the same version. No client-side rewriting: each variant is served already finished, with its own native Core Web Vitals. The trade-off: two pages to maintain in parallel, and specific SEO care — treat it like a redesign without losing your SEO — noindex on the losing variant, canonical to the winning version once the test ends.

1. Duplicate the page into a new route folder (/offer-b) and change only the element being tested — one change at a time, so you can attribute the effect with confidence.
2. Write a middleware that reads an existing cookie or, failing that, randomly picks a variant and sets that cookie for the duration of the test (30 days is enough in most cases).
3. Silently rewrite (a rewrite, not a visible redirect) visitors assigned to variant B from the original URL, so you keep a single URL to share in ads.
4. Send the variant seen as a custom parameter to your analytics tool, so you can compare conversion rates by group once the test is over.

2. Edge feature flags: one page, two renders

Closer to the spirit of Next.js React Server Components: a feature-flag service (Vercel Edge Config, GrowthBook, Statsig) determines a visitor's variant at request time, before the HTML is generated or served from cache. The server component reads the flag and renders the right version of the hero, the price or the CTA directly — no client-side JavaScript, no flicker. It is the most elegant method for testing a single element (a headline, a button colour) without duplicating the whole page, but it requires coding both variants into the component rather than driving them from a visual interface.

3. Classic visual tools: sometimes an acceptable trade-off

The flicker is not always a deal-breaker. For a quick test, on low traffic, or on a lower page section barely visible on initial load, the effect stays marginal and a visual tool remains unbeatable for simplicity with a non-technical team. Reserve this option for exploratory tests, and switch to split URL or a feature flag as soon as a test touches the hero or runs for more than a few weeks in production.

The invisible trap: sample ratio mismatch

Whichever method you choose, a sneakier danger lurks: an unintentional imbalance in traffic splitting. In their reference study published in 2012 at the KDD conference, Ron Kohavi and his Microsoft co-authors document this phenomenon under the name sample ratio mismatch — a programmed 50/50 split that ends up, in practice, at 47/53 because of CDN caching, poorly filtered crawler traffic, or a redirect that is slower for one variant than the other (study on Google Scholar). Such an imbalance silently invalidates the test's results, with no alert ever triggered. On an edge architecture like Vercel, concretely check the actual traffic split in your analytics after a few days, before trusting the conversion numbers.

Keeping the methodology rigorous

The choice of technical infrastructure does not replace rigour in the experiment itself. In their foundational guide to online controlled experiments, Kohavi, Longbotham, Sommerfield and Henne note that the value of an A/B test lies in its methodology — a clear hypothesis, a sufficient sample, a respected duration — far more than in the tool used to run it (study on Google Scholar). Before choosing your implementation method, make sure you have sized the test correctly: our complete A/B testing guide covers the basics, and our articles on test duration and statistical significance help you avoid stopping a test too early on a lucky streak.

The special case of LanderKit templates

Every LanderKit template ships as a self-contained Next.js mini-project, which makes split URL testing especially easy: duplicating the template folder to create a variant B breaks nothing architecturally, since each project is already independent. It is a good way to test two sales angles (a results-driven headline against a method-driven one, for instance) without putting your production page at risk. For deploying both versions, our guide on deploying Next.js on Vercel covers the steps, including running two separate deployments behind the same domain.