Performance Edge
The problem: client-side experiments cause flicker
Section titled “The problem: client-side experiments cause flicker”Standard Web Experimentation works by loading a JavaScript snippet that modifies the DOM after the page begins rendering. Even with synchronous loading, there is a window — sometimes just tens of milliseconds, sometimes several hundred — where the original page is visible before the variation takes effect. This “flicker” is the fundamental trade-off of client-side testing.
For high-traffic pages where page speed directly affects revenue (landing pages, product pages, checkout flows), flicker is not just a cosmetic issue. It increases bounce rates, confuses visitors, and can invalidate experiment results if visitors behave differently after noticing the page change.
Performance Edge solves this by moving the critical decision — which variation does this visitor see — from the browser to the CDN edge.
How Performance Edge works
Section titled “How Performance Edge works”Instead of loading the full Optimizely snippet and evaluating experiments in the browser, Performance Edge uses a lightweight architecture:
- Edge worker activation — When a visitor requests a page, the CDN edge node intercepts the request before it reaches your origin server.
- Variation assignment at the edge — The edge worker evaluates which experiments are active for this URL and assigns the visitor to a variation. This uses the same MurmurHash3 bucketing algorithm as the standard snippet but runs on the CDN server, not in the browser.
- Micro-snippet injection — The edge worker injects a tiny JavaScript payload (typically under 5 KB) into the HTML response. This micro-snippet contains only the specific changes for the assigned variation — not the full experiment configuration.
- Immediate application — Because the micro-snippet is embedded directly in the HTML response, it executes before any rendering occurs. The browser never sees the original content.
The result is zero-flicker experiment delivery. The variation is baked into the HTML before it reaches the visitor’s browser.
What stays the same
Section titled “What stays the same”Performance Edge changes how variations are delivered, not how experiments are designed or analyzed:
- You still create experiments in the Optimizely app using the visual editor or code editor
- Audience targeting, traffic allocation, and goals work identically
- Results flow to the same Stats Engine analytics
- The Optimizely dashboard experience is unchanged
What changes
Section titled “What changes”| Aspect | Standard snippet | Performance Edge |
|---|---|---|
| Where decisions happen | Visitor’s browser | CDN edge node |
| Snippet size | Full experiment config (can be 50-200+ KB) | Micro-snippet with only assigned variation (under 5 KB) |
| Flicker | Possible, especially on slow connections | Eliminated |
| Time to first variation | After snippet loads and executes | Before HTML reaches the browser |
| Complex audience conditions | Evaluated in browser with full JS context | Limited to edge-compatible conditions |
When to use Performance Edge
Section titled “When to use Performance Edge”Performance Edge is ideal when:
- Page speed is critical to conversion. Landing pages, product detail pages, and checkout flows where every millisecond matters.
- Your experiments are primarily visual. Text changes, image swaps, and CSS modifications work seamlessly at the edge.
- You have high traffic volume. The performance improvement compounds across millions of page views.
- Mobile performance is a priority. Mobile devices are most affected by snippet size and JavaScript execution time.
Performance Edge is not the right choice when:
- Experiments require complex client-side logic. Custom JavaScript audiences that inspect cookies, local storage, or DOM state cannot run at the edge.
- You rely on third-party data for targeting. DMP segments or real-time behavioral data are not available at the CDN edge.
- You need SPA support. Performance Edge operates on the initial HTML response. For single-page application route transitions, the standard snippet is still needed.
Configuration
Section titled “Configuration”Enabling Performance Edge requires:
- CDN integration — Optimizely provides edge worker scripts for supported CDN providers (Akamai EdgeWorkers, Cloudflare Workers, AWS CloudFront Functions, Fastly Compute). Your infrastructure team deploys the worker to your CDN.
- Experiment opt-in — Not all experiments automatically use Edge delivery. You enable Performance Edge per experiment in the Optimizely app. This lets you use Edge for simple visual tests while keeping complex experiments on the standard snippet.
- Audience compatibility check — The Optimizely app flags experiments with audience conditions that cannot be evaluated at the edge, so you know before launch.
Decision framework
Section titled “Decision framework”| Factor | Standard snippet | Performance Edge |
|---|---|---|
| Flicker risk | Present (mitigated by sync loading) | Eliminated |
| Audience flexibility | Full (JS-based conditions) | Edge-compatible conditions only |
| Setup complexity | Script tag in <head> | CDN worker deployment |
| Tier requirement | All tiers | Ultimate |
| Best for | Complex experiments, SPA, third-party targeting | High-traffic visual tests where speed is paramount |
For most teams, the standard snippet with synchronous loading provides acceptable performance. Evaluate Performance Edge when flicker is measurably impacting your conversion rates or when you need sub-millisecond experiment delivery on performance-sensitive pages.