The Black-Box Problem With Third-Party Scripts

Loading third-party tools on a website has always been a trade-off. Site owners get useful functionality, but they also inherit whatever comes along with an opaque blob of minified JavaScript: potential performance hits, privacy risks, and zero visibility into what the code actually does or when it runs. There is no way to audit it, no guarantee it behaves consistently across visits, and no warning when the vendor changes something.

Cloudflare Zaraz was built to address this by moving third-party logic out of the browser and into server-side Workers. Integrations were written so that a tool would prepare a payload and send it, with the browser executing as little code as possible — often none at all. That worked well when Cloudflare engineers wrote every integration themselves. But once third-party vendors started asking to contribute their own integrations, the system broke down. Nothing in the architecture stopped a vendor from simply dumping their old client-side JavaScript into the clientJS variable and calling it a Zaraz integration. That defeated the entire purpose.

The core challenge was trust. Zaraz integrations needed to be fast and safe by construction, not by whoever happened to write them. That required a new format for defining third-party tools — one that gives vendors a way to build proper server-side integrations while giving website owners transparency and control over what runs on their pages.

Serving Endpoints and Rendering Widgets Server-Side

The result is Managed Components, a format designed for vendors that want to reimagine their tools rather than port them. At the core of each Managed Component is a JavaScript module, but that module is never shipped to the browser. Instead, it executes inside a Components Manager — a runtime that handles event dispatch, caching, storage, and sandboxing, and exposes APIs the component can use to interact with page data.

A simple analytics component, for example, receives notifications of page views, builds a payload with the visitor's user-agent and the page URL, and sends it as a POST request to the vendor's server. This achieves the same result as a classic analytics script, but with zero browser-side code.

Managed Components go beyond recreating what was already possible. They can expose server-side endpoints under the same domain as the website, meaning a third party can proxy content or add dynamic responses without forcing the user's browser to communicate with yet another external server. The permission model is granular: a component that wants to set cookies, manipulate the DOM, collect IP addresses, or serve content needs to be explicitly granted each capability. Adding a tool becomes like installing an app — you see exactly what it can do and can deny features you're not comfortable with.

The full list of capabilities is substantial:

  • Same-domain assets: Components can serve files from the website's own domain, improving performance and security while reducing bandwidth costs for vendors.
  • Website-wide event hooks: Components can subscribe to an existing tracking events system, so users don't have to learn a vendor-specific browser API.
  • Server-side logic: Vendors can run code on the same domain as the website, including proxying downstream servers or handling dynamic requests.
  • SSR widgets and embeds: Widgets render at the edge so they're already part of the HTML when it reaches the browser. No layout shifts, no extra round trips to fetch embed data.
  • Cross-platform events: Components can listen for clicks, scrolls, and other client-side events without worrying about browser or device quirks.
  • Pre-response actions: Server-side actions can run before the network response is delivered, including inspecting or modifying the response object.
  • Built-in consent support: Because components are scoped and predictable, the manager knows precisely what consent is required before a tool can run.

An Open Format Rather Than a Closed Platform

During early work with vendors, a question kept coming up: would Managed Components only ever work inside Cloudflare Zaraz? To avoid creating another walled garden, Cloudflare is open-sourcing the whole ecosystem.

WebCM is a reference implementation of the Managed Components API. It's a full Components Manager that can be used in production, independently of Cloudflare. WebCM operates as a proxy in front of a website, rewriting pages where necessary and attaching a few endpoints. Since it works at the HTML level, it's completely framework-agnostic — it doesn't matter if the origin runs on Node.js, Python, or Ruby.

Several previously-built Zaraz integrations are also being converted into open source Managed Components. That means, for example, you can run Google Analytics entirely server-side using WebCM, without any Cloudflare infrastructure in the path.

A number of vendors have already built their own components. Drift uses the new format to run its conversational marketing and sales platform while remaining sandboxed and making no third-party network connections from the user's browser. Crazy Egg has written a component for its heatmaps, A/B testing, and session recordings that takes advantage of capabilities impossible with classic third-party JavaScript. Hopin's frontend team has reported meaningful page load savings from moving Drift's library to an edge worker and off the DOM.

On the roadmap: publishing full specifications for the Managed Components format, drivers for other runtimes — service workers, HTTP servers, framework plugins — and mobile support. Cloudflare is also working on letting website owners install unofficial components that haven't gone through its own review process.

More details are available by contacting the team directly at [email protected] or via the Cloudflare Developers Discord.