Alex, In my experience speaking with developers, the issue is that even with logic to make a dynamic judgement (by using the Compute Pressure API or other feedback such as dropped frames) the site still needs to decide what to load first. Consider a developer looking to run an ML model on-device: They may have 3 different models requiring progressively higher compute capabilities but offering similar improvements in quality. Since each model takes time to load, ideally you would load the correct one first most of the time. This API can help with that. It's still just an assumption so other dynamic signals are still necessary.
Nikos, if this matches your experience can you add something like my explanation above to the explainer? Reilly Grant | Software Engineer | [email protected] | Google Chrome <https://www.google.com/chrome> On Wed, Jun 17, 2026 at 8:13 AM Alex Russell <[email protected]> wrote: > Thanks for all of this, Nikos. > > Look at the Explainer again, I'm not sure how this would be use in > conjunction with (or in opposition to) Compute Pressure. Can you show in > code there how they compose or compete? What use-cases benefit from the > static judgement more than the dynamic one? > > Best, > > Alex > > On Wednesday, June 10, 2026 at 8:28:38 AM UTC-7 [email protected] > wrote: > >> 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/4aafe1d7-6404-4b47-adc4-41a556ef95f5n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4aafe1d7-6404-4b47-adc4-41a556ef95f5n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAEmk%3DMbSEy3LtA0VbGPJSJkyhNvg0eZkBHe6uB-HbcrNandC%2BA%40mail.gmail.com.
