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.
