A/B testing on a static site works without losing speed if the page variant is chosen at the edge, not in the browser after the page loads. The server sends fully rendered HTML for the right variant right away, so the visitor never sees content swap in front of them. Here’s how that works technically, and what you can actually test this way.
Across Exceltic.dev projects, we see the same pattern over and over: a team wires a client-side A/B testing script into a landing page that already passed a speed audit, and a couple of weeks later the metrics in Google Search Console drop noticeably. The usual cause is that the script swaps content after the page has already rendered - the browser has to wait for the test code, repaint blocks, and recalculate layout.
For a site running paid traffic, this isn’t an abstract metric. A drop in LCP and CLS lowers conversion rate and raises cost per click in ad platforms, where page speed factors into ad delivery. Let’s look at why client-side tools break speed, and how to test variants at the edge instead - with no content jump and no extra script weight.
The typical scenario: a fast static landing page gets a script like VWO, Optimizely, or one of the Google Optimize successors bolted on to test a headline or a CTA button. The script loads after the HTML, determines the variant in the browser, and swaps the content on the fly.
Flicker of original content (FOOC): a brief flash of the original page version before it’s replaced with the test variant, visible to the user as a jarring jump in the interface. The script blocks rendering while it determines the variant, and adds its own weight on top - this drives up LCP, CLS, and time to interactive.
Why Client-Side A/B Scripts Break a Static Site’s Speed
A static site is fast precisely because the HTML for rendering is already prepared by the time the request comes in. A client-side A/B script breaks that model: it takes over in the browser, after the page has already partially rendered.
To avoid flicker, most tools hide the page content until the script determines the variant and swaps the DOM. That delays first paint and directly hits LCP.
On top of that comes the weight of the script itself - typically 20 to 60 KB compressed, plus a synchronous request to the testing server for variant configuration. On a slow connection, that’s another 100-300 ms before the user sees any content at all.
The result: a site that passed every Core Web Vitals check shows LCP climbing by tens of percent after testing goes live, along with CLS spikes from blocks swapping in. The difference is especially visible on mobile traffic, where both the connection and the device are weaker.
If your landing page’s speed is already suffering, it’s worth running a Core Web Vitals audit and speedup before adding tests - otherwise the A/B test ends up measuring conversion on a page that’s slow to begin with.
How Edge-Level Testing Works
Edge testing: an approach where the page variant is chosen not in the visitor’s browser, but at the CDN or edge function level - before the HTML ever reaches the client.
The user’s request doesn’t go straight to the static source - it hits an edge function running at the CDN point of presence closest to the user. The function checks a cookie to see whether a variant has already been assigned and, if not, assigns one at random according to a defined traffic split.
The edge function then serves the client the finished HTML page for the right variant - either by rewriting specific blocks in the HTML stream at the edge, or by proxying the request to a pre-built static version for that variant. Either way, the browser gets the final HTML immediately, with no script swapping anything in after the fact.
Edge platforms like Vercel Edge Middleware, Cloudflare Workers, and Netlify Edge Functions all support this pattern - each lets you run code before the response is generated and modify HTML or request routing at the CDN level, before it ever reaches the browser.
The key difference from the client-side approach: the user never sees the original version before the swap, because the edge function decides which variant to serve before the response is even assembled. Flicker simply can’t happen - there’s no client-side swap to begin with.
Comparing A/B Testing Approaches
Three main approaches to testing a static site differ in speed impact, implementation complexity, and cost.
| Approach | Speed impact | Implementation complexity | Cost |
|---|---|---|---|
| Client-side script (VWO, Optimizely, and similar) | High - flicker, render blocking, +20-60 KB | Low - drop in a snippet | Platform subscription, usually $100-300/mo+ |
| Edge function (Cloudflare Workers, Vercel Edge Middleware) | Minimal - HTML is ready immediately, no client-side swap | Medium - needs edge code and variant-assignment logic | Function execution costs, often within the free tier |
| Server-side redirect to separate static builds | Minimal after the first visit, but an extra redirect on entry | Medium-high - requires maintaining multiple site builds | Hosting multiple build versions |
A client-side script is the easiest to implement, but it’s also the one most likely to hurt your speed metrics - that’s the price of simplicity.
A server-side redirect to separate builds is fast after the first visit, but requires duplicating build infrastructure and manually syncing content between versions.
An edge function is medium complexity, but the best tradeoff between speed and flexibility for a team that already knows how to work with a CDN.
Step-by-Step Edge Test Implementation
Setting up an edge test comes down to four steps: assigning the variant, serving the right HTML, tracking conversions, and evaluating statistical significance.
Assigning and Locking the Variant to the User
On a visitor’s first request, the edge function randomly assigns variant A or B according to a defined split - for example, 50/50, or 90/10 if the test is just starting out.
The assigned variant is stored in a cookie for the duration of the test (a sticky cookie: a cookie that locks a variant to the user so they see the same version on repeat visits). Without this, the same visitor might see variant A on one visit and variant B on the next, which skews the results.
Example variant-assignment logic at the edge (conceptual)
on request:
variant = getCookie('ab_variant')
if not variant:
variant = random() < 0.5 ? 'a' : 'b'
setCookie('ab_variant', variant, maxAge: 30 days)
route to variant-specific HTMLServing the Right HTML
Based on the cookie value, the edge function either rewrites specific blocks in the HTML stream or proxies the request to a pre-built /variant-b/ version.
The second approach is easier to maintain for static sites: variant B is just a separate build folder, generated by the same static site generator as the main site.
Tracking Conversions by Variant
The client-side conversion event - a form submission, a CTA click - needs to pass the variant value along with the event to your analytics or your own test-data collection service.
Example conversion event tagged with variant (conceptual)
on formSubmit:
variant = getCookie('ab_variant')
sendEvent('lead_submitted', { variant: variant })Without an explicit variant tag on the conversion event, you have nothing to compare A against B with - analytics simply won’t know which version a given user saw.
Statistical Significance of the Result
Stop the test based on reaching statistical significance - typically a 95% confidence threshold with enough conversions on each variant - not on a gut feeling that “variant B looks better.”
For a lower-traffic landing page, collecting enough conversions can take several weeks. Checking significance too early and shutting the test down right away is a common mistake that produces a random result rather than a reliable one.
What’s Easy to Test on a Static Site, and What’s Hard
Edge testing works well for targeted changes within the same page structure.
Easy to test:
- headlines and subheadings;
- CTA button text and color;
- block order on the page;
- presence or placement of social proof - testimonials, client logos;
- lead capture form headline and structure.
Harder to test:
- fundamentally different page logic, like a different funnel flow or a different set of form fields with different validation;
- variants that depend on a server-side integration, like different price calculation;
- tests with more than 2-3 variants at once - edge logic complexity and traffic-per-variant requirements grow fast.
For scenarios with substantially different logic, it’s usually simpler to keep variant B as a separate build and explicitly route a share of traffic to it, rather than cramming everything into one edge function full of branches.
If a landing page is being built specifically for paid traffic, plan for testing at the development stage - that way the page structure is designed from the start for fast block swapping. This is one of the things we handle when building a landing page for paid traffic.
Common Mistakes When Implementing Edge A/B Tests
- Testing without a sticky variant. The user sees different variants on repeat visits, and the test data becomes unreliable.
- Too many variants at once. Three or four variants on low traffic stretch the test out to months instead of weeks.
- Stopping the test on a first impression. Stopping early when a difference looks visible, without checking significance, often produces a random result.
- Ignoring mobile traffic in the analysis. Behavior on mobile and desktop can differ, and an averaged result masks that difference.
- Testing on a page that’s already slow. The conversion difference between variants gets lost in the overall speed drop - fix the baseline performance issues first, for example using the paid-traffic landing page technical checklist.
Who This Is For
Edge testing makes sense for teams already running paid traffic to a static or headless landing page who aren’t willing to trade speed for conversion experiments. This matters most for projects where cost per click is directly tied to page speed as seen by the ad platform, and where development runs on a stack with CDN and edge functions - Vercel, Cloudflare, Netlify.
Frequently Asked Questions
Does A/B testing slow down a site? Client-side tools like VWO or Optimizely usually do - they block rendering and add script weight. Edge testing through Vercel Edge Middleware or Cloudflare Workers has practically no impact on speed, because the variant is chosen before the HTML is served, not after it loads in the browser.
What is flicker of original content, and how do you avoid it? Flicker (FOOC) is a brief display of the original page version before it’s swapped for the test variant. It only happens with client-side content swapping. With edge testing, the server serves the finished HTML for the right variant immediately, so flicker physically can’t occur.
Can you A/B test on Cloudflare Pages or Vercel without a third-party platform? Yes, both platforms support running code at the edge - Cloudflare Workers, Vercel Edge Middleware - which is enough to assign a variant via cookie and route to the right HTML version. A third-party testing platform is mainly useful for reporting and statistical calculations, not for the mechanics of serving variants.
How much traffic do you need for a statistically significant result? It depends on the page’s baseline conversion rate and the expected difference between variants - there’s no universal number. A calculator based on the chi-squared methodology can help you estimate this in advance: the lower the baseline conversion rate and the smaller the expected difference, the more traffic you need.
Is it worth testing more than two variants at once? Not on low traffic. Every additional variant splits an already-limited pool of conversions, stretching the test out to months. For landing pages with traffic below a few thousand visits a week, it’s smarter to test one change at a time.
If you’re running paid traffic to a static landing page and want to test hypotheses without risking your speed, tell the Exceltic.dev team about your project. We’ll look at your current site architecture and scope the work for edge testing.