A new way to ask how fast a device is
Chrome 152, which entered beta on July 30, 2026, and reaches stable release on August 25, adds a small but consequential capability to the web platform: a new CPU Performance application programming interface (API), read through a navigator.cpuPerformance property, that lets a website ask, in one read-only call, roughly how powerful the visitor's central processing unit (CPU) is. The value is an integer from 1, weak, to 4, fast, with 0 reserved for devices Chrome cannot classify.
The feature is defined in a proposal from the Web Incubator Community Group (WICG), authored by Google Chrome engineer Nikolaos Papaspyrou. Its stated goal is to give sites, particularly video conferencing tools and browser games, a way to make performance-dependent decisions, such as dropping heavy animations or serving a lighter video stream, without resorting to benchmarking the device themselves or relying on other, more fingerprinting-prone signals.
Using it is a single property read, guarded by a feature check for browsers that have not shipped it yet:
if ('cpuPerformance' in navigator) {
const tier = navigator.cpuPerformance; // 0 (unknown) to 4 (fast)
if (tier > 0 && tier <= 2) {
// Weaker device: reduce animation complexity, lower video resolution, etc.
enableLiteMode();
}
} else {
// Fallback for browsers without the API
enableLiteMode();
}
The explainer also suggests pairing the API with the existing Compute Pressure API, which reports real-time CPU load, so a site can combine a one-time capability read at page load with ongoing pressure signals while the page is open, rather than relying on either alone.
Built to resist fingerprinting, and to age well
Two design choices in the explainer are aimed squarely at privacy risk. First, each tier has to cover "a fairly large number of devices," both in raw count and in distinct device models, so that knowing a visitor's tier does not narrow them down to a small, identifiable group the way a precise benchmark score might. Second, the specification commits to never redefining what an existing tier means as hardware improves: a device rated tier 3 today should still be rated tier 3 years from now, with faster future hardware earning new tiers, 5, 6, and beyond, rather than the scale being recalibrated underneath existing devices. The API only works in secure, HTTP Secure (HTTPS) contexts, and Chrome Enterprise administrators and end users can override the reported tier through a CpuPerformanceTierOverride policy.
The CPU Performance API is one part of a broader Chrome 152 release. Other additions include a window-drag Cascading Style Sheets (CSS) property that replaces the older app-region for marking draggable regions in desktop web apps, relative alpha color adjustments through the CSS Color 5 alpha() function, new media element pseudo-classes such as :playing, :paused, and :buffering, an autocorrect Hypertext Markup Language (HTML) attribute for controlling autocorrection on form fields, and Connection Allowlists, which let a site restrict which endpoints its own fetch and web API calls are permitted to reach.
The last release on the old schedule
Chrome 152's stable launch on August 25 also marks the end of an era for Chrome's release process: it is the final version shipped on the browser's long-standing four-week release cycle. Starting with Chrome 153 on September 8, Chrome moves to a two-week cadence, with 154 following on September 22 and 155 on October 6.
That timing puts Chrome roughly in step with Firefox, which separately announced its own move to a two-week release cycle starting in September 2026, a shift this site covered previously. Faster release cycles mean new web platform features, and bug fixes, reach users sooner, but they also mean web developers testing against "current Chrome" or "current Firefox" will need to track version changes more often than the roughly monthly cadence both browsers kept for years.
What it means for developers
If you build anything that adapts to device capability, video calling, in-browser games, or media-heavy sites, navigator.cpuPerformance is worth testing once Chrome 152 reaches stable on August 25: it is a cheaper and more privacy-conscious signal than running your own benchmark, though because it only reports four coarse tiers rather than a precise score, it works best combined with existing responsive techniques rather than replacing them outright. Teams that maintain browser support matrices or automated compatibility testing should also plan for both Chrome and Firefox shipping changes roughly twice as often from September onward, since a testing cadence built around monthly browser releases will start falling behind.
