By Mehdi HassanHow do you run A/B testing in Next.js without slowing the site?
You run A/B tests on a Next.js site without slowing it by choosing the variant on the server or at the edge, before any HTML reaches the browser. Edge middleware reads or sets a variant cookie and rewrites the request to a static version of the page, so the visitor simply receives the right page.
The slow way is the old one: load a testing script in the browser, hide the page while it decides, then swap headlines and buttons. That causes flicker, delays the largest paint and adds main-thread work on every page. A coded site built on Next.js for a marketing website doesn't need that compromise, because you control the request before it's rendered.
What are the options for A/B testing in Next.js?
There are four common approaches, and they differ mainly in where the variant is chosen. The earlier in the request it happens, the faster and cleaner the test.
Approach | Where variant is chosen | Flicker | Performance cost | Good for |
|---|---|---|---|---|
Edge middleware + static variants | At the edge, before rendering | None | Near zero | Page and section tests on marketing pages |
Server-side flag in a dynamic page | On the server per request | None | Slower first byte | Pages that are already dynamic |
Client-side flag in a component | In the browser after hydration | Possible for that component | Small to moderate | Below-the-fold or interactive elements |
Visual editor testing script | In the browser, page hidden until ready | Hidden by an anti-flicker snippet | High | Quick copy tests on low-stakes pages |
For most marketing tests, the first row is the right answer. If your site lives in a visual builder instead, our guide on how to A/B test in Framer, Webflow and Next.js compares the platform options.
How do you set up edge middleware experiments step by step?
Edge middleware experiments need a stable assignment, prebuilt variants and a clean handoff to analytics. Here's the setup we use.
Write the hypothesis and metric first
Name the page, the change, the primary metric such as demo requests, and the minimum run time. Agree on it before any code.
Build each variant as a static route
Create the variants as separate routes or as a variant segment, for example /pricing/a and /pricing/b, all statically generated.
Assign in middleware
In middleware, read the experiment cookie. If it's missing, assign a variant using your flag service or a weighted random split, and set the cookie.
Rewrite, don't redirect
Rewrite the request to the variant route so the URL in the browser stays /pricing. Redirects add a round trip and create crawlable duplicate URLs.
Expose the variant to analytics
Pass the variant to the page through the cookie and push an experiment_viewed event with the experiment and variant names once the page loads.
Tie conversions to the variant
Include the variant on the conversion event, so results come from the same analytics tool that reports leads.
End the test cleanly
Ship the winner into the base page, remove the variant routes and middleware branch, and delete the cookie logic.
Should you use feature flags for marketing site experiments?
Use a feature flag service when you run more than an occasional test, because it handles assignment, targeting, gradual rollout and a kill switch from one dashboard. Most flag tools offer an edge-compatible SDK that can be read inside middleware.
Keep the roles clear. The flag service decides who sees what. Your analytics tool measures what happened. Mixing the two, for example trusting a flag tool's conversion counts while marketing reports from GA4, leads to arguments about which number is right. Flags are also useful outside experiments: you can launch a new pricing page to staff first, then to everyone, without a redeploy.
Pros
- No flicker and no anti-flicker snippet
- Variants are static, so LCP and INP stay as good as the base page
- Works with any analytics tool through one event
- Flag dashboards let marketing pause a test without a deploy
Cons
- Each variant needs developer time to build
- Not suited to quick visual edits by non-developers
- Middleware logic has to be kept tidy and removed after tests
How do A/B tests affect SEO and AI crawlers?
A/B tests don't hurt SEO when every variant is a fair version of the same page, the test runs for a limited time and the original URL stays canonical. Google's own testing guidance asks for exactly that, and it warns against showing crawlers something different from users.
Because middleware rewrites keep one public URL, crawlers just see one of the variants, which is fine. Avoid redirect-based tests that expose /pricing-b to search engines, and if you must use separate URLs, add a canonical tag pointing to the original. Our guide to redirects in Next.js covers when a rewrite beats a redirect, and server-side rendering for AI crawlers explains why prerendered variants are safer than client-side swaps.
Hypothetical example: testing a pricing page headline and layout
For example, suppose a SaaS team wants to test whether leading with annual pricing increases plan selections. They build two static pricing variants, assign visitors in middleware with a 50/50 split, and push the variant name with both the page view and the plan-selection event.
They agree up front to run the test for at least two full weeks to cover weekday and weekend traffic, and not to peek and stop early. When it ends, the winner becomes the base page and the middleware branch is deleted the same day, so the codebase doesn't collect dead experiments.
Which pages are worth testing on a marketing site?
Test pages with enough traffic and conversions to reach a clear result, and test changes big enough to matter. On most startup sites, that means the homepage hero, the pricing page and the main signup or demo landing page.
- Messaging tests on the hero: the headline and subhead that frame the product.
- Offer tests on pricing: annual versus monthly emphasis, plan order, what the free tier includes.
- Form tests on demo pages: fewer fields, a different call to action, a calendar embed versus a form.
- Proof tests: case study placement or a comparison table near the decision point.
Small changes on low-traffic pages usually end inconclusive, which wastes weeks. Keep an eye on speed while tests run, using the guidance in improving INP on Next.js sites and our Core Web Vitals platform fixes, so a variant never wins simply because the other one was slower.
