Profiling Cloudflare Workers with Wrangler and Chrome DevTools

Since Workers Unbound removed CPU limits that previously constrained edge compute, developers have been running increasingly heavy workloads—image processing, game logic, and complex algorithms among them. That new horsepower brings a practical problem: how do you find out where a Worker actually spends its CPU time, and how do you verify that a change made it faster?

Cloudflare's answer is to plug into tooling developers already use rather than inventing a proprietary profiler. The first result is beta support for the Chrome DevTools protocol in Wrangler, so you can profile a Worker locally with the same chrome://inspect workflow you might already use to debug a Node.js backend.

Setting Up a Local Profiling Session

The feature works through wrangler dev. After updating to the latest Wrangler release and cloning a project with a CPU-intensive Worker, start the development server with the inspect flag:

wrangler dev --inspect

In Chrome or Chromium, open chrome://inspect and add localhost://9230 under Configure. The wrangler[{Worker name}] target will appear in the Remote Targets list, where {Worker name} is your project name. Selecting inspect opens a DevTools window where you can switch to the Profiler tab.

From there the procedure matches any other Chrome DevTools performance session: click Start, trigger some requests to localhost:8787 in a separate tab, then click Stop.

Reading the Flame Graph

The recorded profile renders as a flame graph showing call stacks over the sampling period. In the included example, which deliberately allocates memory inside a loop that generates the first thousand integers, the visualization shows where execution concentrates.

Clicking a function such as handleRequest reveals an annotated source view of the Worker. Timing annotations make it clear that the memory allocations in the loop body dominate execution time. It's worth noting that this is profiling by stack sampling, so the timings are directional rather than exact. Functions that finish in under 100 microseconds may not show up in the profile at all, which is a useful caveat when your hot path involves very short calls.

What the Sampling Approach Means

Because the profiler records stack traces at intervals, it produces an approximation of where your code spends the majority of its execution time. Think of it as a way to confirm which functions are worth optimizing, not as a precise cycle counter. For finding the biggest bottlenecks in a Worker, that's usually enough to guide the next change—and then you can run the profiler again to see whether the flame graph shifted in the direction you expected.