On August 25, 2026, Chrome 152 arrived in the stable channel for Windows, Mac, Linux, ChromeOS, and Android — bringing with it the property navigator.cpuPerformance. A single number from 0 to 4 that the site reads synchronously, without permissions and without a single computation cycle. It is designed as a hint for video calls and streams: a weak device receives 240p without background blur, while a powerful one gets 1080p with effects. Two weeks after the release, the scraping industry is discussing something else: anti-bot systems now have a cheap and stable signal about the hardware on which your browser runs.
What the Browser Reveals
The property returns not gigahertz or the model of the processor, but a "tier" of performance. According to the WICG explanatory note, there are four tiers plus zero:
- 0 — unable to classify the device;
- 1 — practically unsuitable for heavy tasks;
- 2 — weak, but functional;
- 3 — comfortable for typical scenarios;
- 4 — powerful, with headroom for multitasking.
The specification explicitly prohibits revealing the vendor, model name, and number of cores, requires HTTPS, and aims for privacy: each tier should cover a significant share of devices on the internet — around hundreds of different CPU models, so that the value does not narrow the audience down to a few.
The actual implementation in Chromium turned out to be simpler than the specification. In a Zyte analysis, it is shown that classification relies primarily on the number of logical cores and a built-in table of boosts and downgrades: frequency is not considered at all, although the spec allows it. Boosts are given to AMD Ryzen, Intel Gracemont cores, Apple silicon, and Intel Core Ultra; downgrades go to Intel Atom and processors from the Core 2 era. The rough mapping looks like this: single-core and very weak machines fall into the first tier, two to four cores give the second, four to ten cores or modern energy-efficient chips — the third, while eight or more cores on Core Ultra, Apple M-series, and anything with ten cores or more — the fourth.
Why This is a Detection Signal, Not Just Another Byte of Entropy
By itself, the value is weak: five options provide about 2.3 bits of entropy, less than what the interface language gives. The danger lies in three other properties.
It is free. To measure the actual speed of JS execution with timing, the detection script needs to occupy the processor for tens of milliseconds, which is noticeable in the profiler. Here — synchronous reading of the property, zero costs, zero traces.
It is stable. The value does not depend on the machine's load at the moment of checking: it is a class of hardware, not current utilization. Between sessions, restarts, and IP changes, it remains the same — meaning it is suitable as part of a long-lived profile identifier.
It is checked for consistency. This is the main point. Modern anti-bot engines rarely ban based on a single field — they look for internal contradictions in the set. A device claiming tier four must confirm it with a plausible navigator.hardwareConcurrency, reasonable navigator.deviceMemory, a modern GPU renderer string, and corresponding JS execution speed. A profile that claims tier 4 while executing a benchmark like a dual-core virtual machine gets caught by trivial cross-checking.
Separately, this creates a nearly ready divide between "data center" and "live user": a typical cloud instance with two vCPUs honestly reports the first tier, while consumer laptops and phones live in the third to fourth. For a scraper running on a cheap VPS in headless mode while posing as a regular Chrome on Windows, this is an inconvenient combination.
How This Differs from hardwareConcurrency, Which Has Always Been There
A reasonable question: the number of cores was previously read by the site through navigator.hardwareConcurrency, and memory size through navigator.deviceMemory. What has changed?
The connectivity has changed. hardwareConcurrency is a raw number, and it has been spoofed widely and for a long time: you can set eight instead of thirty-two, and the issue is settled. cpuPerformance is a derived value, calculated by the browser based on a built-in table. Once two fields appear in the set, one of which is computed from the other, any one-sided modification breaks the connection between them. If four cores are set, but the tier remains four — according to the logic of implementation, such a combination requires either Apple silicon, Core Ultra, or ten cores; thus, either the number of cores is lying, or the GPU string is lying, and it is enough for the detector to notice the mere fact of inconsistency without figuring out where the lie is.
This is exactly why old checklists of "which fields to spoof in the profile" become outdated not by one item but by entire blocks: the right question now is not "what to spoof," but "what consistent hardware configuration do we end up with in total."
Who is Most Affected by This
Chromium-only — and this is not a mitigating circumstance. WebKit has taken a "against" position on this API, and Mozilla has not publicly stated a position, so this property will likely not be present in Safari and Firefox. However, the overwhelming majority of production automation — Playwright, Puppeteer, nodriver, Patchright, agent browsers — is built on Chromium. This means the signal lands precisely in the niche where it is least expected.
The contradiction hits hardest on mobile profile emulation. If an anti-detect profile pretends to be an Android smartphone, and cpuPerformance under it reports "4" because the browser is physically running on a desktop with Ryzen, this is not a minor inaccuracy but a mutually exclusive pair of signals. The same goes for farm scenarios, where dozens of profiles with different "devices" live on one host machine and therefore give identical tiers.
What This Changes for the Parsing Stack
Several practical implications for those running headless browsers in batches.
- Containers inherit from the host. A browser in Docker sees the cores of the host machine, not the cgroup limits — meaning ten containers on one beefy server will yield ten identical maximum tiers. The diversity of profiles you painstakingly crafted in the user-agent is absent at the hardware level.
- A cheap VPS is now more noticeable. Two vCPUs mean the first tier, and the first tier on desktop Chrome under Windows is rarely seen among real users. Previously, a weak server was just slow; now it is also tagged.
- The signal is free for the site. Heavy checks like timing benchmarks are selectively included by sites because they take up user time. Reading the property costs nothing, so it will be added to the basic set even by those sites that previously limited themselves to IP reputation and headers.
- It will lie alongside Compute Pressure. Chrome's release notes explicitly suggest combining the new API with the Compute Pressure API — meaning the combination of "hardware class plus observed load" was originally intended as a standard scenario, and anti-bots won’t have to invent anything.
It is also worth reconsidering the assumption that it is enough to gather a "good" profile once and reuse it for years. Browsers add such properties without announcements to end users: weeks passed between the release of Chrome 152 and the first public analyses, during which profiles quietly delivered the new field, unaware. It makes sense to check the set of fields once per release cycle, not once a year.
What to Do Practically
- Capture the current values. In the profile console:
navigator.cpuPerformance,navigator.hardwareConcurrency,navigator.deviceMemory, and the WebGL renderer string. Record them as a quartet, not one field at a time — you will be checked precisely by the combination. - Match the tier with the profile legend. Mobile legend — first to third tier, budget laptop — second to third, flagship desktop — fourth. Tier 4 posing as an old Android or tier 1 posing as a MacBook on the M-series are equally suspicious.
- Do not modify the property directly. Spoofing via
Object.definePropertygets caught by traces of overriding the getter and discrepancies with the actual execution speed. If you do change it, do so at the browser build level or through built-in mechanisms. - Remember legal overrides. Chrome gives the user a handle in settings (Performance → Speed → Override CPU performance tier), and administrators a corporate policy. It is useful to know from both sides: the value can be not only "real" but also set manually, and a mass identical override across a pool of profiles becomes a marker.
- Distribute profiles across different hardware. If all your profiles are on one server, they will have the same tier — regardless of what devices they portray. This is the case where a fleet of several machines with different configurations honestly solves the problem, while a patch does not.
For more details on a related signal of the same family — in the analysis of device memory fingerprinting, and for stealth browsers that work with such properties out of the box, there is a benchmark for nodriver, Camoufox, and Patchright.
Where Proxies Fit In
To be clear: proxies do not fix browser fingerprinting. cpuPerformance is calculated on the client side, and no IP will change that. However, anti-bots make decisions based on the sum of layers, and it is usually at the intersection of layers that failures occur.
A typical chain by which cheap setups fail looks like this: IP from a known hosting network, first tier of the processor, headless signs in JS — three independent signals, each of which is tolerable individually, but together they add up to a clear verdict. Removing the network layer from this sum is cheaper and more reliable than battling browser fields: with a residential IP, the request looks like traffic from a regular home provider, and the "data center" hypothesis falls away for the detector. For mobile legends, the logic is the same — a mobile proxy should support the mobile profile; otherwise, the contradiction simply shifts from the processor to the network.
In Brief
Chrome 152 added not so much a new fingerprint as a new row in the cross-check table. Just over two bits by themselves do not give anyone away — it is the inconsistency that does: the declared device must match the class of processor, memory size, graphics card, execution speed, and the network from which the request came. This week, profile auditing should start with a single line in the console and the question, "does such hardware even exist for whom we are pretending to be?".