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/CAMHN%3DHzo%2BHjgsvCai5%2BVv-iFjyb9WCZRPoh%2BvVhFcRKB%2BgRZeQ%40mail.gmail.com.

Reply via email to