A browser can use less CPU and still make the agent wait longer

The number I would put beside a browser's CPU saving is how long the person or job waited for the result. Those measurements answer different questions, and a fleet decision needs both.

Cloudflare's Kitesurf announcement provides a useful example. In its screenshot comparison, Kitesurf used 380 milliseconds of CPU against Chromium's 1,173 milliseconds, while elapsed time was 1,148 milliseconds against 637. Its HTML comparison also reported substantially lower memory use: 39.4 MiB against 273.7 MiB.

Those are vendor benchmark results, not measurements from my workload. They support a narrower conclusion than “the new browser is faster.” Less processing time and memory can be valuable even when an individual screenshot takes longer to arrive.

I would treat potential fleet density as a hypothesis to test. These numbers alone do not establish production concurrency, the price of an accepted session or the latency a queued customer experiences.

Decide what the browser is waiting for

Consider two hypothetical uses. One agent captures a large batch of public pages overnight. Another sits in a live support conversation, waiting for a page image before answering the customer.

The overnight job may have room to exchange per-page elapsed time for lower resource consumption. The live interaction may have much less room. Neither decision follows automatically from the word “agent” in a product description.

The workload also needs the right browser capabilities. Cloudflare identifies cases such as video, WebGL and long-lived authenticated state where Chromium remains the appropriate option. A renderer that cannot complete the page is not economical merely because its failed attempt was light.

That makes fallback part of the measurement. If a supposedly cheap run frequently hands the same task to another browser, the final bill includes both attempts. The latency includes the time spent discovering that the first route was unsuitable.

I would classify a small representative page set before running a large comparison. The classification should describe requirements, such as persistent login or graphics, rather than reward whichever implementation happens to finish the easiest pages.

Count accepted pages, not isolated operations

The useful comparison is accepted work under a shared resource and time budget. Keep the task, page mix, success criteria and concurrency policy visible. Record resource use and elapsed time separately, including queueing and fallback.

For the batch job, I would ask how many correct captures finish by the deadline. For the interactive job, I would inspect the slow end of the response-time distribution as well as the median. A pleasant average can hide a frustrating set of customer waits.

The result might justify two browser routes. It might justify one browser because operating two costs more than the measured saving. It might also show that the workload is dominated by remote page behaviour rather than local rendering resources.

None of those outcomes would invalidate the resource reduction in Cloudflare's benchmark. They would locate its value within a real task. That distinction matters when a technical improvement becomes a procurement claim.

I have not run this comparison and would not attach a saving to it yet. The proposed test is how I would decide whether the published advantage survives the work we need done.

Choose an agent browser by accepted work, elapsed time and resource use together; a CPU saving does not promise a shorter wait.