Intent to Ship: CPU Performance API
Chromestatus
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1364)
WebKit: Oppose (https://github.com/WebKit/standards-positions/issues/622)
Web developers: Positive
Other signals: Adobe: https://github.com/WICG/cpu-performance/issues/6 Figma: https://github.com/WICG/proposals/issues/253#issuecomment-3719833708
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None.https://wpt.fyi/results/cpu-performance?label=experimental&label=master&aligned
Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?
None.| Shipping on desktop | 151 |
| Origin trial desktop first | 146 |
| Origin trial desktop last | 151 |
| Shipping on Android | 151 |
| Origin trial Android first | 146 |
| Origin trial Android last | 151 |
| Shipping on WebView | 151 |
| Origin trial WebView first | 146 |
| Origin trial WebView last | 151 |
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
No such open issues.Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69aaa531.2b0a0220.c2d7.063a.GAE%40google.com
Alex Russell
Nikos Papaspyrou
Hi Alex,
Thank you for your comments and questions. We have discussed the API publicly since last October, when we circulated the explainer, and then followed with a presentation to the Web Performance WG at TPAC 2025. I’m not sure if somebody from Intel was present there. We have not discussed it with the authors of the Compute Pressure API proposal, in particular, although the two proposals are definitely related. I will try to explain their similarities and differences, as I see them.
The Compute Pressure API is dynamic; it “provides a way for websites to react to changes in the CPU pressure of the target device, such that websites can trade off resources for an improved user experience”. On the other hand, the CPU Performance API is static; it “exposes some information about how powerful the user device is. It targets web applications that will use this static information to provide an improved user experience”.
Both aspects of performance are useful and the two APIs are complementary, not antagonistic. I will not repeat the arguments in favour of dynamic information, as they are well known and documented in the Compute Pressure API. The argument in favour of static information is that we wanted the CPU Performance API to be a proxy for the user’s device hardware class — this means, it should be stable and unmoved by transient conditions, like what other applications are running, battery power, etc. If somebody has a powerful device where, at the moment, a lot of applications are running, we don’t want it to appear as a low-tier device to web applications. We want a new application to be able to realize that it is running on a high-tier device; if necessary, it will also have the chance to use dynamic information (the complementary API) to realize that the device is heavily used.
Obtaining dynamic information is something that a web application is generally able to do on its own, by running some JS benchmark. On the other hand, there’s no reliable way for a web application to obtain static information about the user device, that is, by overlooking what else is running. This is what the CPU Performance API is about. Partners have asked us for static information and this API solves the immediate use case; they have not asked for dynamic information, which is more-or-less covered by the Compute Pressure API. In this sense, the CPU Performance API is similar to `navigator.hardwareConcurrency`, which only exposes the possible level of concurrency regardless of how powerful each individual core may be.
The code example contained in the explainer and the proposed specification illustrates exactly this use case: a web application using the performance tier for pre-setting some features controlling user experience. Later on, such a web application may use the Compute Pressure API independently, to adjust these settings according to dynamic information.
Best regards,
Nikos.
Nikolaos Papaspyrou
Software Engineer
Google Germany GmbH
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.
This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.
