Testing performance changes without the risk

Performance tuning is rarely a matter of flipping a switch and hoping for the best. An optimization that looks good in isolation can behave very differently in production, and the worst outcome — a change that takes a site offline — is always a possibility when you push new code or configuration to live traffic. Cloudflare's Observatory has been designed to address this by letting users test performance experiments in a safe environment before they're deployed.

Observatory combines real-user monitoring (RUM) data with synthetic Lighthouse tests in a single dashboard. It identifies areas where a site is underperforming and suggests specific Cloudflare features to address the issues. For instance, if a Lighthouse report flags images as a bottleneck, the tool will recommend enabling Polish or using Image Resizing, both of which can be turned on with a single click.

The platform also serves as a testing ground for code-level experiments. Cloudflare Workers have long allowed developers to deploy JavaScript that runs before a site is served, and many performance-focused snippets have been shared through Cloudflare's documentation and templates. But verifying the impact of one of these snippets — and confirming it doesn't break anything — has historically required manual testing on a staging path or a more complex A/B setup.

Why code-level performance fixes are tricky

Consider a common problem like serving Google Fonts. The stylesheet comes from fonts.googleapis.com, while the font files themselves are hosted on fonts.gstatic.com. Each domain requires its own round trips for DNS, connection setup, TLS negotiation, and the HTTP request itself, and because the font files can't be downloaded until the CSS is applied, the requests can't be parallelized. In the worst case, that's eight sequential round trips before any text renders.

Because third-party resources are served from a different origin than the main page, they also can't be prioritized alongside critical first-party resources on a single HTTP/2 connection. A Cloudflare Worker can mitigate this by proxying and optimizing the Google Fonts delivery — reducing the performance penalty by roughly 81% in some cases — but the challenge is evaluating that Worker without exposing real users to an unproven change.

Experiments: test first, deploy if it works

Cloudflare's Performance Experiments feature, announced with Observatory, is built to close that gap. The workflow starts with Cloudflare Snippets, a platform for running small JavaScript fragments on the edge before a site is served. Unlike Workers, Snippets are designed for lightweight, user-created code that modifies behavior — improving performance, security, or UX — without the overhead of a full developer platform.

To run an experiment, a user takes a piece of JavaScript (for example, the Fast Fonts snippet mentioned above), pastes it into the Experiments window in Observatory, and clicks "test." Observatory then runs multiple Lighthouse tests with the snippet disabled, then again with it enabled. The results are displayed side by side as before-and-after scores, so the user can see exactly what impact the code would have — e.g., "this snippet would improve my Lighthouse score by 15 points."

If the results look good, the snippet can be deployed via Snippets, targeting either all requests or a specific subset of traffic. The rule engine allows granular scoping; for instance, a user could restrict the snippet to visitors from the UK or to specific office IPs. If the experiment degrades performance instead, the user can discard it safely and try a different approach — no real visitor traffic is ever affected by a failed test.

Availability

Performance Experiments are currently in development. Users can join a waitlist to request access, with initial admittances expected later this year, followed by an open beta. Until then, the best way to evaluate potential optimizations is still a staged deployment with careful manual testing.