Site performance best practices

Optimizely Web Experimentation and Optimizely Personalization work to ensure that the snippet delivers the best possible experience to visitors to your site, but a few best practices can improve optimal site performance. Follow the guidelines below if you are concerned about performance issues or page flickering.

Place the snippet as the first script tag in the head of the page 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 directly in the response from the server. Do not deliver the snippet with any tag managers or inject it with client-side scripting.

Self-host the snippet to improve load times. For more information on self-hosting the snippet, see CDNs and Optimizely Web Experimentation.

Installing the snippet synchronously helps prevent page flickering. Asynchronous loading eliminates any delay in page load times but greatly increases the chances of flashing. Learn more about synchronous and asynchronous snippet loading, including the strengths and drawbacks of both load types.

Add preconnect and preload tags to cdn.optimizely.com at the top of the head for faster synchronous loading. Optimizely recommends using preconnect to open a connection to logx.optimizely.com, the event endpoint, beforehand.

Replace //cdn.optimizely.com/js/12345678.js in the example below with your snippet.

The snippet does not 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.

Optimizely recommends including jQuery natively on the page, synchronously, above the 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 has little or no impact on page load times and experiment execution. You may continue to use jQuery if you prefer, but it is not required.

Use Optimizely Web Experimentation’s holdEvents and sendEvents APIs along with hold or 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, you should use preconnect.

Increase the snippet Cache Expiration (TTL) 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.

By default, the basic snippet includes all pages and events you define in a project. Also, all pages you define for inclusion in a custom snippet are in the snippet as delivered on the page, regardless of their attachment to a running experiment or not.

To keep the overall snippet size small, avoid creating pages where you do not 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. You can also exclude unused pages from the snippet via automatic page trimming.

Create a custom snippet to reduce the size of your snippet and improve site performance. 

Increasing the snippet size diminishes site performance. One main cause of increased snippet size is unminified JavaScript, CSS, or jQuery code, which you might add to your site if you are testing substantial site changes like a page redesign.

Currently, you have three options for delivering substantial site changes within Optimizely Web Experimentation. The best options in terms of minimizing snippet size are to:

To deliver substantial site changes within Optimizely Web Experimentation or Optimizely Personalization, you should use 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):

You can load each instance of an extension called into an experiment synchronously or asynchronously. Create as many extensions as you need, use multiple extensions in one variation, or use the same extension multiple times in one variation.

To deliver substantial site changes like page redesigns outside of Optimizely Web Experimentation, like redirect experiments, you should embed all images and HTML blocks in the native HTML page and use show/hide to create the versions of the page you are testing.

You can also use an Optimizely Web Experimentation redirect test or host large code blocks as minified code in an external public file and call them into the experiment.

Each option is more effective than the options for using custom code and extensions to deliver substantial changes within Optimizely Web Experimentation for successfully reducing snippet size and increasing performance.

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. You can also target your testing for 4G LTE and faster speeds.

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.

You can use the shadow DOM setting to target elements in shadow DOM when using the Visual Editor. However, this can slow down your website as the snippet creates a bundle with the behavior to apply changes in shadow DOM elements, which increases its size.

See Enable shadow DOM support for the Visual Editor for information.