This is a joint post by Whelan Boyd, Senior Product Manager at Optimizely and Remy Guercio, Product Marketing Manager for Cloudflare Workers.
Experimentation is an important ingredient in driving business growth: whether you’re iterating on a product or testing new messaging, there’s no substitute for the data and insights gathered from conducting rigorous experiments in the wild.
Optimizely is the world’s leading experimentation platform, with thousands of customers worldwide running tests for over 140 million visitors daily. If Optimizely were a website, it would be the third most trafficked in the US. And when it came time to experiment with reinvigorating their own platform, Optimizely chose Cloudflare Workers.
Improving Performance and Agility with Cloudflare Workers
Cloudflare Workers is a globally distributed serverless compute platform that runs across Cloudflare’s network of 180 locations worldwide. Workers are designed for flexibility, with many different use cases ranging from customizing configuration of Cloudflare services and features to building full, independent applications.
In this post, we’re going to focus on how Workers can be used to improve performance and increase agility for more complex applications. One of the key benefits of Workers is that they allow developers to move decision logic and data into a highly efficient runtime operating in close proximity to end users — resulting in significant performance benefits and flexibility. Which brings us to Optimizely...
How Optimizely Works
Every week Optimizely delivers billions of experiences to help teams A/B test new products, de-risk new feature launches, and validate alternative designs. Optimizely lets companies test client-side changes like layouts and copy, as well as server-side changes like algorithms and feature rollouts.
Let’s explore how both have challenges that can be overcome with Workers, starting with Optimizely’s client-side A/B testing, or Optimizely Web, product.
Use Case: Optimizely Web
The main benefit of Optimizely Web — Optimizely’s client-side testing framework — is that it supports A/B testing via straightforward insertion of a JavaScript tag on the web page. The test is designed via the Optimizely WYSIWYG editor, and is live within minutes. Common use cases include style updates, image swaps, headlines and other text changes. You can also write any custom JavaScript or CSS you want.
With client-side A/B testing, the browser downloads JavaScript that modifies the page as it’s loading. To avoid “flash-of-unstyled-content” (FOUC), developers need to implement this JavaScript synchronously in their <head> tag. This constraint, though, can lead to page performance issues, especially on slower connections and devices. Downloading and executing JavaScript in the browser has a cost, and this cost increases if the amount of JavaScript is large. With a normal Optimizely Web implementation, all experiments are included in the JavaScript loaded on every page.
With Workers, Optimizely can support many of these same use cases, but hoists critical logic to the edge to avoid much of the performance cost. Here’s how it works:
This diagram shows how Optimizely customers can execute experiments created in the point-and-click UI through a Cloudflare Worker. Rather than the browser downloading a large JavaScript file, your Worker handling HTTP/S requests calls out to Optimizely’s Worker. Optimizely’s Worker determines which A/B tests should be active on this page and returns a small amount of JavaScript back to your Worker. In fact, it is the JavaScript required to execute A/B test variations on just that specific page load. Your Worker inlines the code in the page and returns it to the visitor’s browser.
Not only does this avoid a browser bottleneck downloading a lot of data, the amount of code to execute is a fraction of a normal client-side implementation. Since the experiments are set up inside the Optimizely interface just like any other Web experiment, you can run as many as you want without waiting for code deploy cycles. Better yet, your non-technical (e.g. marketing) teams can still run these without depending on developers for each test. It’s a one-time implementation.
Use Case: Going Further with Feature Rollouts
Optimizely Full Stack is Optimizely’s server-side experimentation and feature flagging platform for websites, mobile apps, chatbots, APIs, smart devices, and anything else with a network connection. You can deploy code behind feature flags, experiment with A/B tests, and roll out or roll back features immediately. Optimizely Rollouts is a free version of Full Stack that supports key feature rollout capabilities.
Full Stack SDKs are often implemented and instantiated directly in application code.
The main blocker to high velocity server-side testing is that experiments and feature rollouts must go through the code-deploy cycle — and to further add to the headache, many sites cache content on CDNs, so experiments or rollouts running at the origin never execute.
In this example, we’ll consider a new feature you’d like to roll out gradually, exposing more and more users over time between code deploys. With Workers, you can implement feature rollouts by running the Optimizely JavaScript SDK at the edge. The Worker is effectively a decision service. Instead of installing the JS SDK inside each application service where you might need to gate or roll out features, centralize instantiation in a Worker.
From your application, simply hit the Worker and the response will tell you whether a feature is enabled for that particular user. In the example below, we supply via query parameters a userId, feature, and account-specific SDK key and the Worker responds with its decision in result. Below is a sample Cloudflare Worker:
import { createManager } from '../index'
/// <reference lib="es2015" />
/// <reference lib="webworker" />
addEventListener('fetch', (event: any) => {
event.respondWith(handleRequest(event.request))
})
/**
* Fetch and log a request
* @param {Request} request
*/
async function handleRequest(request: Request): Promise<Response> {
const url = new URL(request.url)
const key = url.searchParams.get('key')
const userId = url.searchParams.get('userId')
const feature = url.searchParams.get('feature')
if (!feature || !key || !userId) {
throw new Error('must supply "feature", "userId" and "key"')
}
try {
const manager = createManager({
sdkKey: key,
})
await manager.onReady().catch(err => {
return new Response(JSON.stringify({ status: 'error' }))
})
const client = manager.getClient()
const result = await client.feature({
key: feature,
userId,
})
return new Response(JSON.stringify(result))
} catch (e) {
return new Response(JSON.stringify({ status: 'error' }))
}
}
This kind of setup is common for React applications, which may update store values based on decisions returned by the Worker. No need to force a request all the way back to origin.
All in all, using Workers as a centralized decision service can reduce the complexity of your Full Stack implementation and support applications that rely on heavy caching.
How to Improve Your Experimentation Setup
Both of the examples above demonstrate how Workers can provide speed and flexibility to experimentation and feature flagging. But this is just the tip of the iceberg! There are plenty of other ways you can use these two technologies together. We’d love to hear from you and explore them together!
Are you a developer looking for a feature flagging or server-side testing solution? The Optimizely Rollouts product is free and ready for you to sign up!
Or does your marketing team need a high performance A/B testing solution? The Optimizely Web use case is in developer preview.
- Cloudflare Enterprise Customers: Reach out to your dedicated Cloudflare account manager learn more and start the process.
- Optimizely Customers and Cloudflare Customers (who aren’t on an enterprise plan): Reach out to your Optimizely contact to learn more and start the process.
You can sign up for and learn more about using Cloudflare Workers here!