How the Optimize runtime works

Learn about what happens in your visitor's browser and how changes are applied.

There are three steps of the Optimize runtime that take place every time that a visitor comes to your site, which are covered below.

In this article:

Asynchronous download

The Optimize container script is asynchronous and this is great news, since it will not affect the regular functioning of your site. The Optimize container will download in parallel with other scripts and resources of your page and will not block them: other scripts that have downloaded first, will be able to run without a delay.

But you need to keep in mind that Optimize is typically modifying the content of your own page, so its priority is important.

This is why we recommend positioning the Optimize installation at the top of the <HEAD> to run as soon as possible, without been blocked by other scripts and libraries of your page.

Incorrect positioning of Optimize may cause flicker, a longer hiding period, and container timeouts (if you're using the anti-flicker snippet).

Anti-flicker snippet

A common issue whenever JavaScript code modifies an HTML page is flicker: visitors are able to transiently see the original version of the page, before it becomes modified.

With a tool like Optimize, this could cause confusion to your visitors and even make them realize that they are part of an experiment, with effects to your site as well as to experiment results. This is why Optimize has a number of different mechanisms to ensure that this does not happen.

A first level of defense in order to achieve this, is the anti-flicker snippet which is necessary because of Optimize asynchronous nature.

While a synchronous script will block the browser form parsing and displaying the page (and can stop your site from working in worst case), an asynchronous script may run at any time, even after the page is visible (and can’t be catastrophic for your site). This can cause flickering.

The anti-flicker snippet is introduced as a mechanism that ensures that your page is temporarily hidden, until the Optimize container has enough time to download. With correct installation on a typical page, the page hiding will not have any significant real effect, since the Optimize container will download in parallel with other scripts and resources of the page that block it from rendering.

The page hiding is not the only mechanism used by Optimize to avoid flickering since it will typically end before the page is actually available by the browser, in order to be modified by Optimize.

An important thing to note, is that the page hiding timeout does not correspond to the overhead that Optimize will introduce to your page; it is just a worst case guarantee. Furthermore the recommended value does not related to the performance of your site or Optimize, but mainly to your visitors network speed (in case of poor signal reception etc).

If the Optimize container hasn’t download (together with other page resources) and run on the visitor’s device (depending on network speed and conditions) when the timeout occurs, the page hiding ends and any Optimize experiments that may apply (when the container downloads later) will be abandoned, while the visit will be simply excluded from the experiment traffic.

Once the Optimize container has download the global page hiding will end, the container will evaluate experiment rules and will then ensure that only those elements involved in any chosen experiments variants remain hidden. Note that this may happen even if those elements are not in the page yet.


Targeting rule evaluation

Once the Optimize container has downloaded, it will evaluate the targeting rules of any experiments configured to be activated with the default page load option. Experiments that have non-default activation configured will wait for their activation events.

Note that the experiment model page which you may use to launch the Optimize editor is not relevant to targeting (even though it is initially assigned as the default targeting rule). To see exactly which rules apply to an experiment, you need to look to the targeting tab of the experiment details page.

A visitor will be assigned to a variant at his first visit on a page after the experiment has started (doesn’t have to be his first visit on that page). The assignment is random (based on the Google analytics client ID), following the variant weights. The visitor will remain in the assigned variant until the end of the experiment while actions that happen any time later (i.e. goals) are attributed to that variant.

Changing experiment weights will not reassign visitors. Even if you set a variant weight to zero, there may still be traffic on a variant from visitors that were assigned to it before the weight change.

Experiments are independent from each other. A single visit can participate in multiple experiments and you need to take care to ensure that there are no side-effects. So while it is perfectly fine to run multiple experiments on the same page, these should be done on different page areas while avoiding the introduction of bias (e.g. where the variant of one experiment promotes a variant of another experiment).

Note: Optimize variants are applied as a best effort. Even if some or all the CSS selectors of your variants don’t exist, or your JavaScript changes have mistakes and throw exceptions, the visit will still be measured as part of the experiment variant.

Finall, some of your targeting rules may be evaluated on the server side, resulting in completely pruning the experiment from the downloaded container.

Targeting rule evaluation flow diagram

Application of chosen A/B and MVT variants

Once the container has chosen its variants, it will attempt to apply them. A variant is defined as a list of change operations (shown in the Optimize editor) which are generally applied in order (there are some optimizations when there are no conflicts).

Each change is targeting a CSS selector that may correspond to one or more elements. Optimize knows if a change is targeting multiple elements, since this is detected by the editor.

Often the element of a change will not be available in the page at the time that Optimize runs. In such a case Optimize will ensure that it remain hidden once it becomes available, by adding a necessary CSS rule and will then pause the change list execution.

As soon as that target element becomes available, Optimize will apply the change, remove the hiding CSS rule, and attempt to apply the following change in the list in the same manner.

Once the browser has change the page status to ready (after the DOMContentElement event), Optimize will do a last best effort to apply all remaining changes. If the element of a change can’t be found at this point, Optimize will simply ignore it and move on.

Note: Style changes are typically implemented with CSS rules so they don’t need to go through the above process. Instead they are applied immediately as soon as Optimize loads and there is no need for additional hiding.

JavaScript changes have a target CSS selector as well, and will run once the element of this selector has become available by the browser.

Implementing an entire variant with a single JavaScript change (i.e. using jQuery) on <BODY> isn't recommended in Optimize since your code may run later than you intended. Try to restrict the target selector of a JavaScript to the elements that you want to modify, or the smallest possible parent container element.

Finally, a change may have a CSS selector that targets multiple elements (the Optimize editor supports selecting multiple elements by shift clicking) which may appear in a page at different times. Optimize will change them as they appear but will lift the hiding for all of them at the end.

Application of variants flow diagram

Was this helpful?
How can we improve it?