Publicerad februari 06, 2019

Optimizely vs Adobe Target: Performance

There’s much to consider when choosing an experimentation platform.

Alex Finn
av Alex Finn
decorative yellow lines on background

While there are many small players in the space with different focuses, strengths, and teams behind them, Optimizely and Adobe Target have the largest experimentation customer bases. 

In the last few years, we’ve seen a big increase in customers switching from Adobe Target to Optimizely. We’ve learned that there are 7 major reasons why:

  • Performance
  • Deeper testing capabilities
  • Testing beyond web—SPAs, mobile
  • Faster results
  • Guidance and best practices
  • Developer productivity
  • Efficient experiment program management

In the next seven blogs, I’ll cover each in detail and how Optimizely differs from Adobe Target. Regardless of the solutions you are currently using or evaluating, these seven areas are important for you to consider for the overall health of your program.

Let’s take a look at the first topic—Performance.

Why Performance Matters

No matter how much potential an experimentation program has, the whole thing falls apart if your site is performing at an unacceptable speed. This is why Optimizely allows you to choose from many different options depending on what your business needs are. Whether using a custom snippet, self-hosted JavaScript, or a server-side approach, Optimizely has a “menu” of several options that ensure you get the best speed out of your program.

Adobe Target’s snippet performance is more of a one-size-fits-all. Optimizely, on the other hand, has a performance engineering team dedicated to making sure you get the solution that works best for your architecture.

graphical user interface, application

Client-side performance options

The out-of-the-box Optimizely Web configuration

Optimizely partners with leading CDN provider, Akamai, to deliver our snippet across the globe. Optimizely makes sure that out of the box, your snippet is built for speed. It’s compressed and heavily cached to make sure you don’t overpay the cost of downloading it over the wire. All of these out-of-the-box optimizations are critical for having the best snippet performance.

Self-hosted Snippets

Some Optimizely customers like Casper, have seen incredible results from self-hosting the snippet. They have seen 36% increase in site performance, simply by hosting the Optimizely snippet on casper.com. 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.

Custom Snippets

Along with a standard JavaScript snippet that holds the data for your entire project, you have several other options for improving performance. First, you can employ custom snippets. Custom snippets allow you to use a snippet that contains only the experiments you care about. This dramatically decreases the size of the snippets and boosts performance as well. For instance, let’s say you are an e-commerce organization with many marketing teams running experiments. You have experimentation teams for your homepage, category pages, and product pages. With Optimizely’s custom snippets, you’ll be able to control which experiments get included in your snippet. This means you can include only the experiments in a snippet relevant to your portion of the site.

Zero latency UI & server-side testing

If you have the technical resources you can implement experimentation programmatically from the UI down to the server. We went with an SDK-driven approach for our Full Stack product.

graphical user interface, application

How server-side experimentation works with Full Stack

Full Stack uses  in-memory bucketing so it already has all of the information it needs locally. This means users won’t perceive any noticeable latency. With Adobe’s API driven, server-side testing approach, a blocking API request is used to get decisions about which experiment variant to use. This adds even more load time to your current page. With Full Stack, load time is under a millisecond.

Stay tuned for our next blog post in this series where we will explore how Optimizely enables deeper testing capabilities allowing you to test the entire user experience from the UI down to the server-side business logic and data.