Zero-Shift A/B Testing with Next.js and Edge Middleware
Zero client-side JS and CLS with Edge Middleware in Next.js for effective A/B testing. Improve CRO without performance penalties.
- Topic
- JavaScript
- Reading time
- 5 min
- Length
- 1,057 words
- Published
- Oct 2, 2026
09:43 pm IST
In this article
A/B testing is a cornerstone of Conversion Rate Optimization (CRO), but traditional methods often introduce performance issues and layout shifts that can negatively impact user experience and search rankings. The common problems with third-party tools like Optimizely and Google Optimize include the Flash of Original Content (FOOC) and Cumulative Layout Shift (CLS), leading to a degraded user experience and potential penalties from Google.
The source article from DEV introduces a technique leveraging Next.js Edge Middleware to perform A/B testing without these downsides. This approach ensures zero client-side JavaScript is needed, and it achieves a 0.00 CLS score, which is crucial for maintaining both performance and search engine rankings.
What Changed and Why It Matters
The significant change highlighted is the use of Edge Middleware in Next.js for bucketing users into experiment variants at the CDN level before HTML is delivered. This method eliminates the need for client-side DOM manipulation, which is responsible for FOOC and CLS issues. By pre-rendering the variant on the server, the browser receives a fully-formed HTML page with no layout shifts, enhancing both performance and user experience.
Traditionally, A/B testing has relied heavily on client-side scripts that manipulate the DOM after the page has loaded, causing visible shifts and delays. These scripts are often large, adding to the page load time and creating a poor user experience. By using Edge Middleware, the content variation is determined and served directly from the edge server, meaning that when the HTML reaches the user's browser, it is already tailored to the variant they are assigned to. This approach not only eliminates the FOOC but also ensures that the page's CLS score remains unaffected, which is crucial for SEO.
This is crucial for developers maintaining production codebases, as it means they can run A/B tests without compromising the site's performance or risking penalties from Google due to high CLS scores. It also streamlines the process by removing the need for bloated third-party SDKs, which can add significant weight to client bundles. By reducing the amount of client-side JavaScript, developers can ensure faster load times and a more seamless user experience.
Implementing Zero-Shift A/B Testing with Next.js
To implement this in a Next.js application, consider the following steps:
- Set Up Edge Middleware: Use Next.js Edge Middleware to assign users into experiment buckets at the CDN level. The middleware checks for a pre-existing cookie to determine if a user is part of a test variant, and if not, assigns them to one using a 50/50 split. This is done before the HTML is sent to the browser, ensuring no client-side JavaScript is required for these operations.
- Optimize Conversion Tracking: Use server-side actions to track conversions. This approach reduces client-side processing and enhances privacy by keeping user data on the server. The server can log conversions based on cookie data, ensuring that results are accurately attributed to the correct variant.
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/request';
const EXPERIMENT_COOKIE = 'plyxo_variant_hero';
export function middleware(req: NextRequest) {
const url = req.nextUrl;
if (url.pathname !== '/') {
return NextResponse.next();
}
let variant = req.cookies.get(EXPERIMENT_COOKIE)?.value;
if (!variant) {
variant = Math.random() < 0.5 ? 'control' : 'variant_b';
}
url.pathname = variant === 'variant_b' ? '/variants/hero-b' : '/';
const response = NextResponse.rewrite(url);
response.cookies.set(EXPERIMENT_COOKIE, variant, {
maxAge: 60 * 60 * 24 * 30,
path: '/',
});
return response;
}
export const config = {
matcher: ['/'],
};
This code snippet shows how the middleware operates. It checks if the user is on the landing page and then assigns them to a variant based on a random split. The variant is stored in a cookie, which persists for 30 days, ensuring users consistently see the same version on subsequent visits.
'use server';
import { cookies } from 'next/headers';
import { db } from '@/db';
import { experimentConversions } from '@/db/schema';
export async function recordConversion(actionName: string) {
const cookieStore = cookies();
const variant = cookieStore.get('plyxo_variant_hero')?.value || 'control';
await db.insert(experimentConversions).values({
experimentName: 'hero_conversion_test',
variant,
action: actionName,
timestamp: new Date(),
});
}
This server-side function captures conversion events and logs them in a database. It uses the variant from the cookie to ensure that the conversion is attributed correctly, which is crucial for analyzing the effectiveness of each variant.
Limitations of Edge-Based A/B Testing
While this method offers significant advantages, it is not without limitations. The complexity of setting up and maintaining an edge-based system can be higher than traditional client-side methods, particularly for teams unfamiliar with server-side rendering and CDN configurations. Additionally, this approach might not be suitable for smaller projects where the infrastructure overhead outweighs the benefits.
Moreover, the technique is most effective for static elements of the page that can be determined at the time of the initial request. Dynamic elements that rely on user interaction or real-time data might still require some client-side interaction, although this can be minimized. For instance, if a page needs to update frequently based on live data feeds, the edge-based approach may not fully address those needs without additional client-side logic.
Real-World Applications
For teams looking to implement this in a real-world scenario, this approach is particularly beneficial for large-scale applications where performance and SEO are critical. For example, e-commerce sites can use this method to test different product page layouts without risking their search rankings or degrading the user experience due to layout shifts.
In the context of Indian engineering teams, where mobile users are predominant, ensuring fast load times and seamless interfaces is crucial. This edge-based approach can help achieve these goals by minimizing client-side processing and optimizing server-side rendering. Given the diversity of internet speeds in various regions, reducing the amount of data that needs to be downloaded and processed on the client side can significantly enhance the user experience.
For further exploration on enhancing JavaScript performance, you might find our post on VoidZero's Open-Source Boost helpful, as it discusses optimizing JavaScript tools for better productivity.
In my experience, ensuring that your infrastructure can handle the additional load of edge processing is key. It might be beneficial to conduct a thorough analysis of your current CDN capabilities and possibly consult with your CDN provider to understand the potential performance impacts and costs associated with edge-based A/B testing. Additionally, testing the infrastructure under load conditions similar to peak traffic times can help identify any potential bottlenecks or issues before they affect end-users.
Sources
A/B Testing UI Variations with Zero Performance Penalty & Zero Layout Shifts
Every claim above was checked against this source before publishing. The analysis, the code and the opinions are mine.
Frequently asked
What is the main advantage of using Edge Middleware for A/B testing?
Edge Middleware allows for zero client-side JavaScript and eliminates cumulative layout shifts, enhancing both performance and SEO.
How does Edge Middleware improve performance?
By pre-rendering variants at the CDN level, it reduces the need for client-side processing and ensures fully-formed HTML is delivered.
Are there any limitations to this approach?
Yes, it can be complex to set up and maintain, and might not suit smaller projects where infrastructure overhead isn't justified.