On August 25, 2026, Chrome 152 ships navigator.cpuPerformance to every user on Windows, Mac, Linux, ChromeOS, and Android. It is a single read-only property that returns a small integer from zero to four, meant to tell a website roughly how powerful the visitor's CPU is so it can decide whether to serve a 1080p video call with a virtual background or a 240p stream with the effects turned off. That sounds harmless, and the W3C Web Incubator Community Group (WICG) spec goes to real lengths to make it sound harmless: five possible values, a stated privacy goal that each tier should cover at least 10% of devices, and an explicit design rule that the value must never leak raw CPU model or vendor information. For anyone who spends their time thinking about fingerprinting, bot detection, or building scrapers, the interesting part is not what the spec says the API should reveal. It is what Chrome's actual implementation reveals once you read the algorithm behind it.
What the API is supposed to do
navigator.cpuPerformance is modelled on the older Device Memory API: a coarse, static signal rather than a precise one. It lives only in secure (HTTPS) contexts on Window, and it is explicitly not meant to compete with the dynamic Compute Pressure API, which measures how hard the CPU is working right now. The two are meant to work together: cpuPerformance tells a site what to load first, and Compute Pressure tells it when to back off once the page is running under load.
The spec's own example is a video conferencing app. Tier one is barely usable for a call at all, QVGA resolution at 15 frames per second with no effects. Tier four has performance to spare: 1080p at 30 frames per second, plus a virtual background. The spec even instructs developers to treat tier zero, meaning the browser could not classify the device, the same as tier four, so an unknown device gets the benefit of the doubt rather than the worst experience.
Chrome is not doing this alone for altruistic reasons. Rick Byers, who has been driving the proposal, has been candid on the blink-dev mailing list about why this exists: mobile Gmail has quietly maintained a server-side database mapping user agent and device-model strings to capability classes for years, similar to Facebook's old "Year Class" system, so it could ship different HTML and JavaScript bundles to different phones. This API takes a practice that has existed invisibly for over a decade and makes it a standard, inspectable browser feature.
The algorithm nobody is talking about
Here is where things get interesting for anyone working on unblocking or headless automation. On July 21, 2026, the spec's editor opened pull request #19, which adds Chrome's actual classification logic to the spec as normative text. Reading it strips away most of the mystery.
The algorithm works roughly like this:
1. Read the logical core count from the OS.
2. No core count reported, or zero cores → tier 0 (unknown).
3. Exactly one core → tier 1.
4. Two to four cores → check the CPU model against a hardcoded
list of "old or Atom-class" families (demote to tier 1) or
"modern efficient quad-core" families like Ryzen and Gracemont
(promote to tier 3). Everything else falls back on core count alone.
5. Five to ten cores → tier 4 if it is an Apple M-series chip or an
Intel Core Ultra with eight or more cores, otherwise tier 3.
6. More than ten cores → tier 4, unconditionally, regardless of
the CPU model.
Frequency is never consulted, despite the spec permitting it. In practice, the tier is hardwareConcurrency doing nearly all of the work, with a small demotion table for CPUs considered underpowered and a small promotion table for chips considered premium. The demotions cluster around Intel Atom-derived cores and very old Core 2 and Nehalem-era chips. The promotions cluster around AMD Ryzen, Intel's Gracemont efficiency cores, Apple silicon, and Intel Core Ultra.
That detail matters more than it looks. Because the model-matching table is public in the spec, the tier value leaks CPU family information in specific bands that no other browser API exposes directly. An eight-core device reporting tier four is very likely an Apple M-series machine or an Intel Core Ultra system: no other eight-core CPU family clears that bar. A four-core device reporting tier three is very likely a Ryzen or Gracemont-based chip, since the fallback path for a generic four-core CPU caps out at tier two. Marcos Caceres flagged the underlying concern in WebKit's standards-positions review, pointing out that a higher tier correlates with a more expensive device, and a more expensive device is itself a proxy for the visitor's disposable income. Ad targeting is not a hypothetical use case here either. It is listed as use case five in the WICG explainer itself, right alongside things like deciding whether to run an AI model locally.
Why this matters for scraping and bot detection
The entropy math looks reassuring on paper. Five possible values is roughly 2.3 bits, which sounds trivial next to the 15 to 25-plus bits that the Performance API family alone can expose through timing side channels. But cpuPerformance has a property those noisier signals do not: it is a single synchronous read, it costs no CPU time to compute, and the reproducibility requirement in the spec means it is guaranteed to return the same value across every session on the same device. Stacked with hardwareConcurrency, deviceMemory, screen metrics, and GPU adapter strings, it becomes one more piece of clean, free, stable entropy in the fingerprinting surface. Nothing about running traffic through a VPN or rotating IPs touches it.
For anti-bot vendors specifically, the more immediate use is not identification, it is coherence checking. A cloud VM with two virtual CPUs will report tier one, the same bucket the spec describes as "practically unusable for video calls." A four-vCPU instance lands at tier two. Meanwhile, nearly every real consumer laptop or phone from the last five years reports tier three or four. That split alone is a free, low-cost signal for separating datacenter traffic from real users, in the same category as the existing deviceMemory and hardware concurrency checks that detection vendors already fold into their scoring.
The more interesting failure mode shows up when a headless browser's reported cpuPerformance disagrees with everything else the page can measure about it. A patched Chromium instance claiming tier four while its actual JavaScript execution speed, hardwareConcurrency, and GPU signals all look like a two-vCPU cloud box is exactly the kind of internal inconsistency that coherence-based detection is built to catch. Zyte's own conversations with anti-bot vendors such as Castle at Extract Summit 2025 described this shift directly: detection has moved from a binary bot-or-not decision toward scoring an entire session for consistency across IP, TLS, browser fingerprint, and now, potentially, this new CPU tier.
Spoofing the value itself is trivial. It is one property on navigator, and Chrome even ships an enterprise policy, CpuPerformanceTierOverride, that lets administrators force it to any value from zero to four, which is itself a tacit admission that some deployments will not want the real number exposed. Overriding it in a headless context is a one-liner:
Object.defineProperty(navigator, 'cpuPerformance', {
get: () => 4
});
The catch is that the value alone was never strong evidence in the first place. What actually matters is whether it lines up with everything else the page can observe. This is the same lesson that shows up across TLS fingerprinting and network-level signals: a single spoofed header or property is cheap to fake, but a whole profile that has to agree with itself is much harder to fabricate convincingly. curl-cffi's browser-shaped TLS fingerprint solves one layer of that problem; a coherent cpuPerformance value that matches the emulated hardware profile is now one more layer to get right.
What to actually do about it
We aren't worried about breaking changes. But that doesn't mean you shouldn't be aware of it and decide if you need to take some precautions.
For anyone running headless infrastructure, the practical checklist is short. Do not simply hardcode cpuPerformance to four and call it done. If a browser session is emulating an eight-core M-series Mac, the CPU tier, hardwareConcurrency, GPU renderer string, and JavaScript execution timing all need to agree with that story, or the mismatch becomes the tell. This is exactly the kind of consistency problem that unblocking infrastructure exists to solve for, since maintaining a coherent fingerprint across dozens of signals at scale is a different job from spoofing any single one of them.
The interoperability story is worth watching too. Mozilla has taken no position, and WebKit has marked itself opposed, which means this is very likely to remain a Chromium-only signal for the foreseeable future, at least on the browser side. That does not make it any less relevant for automation built on Chromium, which covers the overwhelming majority of headless scraping tooling in production today.
Chrome 152 goes to stable on August 25, 2026, the last four-week release cycle before Chrome moves to a two-week cadence with version 153. Anyone maintaining anti-detect profiles, custom browser builds, or fingerprint-consistency checks has about a month to decide how cpuPerformance fits into that picture before it is live for every Chrome user on the web.
