I frequently see test pages in which the control script is not placed in a good location. In this article, I want to talk about the things to consider when placing the control script into your test pages.
Latency
The presence of the control script in your page will introduce latency into the total load time of the page. When the control script executes, it generates a request for a Google resource called siteopt.js. The latency is attributed to the time it takes for siteopt.js to load. To demonstrate this, with Firefox, you can load siteopt.js in the presence of the Firebug add-on that can measure the amount of time that it takes the page to fetch various resources. For me, inside the Google corporate network, it takes on average about 20 milliseconds to load siteopt.js:
Redirection
If you are running an A/B experiment, the control script may cause a redirection to happen if Google decides that this particular visitor should see a page other than the A page. This means that all the processing that the browser is doing when the redirect takes place will be aborted when the new page is loaded.
Other Resources
Given these aspects of the control script, it is very important that the control script appear before any references to external resources. These include CSS, script, image, objects, and the like. The reason for this is that if the control script decides to perform a redirect, all the time and work involved in loading these resources will be wasted and, most likely, performed again in the target of the redirect. This leads to increasing the total latency that the visitor experiences.
Displayable Content
Because the control script loads alternative content used in the display of the page, it needs to appear before the points in the page that potentially use this alternative content. Additionally, it is very important that the control script appear before any content in the page that is displayed to the user.
The reason for this is, again, latency. If the control script were to appear after, say, the first paragraph of the page, the user would see that paragraph, experience a very brief latency, and then the rest of the page would display. However, if the control script were to appear before this paragraph, then the window remains blank during the small latency, and then the page would render as a whole. This is a better experience for the user.
Also, a browser may spend less time laying out the page because there is no interruption of the display of the page.
Document Type Declaration
Many pages have a document type declaration. It may look something like this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "https://www.w3.org/TR/html4/strict.dtd">
Browsers will change the way they parse an HTML file based on this declaration. In order to determine the type of a page, browsers will “sniff” for this declaration at the very beginning of the page. If they find a well formed declaration, then the parser for that document type will be instantiated.
It is very important that the control script appear after any document type declaration. The reason for this is that browsers will only look so far into an HTML document when sniffing for these declarations. The presence of the control script before the declaration may cause the browser to not find the declaration and to choose the wrong parser. This can have devastating effects on a page, potentially rendering it unusable.
Conclusion
So, in a well formed HTML document, the control script should be:
- After any document type declaration
- Before any other resources (CSS, scripts, etc)
- Before any displayable content (text, tables, etc)
In a well formed document, these restrictions are usually accommodated by placing the control script as the very first element of the head element, just after the beginning <HEAD> tag.
Comments:
Nice, totally agree Eric, I always recommend placing the tag just inside the head tag. However as you mention IE can trigger quirks mode if anything appears above the doctype so you need to place it after doctype and ideally before anything in the head section.
Thanks for explaining why the control script should as close to the top of the page as possible. Putting the control script in the head of our HTML would be somewhat difficult for me, because the web framework I’m using uses “layouts”, which make it difficult to customize the head of a page.
The other thing is that we try to push the loading of external scripts to the bottom of the page, which prevents blocking while external scripts are loaded. One way to achieve this might be to have your page sections consist of JavaScript at the bottom of your page that replaces the original content in the middle of the page with alternate content. This adds a bit of indirection to your page, but I think it would work.