Hey folks, Sorry for letting this drag on, but I'm still stuck on seeing some example code that shows how this might be used in anger. Are there developers who have tried this behind a flag that might be able to weight in? And is there any reason not to go to OT if we can't either show how this works in practice alongside compute pressure, or is used instead?
Best, Alex On Saturday, June 27, 2026 at 1:47:08 PM UTC-7 Sangwhan Moon wrote: > 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 > > On Jun 26, 2026, at 8:51, Rick Byers <[email protected]> wrote: > > > > > On Fri, Jun 26, 2026 at 9:16 AM Barry Pollard <[email protected]> > wrote: > >> 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 >> <https://www.smashingmagazine.com/2022/03/signals-customizing-website-user-experience/#device-capability-signals> >> *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? > > On Mon, 22 Jun 2026 at 16:02, Rick Byers <[email protected]> wrote: >> > 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 >>> <https://github.com/WICG/cpu-performance/issues/2>, I also built a JS >>> reference implementation derived from the Chromium impl and proposed >>> contributing it to the WICG >>> <https://github.com/WICG/cpu-performance/pull/12>, along with a little >>> demo page <https://rbyers.github.io/cpu-performance/demo.html>, and >>> possible >>> spec additions <https://github.com/WICG/cpu-performance/pull/13>. 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 >>> >>> On Mon, Jun 22, 2026 at 5:48 AM Thomas Steiner <[email protected]> wrote: >>> >> 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 <https://github.com/AlexsJones/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 >>>> >>>> On Sat, Jun 20, 2026 at 1:25 AM Rick Byers <[email protected]> wrote: >>>> >>>>> I am personally convinced of the use case's importance and Nikos's >>>>> responses to the TAG feedback. In addition to the linked Adobe >>>>> <https://github.com/WICG/cpu-performance/issues/6> and Figma >>>>> <https://github.com/WICG/proposals/issues/253#issuecomment-3719833708> >>>>> support, Josh Comeau's comments on the I2P >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/8y-EauEeWWE/m/ghE0ByYaCAAJ> >>>>> >>>>> 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 >>>>> <https://engineering.fb.com/2014/11/06/android/year-class-a-classification-system-for-android/>). >>>>> >>>>> 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 >>>>> <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/mycizSF0lnQ?e=48417069> >>>>> >>>>> 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 >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:content/browser/cpu_performance/cpu_performance.cc?q=cpu_performance.cc&ss=chromium> >>>>> >>>>> 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 Thu, Jun 18, 2026 at 12:03 PM Nikos Papaspyrou < >>>>> [email protected]> wrote: >>>>> >>>>>> 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. >>>>>> >>>>>> On Wed, Jun 17, 2026 at 8:59 PM Reilly Grant <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> 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? >>>>>>> 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? >>>>>>>> >>>>>>> >>>>>> 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. >>>>>> Until the PR is merged, you can read it here: >>>>>> https://github.com/WICG/cpu-performance/pull/10/changes >>>>>> 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 >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMHN%3DHy3Cqd%2BMX%3DB%3Dy7%2BWwafkiBFCB0zDXj4iRGKt0qmeWerRg%40mail.gmail.com?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/CAFUtAY8i6a1a-fz8S7%3DCHCSfU1gB%2B9ij1eU7y9gaKOjjqj%2BNxg%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8i6a1a-fz8S7%3DCHCSfU1gB%2B9ij1eU7y9gaKOjjqj%2BNxg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com, >>>> toot.cafe/@tomayac) >>>> >>>> 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 >>>> 0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181. >>>> ----- 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 >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY90H6SuPm0JokoOY%2BHBtVUkC3YBSzYK1bS9%3D7%2BVQk%3DtNQ%40mail.gmail.com?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/CAFUtAY-AWVyD5iR3HXSftNrx-HnZBy%2BJwbZb63NOpqnXELyUjA%40mail.gmail.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-AWVyD5iR3HXSftNrx-HnZBy%2BJwbZb63NOpqnXELyUjA%40mail.gmail.com?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/322ee3c5-b1de-47fe-84f7-e946d54f38een%40chromium.org.
