| One small thing that came to mind is when there is CPU hotplug is involved (e.g. ChromeOS does this for battery saver).
It seems like as of today there isn't a way for apps to react when the core count changes by the system - has an event or watcher been considered? Sangwhan Moon
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?
I don't have code, but I see them as related but different.
IMHO the Compute Pressure API is about dealing with a system under stress and backing off non-critical work.
This CPU Performance API is about setting an initial baseline of what a system should be able to handle under normal conditions (i.e. don't default assumptions that a system is under-powered and default to the bare minimum and make the user perhaps miss out on providing optional, extra enhancements, but also don't assume it's overpowered and make users turn off features to get a useable experience).
Now it's true that the Compute Pressure API could be used for the same reasons as CPU Performance API. But that basically means ramping up until it hits a pressure point and then backing off. That's effectively just another form of micro-benchmarking and I think we all understand the downsides of that.
I also think this CPU Performance API is a simpler, and more developer egronomic API than computer pressure, along the lines of Network Information API and Device Memory API where sites can use these signals to customize the experience upfront (for example providing a more stripped down experience for lower-powered devices). The Compute Pressure API is more about reacting to continual signals in a real-time fashion, so I'd see it as a more advanced use case for real time systems (video conferencing, video games). I don't think you want to remove features already loaded due to Compute Pressure (for example, you wouldn't switch already-loaded hi-res images to lower resolution images based on CPU pressure), just lower/pause continually processing processes like video or background calculations.
Would sites use both? Maybe. But as I say, I think the Compute Pressure API is a more advanced API.
Thanks Bary, this was exactly my thinking too - depending on your use case you'd want either static (eg. UX that is jarring to change) or dynamic (more advanced, good for anything that really needs to adapt over time). I still think we COULD show an example of a dynamic system which bootstrapped itself using the static value, but I'm not personally aware of any developer who wants to do that, so it might be entirely artificial. For problems where the UX is amenable to a dynamic system, wouldn't I want to just always go for the max utilization and back off under pressure, rather than try to set some artificial ceiling?
Nikos, WDYT? Can you ask any of your known OT users for this API whether they are using it in conjunction with dynamic signals, or whether they have features effectively split into those which are dynamic vs. those that are static? For example, the explainer talks about setting initial video resolution, frame rate and features for a video chat app. Features seems clearly static to me (don't want background blur turning off and on based on CPU load). But what about framerate and video resolution? Would these generally only be changed by user action (manually choosing a higher resolution), by other dynamic signals (like dropped frames), or also by CPU pressure?
Thanks everyone for the input and offer of support! Note that Nikos is OOO this week so we should not expect responses from him until next week. I believe the team will likely postpone this feature to M152 to ensure there's adequate time to engage with this debate and make any necessary adjustments. But note the OT ends in 151 so IMHO we should not let this slip past M152 without a very good reason.
Regarding the interoperability concern, I also built a JS reference implementation derived from the Chromium impl and proposed contributing it to the WICG, along with a little demo page, and possible spec additions. I suggest we give the standards debate a couple weeks to play out in the WICG repo + TAG thread. Then, depending on the outcome, API owners can evaluate whether to ask the team to move their implementation into an independent open source repo. IMHO if the spec ends up reasonably precisely defining the algorithm, there's no reason to request any changes in Chromium's implementation strategy.
Rick
I know that the Web AI community are very interested in finding out if a given device can run an AI model. In the native world, there are tools like llmfit. I recently compared what they can obtain with what is available via Web APIs.
llmfit:
<Screenshot 2026-06-12 at 12.31.54.png>
Web APIs:
<Screenshot 2026-06-12 at 12.35.17.png>
- Hardware concurrency shows 14 cores, paired with other info like OS, you can pretty accurately tell the CPU.
- Device memory shows a capped value of 32 GB, but I actually have 48, and it doesn't give you the currently free RAM.
- GPU adapter info seems on par, and I think there could be some info you could deduce about available RAM by looking in the max buffer size and additional out-of-bounds knowledge based on the vendor.
Happy to put you in contact with the people at Hugging Face I'm talking to. They are interested in the API for sure.
Cheers, Tom
I am personally convinced of the use case's importance and Nikos's responses to the TAG feedback. In addition to the linked Adobe and Figma support, Josh Comeau's comments on the I2P are notable.
While it's quite dated now, this all aligns with my personal experience working on mobile GMail. We essentially had a database mapping heuristic signals (like precise device model strings in the UserAgent header) to higher level concepts of device capability (similar to what Facebook described around that time). Then, we'd serve our best guess of a bundle of html/js in the initial HTTP response based on these heuristics (with a selection of features enabled which we believed would work well for the user). When people argued that relying on such heuristics was "wrong", we would cringe at their lack of pragmatism and connection to the real-world tradeoffs involved in delivering a top-tier web app which refused to compromise on user experience. Of course that team eventually (very reluctantly) gave up on the web, deciding it was too hard to fight things like this relative to native mobile platforms where they faced no such headwinds.
This proposed API is a HUGE improvement for browser interoperability over the approach we used in GMail, since it was virtually impossible for a browser/device maker to tell what signal we were using on our server to determine the quality of experience we served them. I would expect such heuristics are still relied upon across sophisticated web apps. Developers of such sophisticated web apps have no reason to talk publicly about how they optimize user experience, since such heuristics are generally frowned upon yet also a competitive differentiator for the best of the web.
My only concern with this intent (especially after reflecting on my handling of the prompt API intent) is whether it meets our bar for establishing "plausible interoperability". If I were working on Firefox and wanted to ensure an Adobe or Figma web app got the same quality level of experience as Chrome thanks to this API, I'm pretty sure I would want to just copy the Chromium algorithm exactly rather than risk doing something different. If we expect that to happen, then I think the burden should be on us to make that easy, e.g. by either:
1) Moving our core algorithm into an open-source repo independent from Chromium, intended to be easy for other browser engines to consume and keep up-to-date, OR
2) Encoding the algorithm we're using directly into the spec (perhaps via a reference implementation as is done for other specs like WASM). Ensuring this stays in sync with Chromium could be a pain, but maybe some declarative data table could be used to drive the algorithm?
If all other engines oppose this capability in any form, it's probably not worth doing this work now for zero tangible benefit. Instead perhaps we should commit to taking one of the above paths should another implementation come along in the future and request it? WDYT?
Rick
On Wednesday, June 10, 2026 at 5:28:38 PM UTC+2 [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.
The comments and questions on the TAG review thread have now been answered.
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? 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?
Thank you Alex and Reilly! Reilly's explanation matches indeed the feedback from our partners. I added a paragraph to the "Motivating use cases" section in the explainer, to make this more prominent. I hope that this addresses both Alex's comments and similar comments on the TAG review thread.
Best regards,
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%3DHy3Cqd%2BMX%3DB%3Dy7%2BWwafkiBFCB0zDXj4iRGKt0qmeWerRg%40mail.gmail.com.
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/CAFUtAY8i6a1a-fz8S7%3DCHCSfU1gB%2B9ij1eU7y9gaKOjjqj%2BNxg%40mail.gmail.com.
--
Google Spain, S.L.U. Torre Picasso, Pl. Pablo Ruiz Picasso, 1, Tetuán, 28020 Madrid, Spain
CIF: B63272603 Inscrita en el Registro Mercantil de Madrid, sección 8, Hoja M-435397 Tomo 24227 Folio 25
----- BEGIN PGP SIGNATURE ----- Version: GnuPG v2.4.8 (GNU/Linux)
iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck ----- END PGP SIGNATURE -----
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/igPwzkxhQtk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [email protected].
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY90H6SuPm0JokoOY%2BHBtVUkC3YBSzYK1bS9%3D7%2BVQk%3DtNQ%40mail.gmail.com.
--
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/CAFUtAY-AWVyD5iR3HXSftNrx-HnZBy%2BJwbZb63NOpqnXELyUjA%40mail.gmail.com.
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/03CA62A6-1602-402B-B1CC-BC8ECDF80685%40chromium.org.
|
