I saw there were some open comments/questions on the TAG review thread https://github.com/w3ctag/design-reviews/issues/1198 -- it would be great if you could respond there so that review might reach some conclusion.
-- Dan On Tuesday, June 9, 2026 at 11:31:30 AM UTC-7 Nikos Papaspyrou wrote: > 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. > > > On Mon, Jun 8, 2026 at 9:00 PM Alex Russell <[email protected]> wrote: > >> Hey Nikolaos, >> >> Exciting to see more information in this space coming through, as we've >> heard developers asking for similar data. Have you discussed the API shape >> with our friends at Intel? The Compute Pressure work is motivated by >> similar issues, and it would be helpful to at least see a sketch in the >> considered alternatives section of adding this information to either the >> existing `navigator.hardwareConcurrency` interface or Compute Pressure. At >> a minimum, I'd expect to see code samples that outline how they would be >> used together, given that the Explainer discusses it. The Explainer also >> doesn't outline the sorts of code folks have to write today to understand >> how to effectively understand the situation, which makes it hard for >> reviewers (e.g., the TAG) to understand if this is solving an important >> problem well. >> >> Best, >> >> Alex >> >> On Monday, June 8, 2026 at 7:14:38 AM UTC-7 Chromestatus wrote: >> >>> *Contact emails* >>> [email protected] >>> >>> *Explainer* >>> https://github.com/WICG/cpu-performance >>> >>> *Specification* >>> https://wicg.github.io/cpu-performance >>> >>> *Summary* >>> Expose some information about how powerful the user device is. This API >>> targets web applications that will use this information to provide an >>> improved user experience, possibly in combination with the Compute Pressure >>> API, which provides information about the user device’s CPU >>> pressure/utilization and allows applications to react to changes in CPU >>> pressure. >>> >>> *Blink component* >>> Blink>PerformanceAPIs >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPerformanceAPIs%22> >>> >>> *Web Feature ID* >>> Missing feature >>> >>> *Motivation* >>> At present, some video conferencing applications support advanced >>> functionality by relying on internal/private browser extensions or APIs to >>> classify devices into performance categories. Our proposal allows these >>> applications to support existing functionality without depending on such >>> non-standard features. Applications whose functionality depends on >>> client-side hardware detection often resort to running benchmark workloads, >>> to estimate hardware capabilities. Providing a public CPU Performance API >>> would help prevent a needless waste of resources. >>> >>> *Initial public proposal* >>> https://github.com/WICG/proposals/issues/253 >>> >>> *TAG review* >>> https://github.com/w3ctag/design-reviews/issues/1198 The specification >>> is ready for review, so the above is not an "early design" review. >>> >>> *TAG review status* >>> Pending >>> >>> *Origin Trial Name* >>> CPU Performance API >>> >>> *Goals for experimentation* >>> This API provides device-specific information about CPU performance >>> while preserving user privacy. We'd like to see if this information is >>> useful in providing the user experience improvement for the kind of >>> applications that this API targets and if its shape matches developer >>> expectations. We will measure API usage metrics and obtain developer >>> feedback to validate our designs. >>> >>> *Chromium Trial Name* >>> CpuPerformance >>> >>> *Origin Trial documentation link* >>> https://github.com/WICG/cpu-performance >>> >>> *WebFeature UseCounter name* >>> kNavigatorCPUPerformance >>> >>> *Risks* >>> >>> >>> *Interoperability and Compatibility* >>> None. >>> >>> *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 >>> >>> *WebView application risks* >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> None. >>> >>> >>> *Debuggability* >>> Nothing interesting, debuggability review completed. >>> >>> *Will this feature be supported on all six Blink platforms (Windows, >>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>> Yes >>> >>> *Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>> Yes >>> >>> https://wpt.fyi/results/cpu-performance?label=experimental&label=master&aligned >>> >>> *Flag name on about://flags* >>> *No information provided* >>> >>> *Finch feature name* >>> CpuPerformance >>> >>> *Rollout plan* >>> Will ship enabled for all users >>> >>> *Requires code in //chrome?* >>> True >>> >>> *Tracking bug* >>> https://issues.chromium.org/449760252 >>> >>> *Measurement* >>> >>> https://uma.googleplex.com/p/chrome/timeline_v2/?sid=eb11c4b156c799e994576301d01ff0b5 >>> >>> *Availability expectation* >>> Feature is available only in Chromium browsers. It is not clear if/when >>> other browsers will follow. >>> >>> *Adoption expectation* >>> Feature is used by specific partner(s) to provide functionality as of >>> the launch in Chrome. At least one major abstraction will replace their use >>> of an existing feature with this feature as of the launch. >>> >>> *Adoption plan* >>> We are already working with specific partner(s) who will benefit from >>> this feature. >>> >>> *Non-OSS dependencies* >>> >>> Does the feature depend on any code or APIs outside the Chromium open >>> source repository and its open-source dependencies to function? >>> None. >>> >>> *Estimated milestones* >>> 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 >>> >>> *Anticipated spec changes* >>> >>> 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. >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5189864286978048?gate=5090091072618496 >>> >>> *Links to previous Intent discussions* >>> Intent to Prototype: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMHN%3DHydj6Q7pz6i_y3j1ON20a270NFGx%2BKD11Q3VdfTXvtCDg%40mail.gmail.com >>> Intent to Experiment: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69aaa531.2b0a0220.c2d7.063a.GAE%40google.com >>> >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com>. >>> >> > > Nikolaos Papaspyrou > > Software Engineer > > [email protected] > > > Google Germany GmbH > Erika-Mann-Straße 33 80636 München > > > 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. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/211f51e5-443e-478e-9b35-bb45616ec46bn%40chromium.org.
