Amadesa is investing a lot of resources to make sure that test content is delivered in a timely manner by its content delivery servers and provide a minimal impact on page load as possible. However, Amadesa servers are only one of the factors that contribute to page load time while the others are the design of the test and the elements that exist on page.
The following will explain what can you do to optimize your page load time.

When you consider testing a page on your web site (A/B, MVT or Behavioral Targeting) you may ask yourself the following:

Let’s assume that you integrate 6 elements on your web page. The following describe several scenarios and discusses how tests/tags can be designed to have minimal impact on your page load time.

Scenario 1 – No test is defined for the elements

In this scenario, the 6 elements are deployed on your web page and no test is deployed live that is utilizing those elements.
In this case, the page level tag will be making one hit to the Amadesa server and every element will be making another hit to find if there is a test defined for the element.
This will make a total of 7 hits to the Amadesa server (one for the page and one for each element). See illustration below showing the calls to the Amadesa servers recorded by FireBug.

The server calls, even if each one takes a small period of time, multiplied by the number of elements on the page can add up quickly.

In the following scenario you will see that with little consideration to test design the number of elements on the page will not impact significantly your page load.

Scenario 2 – Test is utilizing all elements

Let’s assume you integrated 6 elements on you web page and also create a cross site test that utilizes all those elements and deployed it live.

In this scenario, the 1st element is calling the Amadesa server, the Amadesa server identifies that there is a test defined for the element, picks a version, and downloads the content for all the elements of the selected version. The 2nd element identified that content is already downloaded and thus does not need to make another call to the Amadesa server. See illustration below, taken from FireBug:

In this scenario the page will make a total of only 2 hits to the Amadesa servers; one for the page level tag and one for the 1st element rather than 6 hits in Scenario 1 above. We saved 5 hits.

Scenario 3 – Test is not utilizing all elements

In this scenario, you have a cross site test deployed live which is only utilizing 3 elements out of the 6 on the page (the other 3 will be used in future test). In this case there will be 5 hits to the Amadesa servers; one for the page level tag, one for the 1st element in the test, and one for each element which is not associated with a test (1+1+3).
See illustration below:

Notice that the calls to cache.amadesa.com are not hitting the Amadesa decision making engine, but rather JS files downloaded from our Cache Domain Network (Akamai).

Scenario 4 – Using unutilized elements in a test

Let’s take scenario 3 and improve it a little. You will create another cross site test that utilizes the unused elements and deploy it live with 100% of the traffic to the control (meaning no impact on user interface).
In this case there will be only 3 hits to the Amadesa servers (we saved 2 hits from Scenario 3). One for the page level tag, one of the 1st element in the first test and one for the 1st element in the second test.
See illustration below:

Scenario 5 – Using funneled optimization

A funneled optimization is an optimization that is targeting a specific page (none cross site) or a specific set of pages. The pages are identified by a unique page id (var amPPid). Thus, any optimization that is defined on a funnel can be identified at the page level. Meaning when the page level tag is hitting the Amadesa servers, it will find all the optimizations identified for the page and will download the content.

So, let’s take scenario 4, tweak it a little and run both tests as funneled tests (one test for the user elements and one test for the unused elements). In this scenario the page level tag will hit the Amadesa server, find the 2 optimizations defined on the page and will download the content for both optimizations.
In this scenario there will be only one hit to the Amadesa server to download content as oppose to 3 hits in Scenario 4 and 6 hits in Scenario 1. See illustration below:

Conclusion

You can see from the above scenarios that you can design your tests in such a way that will optimize testing performance and thus reduce impact on page load.
Here are a few guidelines to summarize: