- Optimizely X Web Experimentation
- Optimizely X Web Personalization
- Optimizely X Web Recommendations
This article will help you:
- Address performance issues like slow page loading and page flickering
- Improve your visitor experience
Optimizely works hard to ensure that the snippet delivers the best possible experience to visitors to your site, but a few best practices can help ensure optimal site performance. If you're concerned about performance issues or page flickering, check out the guidance below.
Use proper snippet placement
Place the snippet as the first script tag in the head of the page, but after all charset declarations, meta tags, and CSS inclusions.
If you use jQuery within variation code and jQuery is already included natively on the page, place the snippet directly after the jQuery.
Include the snippet in the server response
Include the snippet directly in the response from the server. Don’t deliver the snippet via any tag managers or inject it via client-side scripting.
Deploy the snippet synchronously
The snippet should be installed synchronously. Loading the snippet asynchronously increases the page load time and causes page flickering.
Use preconnect and prefetch tags
Add preconnect and prefetch tags to “cdn.optimizely.com” at the top of the head for faster synchronous loading. We recommend using preconnect to open a connection to
logx.optimizely.com, our event endpoint, ahead of time.
In the example below, replace
//cdn.optimizely.com/js/12345678.js with your snippet.
<!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <link rel="prefetch" href="//cdn.optimizely.com/js/12345678.js"> <link rel="preconnect" href="//logx.optimizely.com"> <!-- Add other meta information here --> <!-- Add stylesheets here --> <script src="//cdn.optimizely.com/js/12345678.js"></script> <!-- Add scripts and other content here --> </head> <body>
Follow jQuery recommendations (if your site uses jQuery)
The Optimizely X snippet doesn’t require jQuery to run, so you can remove jQuery from the snippet and your site. If you write experiment code in jQuery, you must make jQuery library 1.11.3 (minimum) available to the snippet.
We recommend including jQuery natively on the page, synchronously, above the Optimizely snippet. Optimizely can execute immediately using this library, with no page flickering.
Minify any jQuery and load it from a fast, trusted source. This load time will have little or no impact on page load times and experiment execution. You may continue to use jQuery if you prefer, but it’s not required.
Use the holdEvents and sendEvents APIs
Use Optimizely’s holdEvents and sendEvents APIs in conjunction with hold/send event APIs to hold events upon initial page load and send them after page load is complete, in consolidated batches. This consistently reduces page load time.
If you choose not to use the holdEvents and sendEvents API, we recommend using preconnect.
Increase the Cache Expiration (TTL)
Increase the Cache Expiration (TTL) of the snippet to a time that makes sense for the pace of experimentation, such as 10 or 20 minutes. Longer cache expiration times improve site performance. The default setting is 2 minutes.
Minimize the number of pages and events in your projects
By default, all pages and events you define in a project are included in the basic snippet. Also, all pages you define for inclusion in a custom snippet will be in the snippet as delivered on the page, regardless of their attachment to a running experiment or not.
To help keep the overall snippet size small, avoid creating pages where you don’t expect to run experiments, and archive any unused pages. Try to limit the number of pages and events in your projects to the minimum required to execute active experiments.
The snippet won’t include audiences and experiments that aren’t being used, so archiving unused audiences and experiments won’t affect snippet size. Also, running A/B tests as standalone experiment objects or underneath Personalization campaigns will not reduce snippet size or improve performance. All experiments and campaigns are represented with the same JSON data model in the snippet.
Use custom code and extensions to deliver substantial changes within Optimizely
Currently, you have three options for delivering substantial site changes within Optimizely. The best options in terms of minimizing snippet size are to:
Minify large blocks of custom variation code or shared code
To deliver substantial site changes within Optimizely, we recommend using a combination of custom code and extensions to deploy different blocks of code synchronously (for above-the-fold changes) and asynchronously (for below-the-fold changes):
Use an extension to define the above-the-fold changes as synchronous
Use custom variation code to define the remaining page changes as asynchronous
You can load each instance of an extension that is called into an experiment synchronously or asynchronously. Create as many extensions as you need, use multiple extensions in one variation, or even use the same extension multiple times in one variation.
The options in the Use show/hide elements to deliver substantial changes outside of Optimizely section are generally more effective for reducing snippet size and increasing performance.
Use show/hide elements to deliver substantial changes outside of Optimizely
To deliver substantial site changes like page redesigns outside of Optimizely, such as in redirect experiments, the best option is to embed all images and HTML blocks in the native HTML page. Then, use show/hide to create the versions of the page you’re testing.
Another option is to use an Optimizely redirect test. You can also host large code blocks as minified code in an external public file and call them into the experiment.
Each of these options is more effective than the options for using custom code and extensions to deliver substantial changes within Optimizely in terms of successfully reducing snippet size and increasing performance.
Use analytics to target your testing
Use an analytics tool to identify traffic that represents your visitors so you can optimize your site for the majority of people who visit. For example, if you find that most of your traffic is from mobile devices, you can target your experiments for mobile users. Further, since an estimated 70% of mobile subscribers in the US connect on 4G LTE and 3G is no longer considered a representative connection speed, you can target your testing for 4G and faster speeds.
Use time to first paint rather than time to interactive
If you want to measure bounce rate, use the time to first paint (TTFP) metric rather than time to interactive (TTI). TTFP can be measured, whereas TTI is less measurable because many factors can influence when a visitor actually interacts with a page after it is ready.