Configure Performance Edge
Why flicker happens
Section titled “Why flicker happens”In standard Web Experimentation, the browser loads your page, then the Optimizely snippet evaluates experiments and modifies the DOM. Visitors briefly see the original content before the variation takes effect. This flash of original content — called “flicker” — degrades user experience and can bias experiment results if visitors react to the original before the variation renders.
How Performance Edge eliminates flicker
Section titled “How Performance Edge eliminates flicker”Performance Edge moves the bucketing decision from the browser to the CDN edge. When a visitor requests your page:
- The request hits the Optimizely edge network
- The edge worker evaluates experiment targeting and buckets the visitor
- The variation changes are applied to the HTML response before it reaches the browser
- The browser renders the modified page directly — no JavaScript-based DOM manipulation
The result is zero flicker. Visitors see only their assigned variation, from the very first paint.
Architecture overview
Section titled “Architecture overview”| Layer | Role |
|---|---|
| Optimizely edge network | Runs the bucketing logic at CDN points of presence worldwide |
| Edge worker | Evaluates targeting rules, assigns variations, modifies HTML |
| Your origin server | Serves the base HTML page as usual |
| Browser | Receives pre-modified HTML — no snippet-based DOM changes needed |
Performance Edge does not replace the Optimizely snippet entirely. The snippet still loads for analytics, event tracking, and experiments that require client-side JavaScript. Edge handles the initial rendering to prevent flicker.
Enable Performance Edge
Section titled “Enable Performance Edge”Step 1: Contact your account team
Section titled “Step 1: Contact your account team”Performance Edge requires server-side configuration by Optimizely. Your account team will:
- Enable the Performance Edge feature on your project
- Provision edge worker capacity for your traffic volume
- Provide the edge endpoint configuration details
Step 2: Configure DNS
Section titled “Step 2: Configure DNS”Point your site traffic through the Optimizely edge network. The exact setup depends on your hosting architecture:
Option A: CNAME routing
- Create a CNAME record pointing your domain to the Optimizely edge endpoint provided by your account team
- The edge network proxies requests to your origin server
- Experiment modifications are applied on the return path
Option B: Edge-side include
- Keep your existing CDN setup
- Configure an edge-side include (ESI) that calls the Optimizely edge API for bucketing decisions
- Apply modifications before caching the response
Your account team will recommend the best approach for your infrastructure.
Step 3: Configure eligible experiments
Section titled “Step 3: Configure eligible experiments”Not all experiments need to run at the edge. Configure which experiments use Performance Edge.
- In the Optimizely application, open your experiment
- Navigate to Settings > Delivery Method
- Select Performance Edge as the delivery method
- Save the experiment
Experiments using Performance Edge must meet these requirements:
- Variations use HTML/CSS modifications only (no custom JavaScript in the initial render)
- URL targeting uses exact match or simple pattern matching
- Audience conditions use server-evaluable attributes (location, device, query parameters)
Step 4: Verify edge delivery
Section titled “Step 4: Verify edge delivery”- Open your site and load a page with an active edge-delivered experiment
- Open browser developer tools and check the Network tab
- Look for the
x-optimizely-edgeresponse header — its presence confirms edge delivery - Inspect the HTML source — variation changes should appear in the initial HTML, not via DOM manipulation
- Disable JavaScript in the browser and reload — the variation should still appear
Performance Edge vs. standard delivery
Section titled “Performance Edge vs. standard delivery”| Aspect | Standard (snippet) | Performance Edge |
|---|---|---|
| Bucketing location | Browser | CDN edge |
| Flicker | Possible — depends on snippet load time | None |
| Time to first variation paint | After snippet evaluates (100-500ms) | At first paint (0ms additional) |
| Custom JavaScript variations | Supported | Not eligible — use standard delivery |
| Audience targeting | Full capability | Server-evaluable attributes only |
| Analytics and tracking | Via snippet | Snippet still loads for tracking |
Hybrid approach
Section titled “Hybrid approach”Most teams use a hybrid setup:
- Performance Edge for visual changes where flicker matters (hero sections, above-the-fold content, pricing tables)
- Standard snippet delivery for experiments requiring custom JavaScript, complex audience conditions, or third-party integrations
Both methods can run simultaneously in the same project. Assign each experiment to the appropriate delivery method based on its requirements.
Monitor edge performance
Section titled “Monitor edge performance”After enabling Performance Edge, monitor these metrics:
- Edge hit rate — Percentage of requests processed at the edge vs. passed through. Check in the Optimizely dashboard under Settings > Performance Edge.
- Origin response time — Edge adds minimal latency, but verify your origin response time is unchanged.
- Experiment activation rate — Compare activation rates before and after enabling edge to confirm consistent bucketing.
Troubleshooting
Section titled “Troubleshooting”| Issue | Cause | Fix |
|---|---|---|
| Variation not applied at the edge | Experiment not configured for edge delivery | Set delivery method to Performance Edge in experiment settings |
| Edge header missing from response | DNS not routing through edge network | Verify CNAME configuration and DNS propagation |
| Flicker still visible on some pages | Experiment uses custom JavaScript variations | Switch to CSS/HTML-only variations or accept snippet delivery for those experiments |
| Audience targeting not working at edge | Audience uses client-side-only attributes | Use server-evaluable attributes (location, device) for edge-delivered experiments |
| Cached variations served to wrong visitors | CDN caching the modified HTML | Configure your CDN to vary cache by the Optimizely bucketing cookie |
Best practices
Section titled “Best practices”- Start with above-the-fold experiments. These benefit most from flicker elimination since they are visible immediately on page load.
- Keep edge variations simple. HTML and CSS changes at the edge are fast and reliable. Reserve complex JavaScript interactions for standard delivery.
- Test with JavaScript disabled. If the edge-delivered variation appears correctly without JavaScript, your configuration is working.
- Monitor cache behavior. If you use a CDN in front of your origin, ensure it respects the Optimizely bucketing cookie to prevent serving the wrong variation from cache.