Sawiday’s experimentation journey had hit a wall. Every new test they wanted to run came with a hidden tax: not just the increasing costs from their vendor, because of the per-visitor pricing model. Each additional experiment meant more code loading on visitors’ browsers, creating a vicious cycle—the more they tested to improve performance, the slower their site became.

The performance impact created a genuine dilemma: their client-side testing tool meant that the more experiments they ran to improve user experience, the more they risked harming site speed—which directly affects Google rankings. They found themselves having to balance innovation with maintaining their search visibility, a trade-off no growing business should have to make.

It was the classic challenge of client-side testing playing out in real-time.

Luckily, Sawiday was already using Cloudflare proxy services as a protection measure against DDOS attacks. This means they can also enable Workers within their plan to run apps, such as A/B testing tools. So we proposed implementing the GrowthBook Edge SDK as a Worker within their infrastructure. The GrowthBook Edge SDK would use Cloudflare KV storage to deliver experiment data, and for extra flexibility, it would also hydrate a JavaScript SDK that can run on the client for post-worker experiments (i.e., when the visitor has to scroll below the fold for an experiment to start).

So how does this help Sawiday reduce their experiment costs? Well, based on the site structure analysis we performed, we can estimate a total traffic cost with Cloudflare Workers of just €10 per month.

Now to drive this point home: because Cloudflare Workers run on all your site traffic, this means you can now run an unlimited number of experiments, and the more you test, the lower the cost per experiment becomes.

On the performance side, we can also achieve massive improvements because:

• Server-side experiments are rendered within the Worker, so there’s no performance loss at all—experiments are finished rendering when they arrive at the client (visitor’s device).
• Client-side experiments load almost instantly because all the code for the experiments comes with the Worker. Normally, an experiment tool has to load on the client and then retrieve the experiment data from the experiment tool’s CDN. This additional round trip is where most performance impact occurs, but with this setup, we can skip this trip. That means you go from approximately 0.150 seconds for traditional client-side test loading to 0.015 seconds with the new setup.

Basically, a 10x performance improvement and virtually unlimited testing capacity for the price of a few cups of coffee per month.

With a new technical foundation built for scale and performance, Sawiday is now ready for the future with new additional features that were not possible before. For example:

Experiment development is now possible within the existing workflow using GitHub. No more copy pasting code between IDE’s and visual editors. Makes for an easier and more efficient way of working for developers.

Developers can now join the experimentation party by adopting the feature flagging technology that exists in Growthbook and offers more sophisticated ways to test new features, like for example “Safe Rollouts” where a feature is deployed based on the impact on custom guard rail metrics, i.e. more traffic when impact is positive or decrease traffic or stop when negative impact is detected.

And last but not least, because GrowthBook is now running on Cloudflare workers, we can also start thinking about running SEO experiments.

This was a pretty technically advanced implementation. Not everything went flawlessly, but in the real world, that’s rarely the case—what matters is how you work together to get through it all. For example, we didn’t have full knowledge of Sawiday’s tech stack, but it was great to collaborate on this, and the team at Sawiday was fully committed to making it work. We’re very thankful for that, as it made our job much easier.