How Optimizely Performance Edge works
Optimizely Performance Edge gets its speed by moving work out of your visitors' browsers and into CDN edge servers. Three components work together to deliver super-performant Web experimentation, the Edge Decider, microsnippet, and tracking snippet.
- First, an HTTP service called the Edge Decider receives a request that originates from your visitor's browser. This service identifies which pages are active, computes which experiments the visitor is eligible for, and buckets the visitor into experiment variations. This service is deployed on high-powered CDN servers that are geographically close to your visitors.
- The Edge Decider responds to the visitor’s request with an optimized, minimal piece of JavaScript code called the microsnippet, built specifically for the given visitor and page. The microsnippet runs in the visitor’s browser, where it applies the set of changes that the Edge Decider selected.
- Finally, the microsnippet injects onto the page an asynchronous tracking snippet, which sends events (for example, conversion and click events) back to Optimizely.
Edge Decider
Main job: Decide which changes need to be applied to the page and return a corresponding microsnippet.
The order of operations in the Edge Decider is the following:
- The service receives a request from your CDN, with essential information (for example, visitor ID, page URL) supplied through headers and query parameters.
- Fetch the experiment configuration for the relevant Performance Edge project.
- Decide which pages configured in the project are active. Not all page triggers and conditions are supported in Performance Edge. See the Core functionality section in the Optimizely Performance Edge and Optimizely Web Experimentation documentation for a list of what is supported.
- Of the experiments running on active pages, decide which are active for the given visitor. This decision is based on the experiment’s traffic allocation and audience targeting.
- For each active experiment, bucket the visitor into a variation. This is based on applying a consistent hashing function to the provided visitor ID.
- For each of the chosen variations, identify the set of changes that need to be applied to the page.
- Return a microsnippet that contains decision results, change definitions, and more.
Microsnippet
Main job: Apply changes and inject the asynchronous tracking snippet.
The microsnippet is the JavaScript code returned from the Edge Decider, tailor-made for each individual visitor and page. Because all of the decision-making for your experiments happens at the edge, the scope of work for the microsnippet is much smaller than that of traditional Web snippets.
The microsnippet does the following:
- Forwards events and performance telemetry to the asynchronously-loaded tracking snippet
- Sends performance telemetry to Optimizely.
- Enqueues experiment changes to be applied. The timing of applying these changes depends on the type of change. For example, most visual changes are applied to targeted elements as they display, while redirects and custom code are applied immediately.
- Initiates listening for click events on active pages.
- Immediately injects the tracking snippet with a "defer" attribute, which ultimately sends events to Optimizely.
If you are writing code that is dependent on the timing of the microsnippet's effects, note the order of operations during the microsnippet's synchronous phase.
- Initializes get APIs.
- Runs Project JavaScript.
- Applies changes for active experiments. For each experiment that includes custom code, experiment shared code runs before variation code.
For comparison, see the Optimizely Web Experimentation's Snippet order of activationOptimizely Web Experimentation's Snippet order of activation.
Tracking snippet
Main job: Send events to Optimizely.
The last phase of execution is handled by the tracking snippet. It sends to Optimizely events and performance telemetry collected by the microsnippet. The tracking snippet has no public JavaScript API.