In my corporate work, we have implemented device tiering multiple times over the years, using whatever signals were available at the time: core count, device memory, battery state, connection type, screen size, OS version, and sometimes user-agent-derived platform hints. The goal was always practical: reduce battery usage, pick a reasonable initial bundle/model/feature set, and avoid starting users on an experience that we then immediately have to degrade, or that fails along the journey. Having this proposed API would have helped a lot.
Personally, I am not concerned about the privacy aspect of this API at the proposed granularity. The alternative in practice is often worse. On the interoperability point, I started a small Rust port of the Chromium classification algorithm here: https://github.com/hjanuschka/cpu-performance-tier Please consider this only a PoC. If this direction is useful, moving it under a neutral namespace would be mandatory. My hope is that having the algorithm live in an independent, reviewable repo can help with credibility, make it easier for other engines to reuse the exact same logic, and build user and market trust through an open-source approach. The PoC is independent of Chromium internals, includes the Chromium test vectors, and has an optional dependency-free host-info helper feature (to fetch core count and brandname). I can help with a Chromium migration to such a shared crate if that direction is useful. If positions from other engines ever change, I can also help pursue integration CLs there. If Rust is not practical for a given engine, we could provide a C++ version as well. Even if other engine positions stay negative/opposed for a while, I think option 1 would still provide a solid foundation for a possible future change in those engines. I am not expecting anything here; I just wanted to raise my hand and say I would like to help turn option 1 into something real if that becomes useful. cheers, helmut [email protected] schrieb am Samstag, 20. Juni 2026 um 01:25:15 UTC+2: > 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/8b690961-f316-443c-9985-b1add67f3010n%40chromium.org.
