Prototyping Performance Ideas at the Edge

Testing a new performance optimization usually means standing up a server, pointing traffic at it, and hoping the instrumentation doesn’t get in the way of what you’re trying to measure. WebPageTest and Cloudflare Workers together remove most of that friction: WebPageTest can redirect requests to any origin, and Workers can intercept and rewrite those requests before they hit the network. That combination makes it possible to prototype an idea and measure its real impact in minutes.

The core setup is simple. A Worker acts as a programmable proxy: it listens for fetch events, can modify both requests and responses, and runs on Cloudflare’s edge network. Because Workers use the Service Workers fetch API, the request/response model is familiar, and the ability to stream HTML through an HTMLRewriter means you can rewrite markup without buffering the entire document.

Quick Worker Setup

Cloudflare offers a workers.dev subdomain with 100,000 free requests per day, which is plenty for experimentation. You’ll need Wrangler, the CLI tool for deploying Workers. After installing it, generate a starter project and update wrangler.toml with your account ID from the Cloudflare dashboard. Configure your API key with wrangler config, then publish with wrangler publish. Your worker will be live at https://wpt-proxy.<your-subdomain>.workers.dev.

For the examples below, the proxy worker checks an x-host header set by WebPageTest, fetches the original URL, and returns the response. The source is available on GitHub.

Pointing WebPageTest at Your Worker

WebPageTest supports an overrideHost scripting command that re-points an origin to a different domain. Every redirected request carries an x-host header so the target knows the original hostname. The script below sends all requests for www.bbc.co.uk through the worker:

Override the bbc.co.uk domain to wpt-proxy.prf.workers.dev

Multiple hosts can be overridden in one script, and HTTPS connections benefit from HTTP/2 connection coalescing when all requests go through the same endpoint. Wildcards are also supported, so a single script can cover several subdomains.

For bulk testing, three special strings make a script reusable across many URLs:

  • %URL% – replaced with the current test URL
  • %HOST% – replaced with the hostname of the current test URL
  • %HOSTR% – replaced with the hostname of the final URL after any redirects

A generic script using %HOST% overrides whichever host is being tested:

overrideHost %HOSTR% wpt-proxy.prf.workers.dev    
navigate %URL%

Measuring What a Single Connection Buys You

A practical experiment is to route all of a site’s domains through one worker, forcing every asset over a single connection. Each DNS lookup, TCP handshake and TLS negotiation that disappears is visible directly in the WebPageTest waterfall. Testing the BBC homepage this way — with all subdomains overridden and a UK test location on 3G Fast — shows the difference in filmstrip and connection timing.

overrideHost    *bbci.co.uk wpt.prf.workers.dev    
overrideHost    *bbc.co.uk  wpt.prf.workers.dev    
navigate    https://www.bbc.co.uk

Consolidating everything onto one domain isn’t always feasible, but with this workflow it’s trivial to quantify the potential gain before committing to architectural changes.

Rewriting HTML in the Stream

With HTMLRewriter, you can alter HTML as it flows through the worker. A CSS-selector matching syntax, along with standard DOM mutation methods, makes it easy to test ideas like self-hosting third-party scripts. One example rewrites any script tag whose src points to a proxiable domain, changing it to a first-party URL with a distinct path prefix. The worker then detects requests with that prefix and fetches the asset from the original source. That worker can be generated with:

wrangler generate test https://github.com/xtuc/rewrite-3d-party.git

Delaying or Altering Requests

Workers aren’t limited to rewriting content. You can also change request behavior to simulate conditions or measure resilience. A simple example delays a request by one second on a random basis, which can expose how your page behaves under slower third-party resources without leaving the test environment.

addEventListener("fetch", event => {    
    const host = event.request.headers.get('x-host');    
    if (host) { 
//....     
    // Add the delay if necessary     
    if (Math.random() * 100 < DELAY_PERCENT) {       
      await new Promise(resolve => setTimeout(resolve, DELAY_MS));     
    }    
    event.respondWith(fetch(originUrl, init));
//...
}

Custom HTTP/2 Prioritization

If your experiment involves HTTP/2 prioritization, Cloudflare Workers supports custom schemes through the cf-priority response header. The header format is <priority>/<concurrency>. For example, setting the priority of a response to 30 with no concurrency looks like this:

response.headers.set('cf-priority', "30/0");

Values of the form 30/1 or 30/n set concurrency to 1 or n respectively. With per-response control, you can stress-test a new prioritization scheme or run a bulk comparison against the default browser behavior.

The Payoff

The biggest barrier to performance work is often the delay between forming a hypothesis and measuring its effect. A worker-based proxy gives you a lightweight, repeatable environment for changing requests and responses arbitrarily. Combined with WebPageTest’s overrideHost feature, you can test everything from connection consolidation to script self-hosting without leaving your browser.