decorative yellow lines on background

 It’s gone from being a priority for technical teams to becoming a top priority for business and product leaders as well. Why? Performance can impact key business metrics like page or cart abandonment, conversion rates, and ultimately revenue. So, performance is no longer a nice-to-have, but a critical part of the user experience. To succeed, websites need to be fast. Developers need to learn new techniques to thrive in this new environment.

That’s why today we wanted to take time to highlight a flexible set of options that are available for implementing Optimizely Web to improve site performance. In the last month we’ve seen customers like Casper change their client-side implementation and experience a 36% improvement in their page load time. Our goal in this post is to highlight some of the most performant configurations of Optimizely Web so that you can continue to experiment at scale, while improving the speed of your site.

When it comes to running client-side experimentation there is a natural trade-off that has to be made between performance, user experience (ensuring experimentation is invisible to your customers), and the operational costs of more technical implementations. Kyle Rush, the VP of Engineering at Casper, shared “It’s a trade-off we struggled with for a long time. Should we follow web performance best practices and load Optimizely asynchronously, or follow what has traditionally been considered experimentation best practices and load it blocking as the first asset? Both of these approaches have their pros and cons.”

In the diagram below we aim to highlight some of the different configurations for Optimizely Web that you can tailor to meet your needs. These are some of the different configurations used by our most performance-focused customers:

graphical user interface

Each package offers a different benefit depending on what’s most important to you. If you want to maximize performance above everything else, and have the technical resources to complete a custom implementation, the package on the left is the best solution for you. Others, like Casper, who don’t want to load Optimizely asynchronously, can still see significant improvements from self-hosting the snippet. And lastly, thousands of customers today run performant sites with our out-of-the box solution on the right.

Not all sites should implement Optimizely the same way. It is important to consider your available configurations and how each element contributes to improving performance under various conditions. Put simply, addressing performance requires a thoughtful and deliberate approach to implementation. If you’d like to hear from our Performance team on their recommendations, best practices, and ask questions unique to your site you should join our upcoming performance webinar here.

Lastly, if you’d like to learn more about any of the implementation options profiled today, please contact your Customer Success Manager. While self-hosting the snippet will require some engineering resources to set-up, we have documentation for doing this with popular CDNs like Akamai, Fastly, Cloudflare, and Cloudfront. We also offer professional services that help expedite this process and help you get back to scaling your experimentation practice.

In the months to come we will be launching new features that help you automatically reduce the size of your snippet by removing unused data that may be affecting your performance. Stay tuned for further updates as we continue to make Optimizely Web the most performant client-side experimentation solution.