Playwright's Chromium was x64 and counted primes in 297ms

Playwright Chromium counted primes in 297ms, and its executable was chrome-win64\\chrome.exe with an x64 PE Machine value.

The unexpected part was that the story did not end there. If an x64 browser is emulated on Windows ARM64, I expected heavy JavaScript to become plainly slower. In fact, the prime-counting result was 41,538 primes in 297ms. It was not slower than native Node.js. That was the moment my heavily assumed premise fell apart.

Of course, this is not a rigorous Node.js-versus-Chromium V8 comparison. It may be close to an E2E impression, but the V8 versions, startup flags, and JavaScript conditions inside the page were not aligned. Still, at least in this environment, it did not feel as though “x64 emulation makes E2E obviously heavy.” That is the most surprising part of the August 1, 2026 log. I still wonder a little why the prime count did not look expensive.

Inspect the browser itself first

I took p.chromium.executable_path from the Playwright Python API and read the PE header of that file. I launched the browser three times to time startup, and after launch I also collected navigator.userAgent, navigator.hardwareConcurrency, and navigator.deviceMemory inside the page. Deciding from the path name alone felt risky.

exe = p.chromium.executable_path
res["executable"] = exe
res["pe_machine"] = pe_machine(exe)

for _ in range(3):
    t = time.perf_counter()
    b = p.chromium.launch()
    launches.append(round((time.perf_counter() - t) * 1000))
    b.close()

On the JavaScript side, I only counted primes inside the page. It is a simple loop that divides each integer below 500,000 in order, so the DOM and network are largely irrelevant.

()=>{
  const t=performance.now();
  let c=0;
  for(let n=2;n<500000;n++){
    let ok=true;
    for(let i=2;i*i<=n;i++){
      if(n%i===0){ok=false;break}
    }
    if(ok)c++
  }
  return [c, Math.round(performance.now()-t)]
}

For page loading, I opened only two of my own sites: arm64-lab.pages.dev and ai-tool-hikaku.pages.dev on Cloudflare Pages. This was not a broad survey of congestion on external sites; I loaded pages I might actually touch in E2E.

Chromium calling itself x64

First, the executable information. The path contains chrome-win64, and PE Machine is x64. At least for the Chromium automatically downloaded by this Playwright, nothing like chrome-win-arm64 was retrieved for Windows ARM64.

Item	Value
executable	C:\Users\akirasakai\AppData\Local\ms-playwright\chromium-1200\chrome-win64\chrome.exe
pe_machine	x64
version	143.0.7499.4
launch_ms	446 / 198 / 199
hw_concurrency	12
device_memory	null

Startup took 446ms the first time, then 198ms and 199ms. I measured startup separately so page waiting and JavaScript time would not be mixed in. File loading and process initialization showed up on the first launch, while the second and third settled at nearly the same number.

hw_concurrency was 12. Chromium saw the host's logical core count directly. device_memory was null, so this API did not expose the amount of memory. I expected a value and got slightly stuck on that point.

The User-Agent returned this.

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/143.0.7499.4 Safari/537.36

What is interesting is that there is no sign of ARM64 at all. The empty device_memory also mattered in a small way. After Windows NT 10.0 comes Win64; x64, and HeadlessChrome identifies itself as 143.0.7499.4. From the site's perspective, this looks like ordinary x64 Windows Chromium. The assumption that x64 must be slow broke down here.

JavaScript was not as slow as expected

The prime-counting return value was [41538, 297]: the first half is the number of primes found, and the second half is the elapsed 297ms.

Operation	Result
prime count	41538 primes
elapsed	297ms

This is the core of the run.

The number itself is not dramatic.

Even though x64 V8 was running through emulation on Windows ARM64, it was not slower than native Node.js on this machine.

I expected the opposite.

I will not generalize strongly from this. I will measure it again alongside Edge. Node.js and Chromium use different V8 builds and startup conditions, and JavaScript running in a browser page is a different execution environment from Node.js on the CLI. The 297ms should be read only as the result of running this simple prime count in Playwright Chromium 143.0.7499.4.

Even so, JavaScript pure computation is not necessarily what controls E2E wait time. Page navigation, rendering, network, and waits in the test code also contribute. “Emulation makes everything twice as slow” did not fit this measurement. Without separating the layers, it is easy to identify the wrong cause.

Loading two Cloudflare Pages sites

Both page loads completed without errors. arm64-lab.pages.dev had wall 4961ms, Navigation Timing TTFB 4363ms, DOM 4400ms, and load 4949ms. ai-tool-hikaku.pages.dev had wall 1547ms, TTFB 712ms, DOM 1341ms, and load 1529ms.

URL	wall	ttfb	dom	load	title
https://arm64-lab.pages.dev/	4961ms	4363ms	4400ms	4949ms	ARM64 Lab — Measuring how far Windows on Snapdragon X Elite can go in real work
https://ai-tool-hikaku.pages.dev/	1547ms	712ms	1341ms	1529ms	AI Tool Comparison Notes — personal notes written after using paid plans for a month

The difference is difficult to explain with browser CPU alone. In particular, arm64-lab.pages.dev had TTFB of 4363ms and reached DOM at 4400ms, so most of the wait happened very early. It is weak evidence for saying Chromium is slow because it is x64-emulated.

ai-tool-hikaku.pages.dev reached load in 1529ms. In the range I tested, waits on the Cloudflare Pages side and the network sometimes stood out more than the fact that Headless Chromium was running under emulation. This measurement made Cloudflare-side waiting more visible than expected.

Easy ways to misread it

When I first saw the path, I thought chrome-win64 might be only a folder name. Reading the PE header returned x64, and the User-Agent also said Win64; x64. With all three aligned, it is reasonable to treat this executable as x64, at least.

The other trap was device_memory. I expected a browser to expose the memory amount, but the result was null. I cannot use it to write that the machine is seen as a 32GB system. Adding a number that is not in the JSON turns a measurement log into an opinion piece.

The interpretation of load time also needs care. Both Cloudflare Pages sites loaded, but the first had TTFB as high as 4363ms. Treating that as Chromium emulation performance would be a mistake. For the same reason as avoiding a path-name guess, wall time that includes the network and the 297ms page JavaScript need to be read separately.

So how should E2E users see this?

Using Playwright Chromium as-is on a Windows ARM64 machine means the test browser is, in fact, an x64 browser running under emulation. My local data from August 1, 2026 pointed that way through the executable path, PE Machine, and User-Agent. Cloudflare-side waiting was more noticeable than expected, so I was careful not to read it as browser performance.

That is why the verdict is conditional. It worked. Startup was 198ms to 199ms after the first run, and both pages loaded. The JavaScript prime count was 297ms, and personally I did not strongly feel slowness in this situation. Cloudflare-side waiting was visible, but that is not a browser issue.

However, if you believe you are validating native ARM64 Chromium, that is wrong. As long as you use the browser Playwright distributes, this environment is showing x64 Chromium behavior. The distinction may matter when investigating browser bugs, video, WebGL, or low-level encoding.

So far I have not experienced that as a problem in ordinary E2E tests: opening a form, pressing a button, reading text, and taking screenshots. For that range, the local numbers and my impression were not far apart. Next I would put the same pages side by side in native Edge and Playwright Chromium, including rendering and video playback. That should get closer to the browser-engine difference itself.