Hey y’all - just wanted to add my thoughts that I think this API would add a lot of value! I read through the explainer and I think it makes a lot of sense. 👍
I’m the developer Rick mentioned in the previous message; specifically, a lot of the animations I like to create involve particle effects, and I don’t really feel like I have a *great* way to figure out how many particles a particular device could support before the framerate drops. What I often wind up doing is figuring out how many particles can run smoothly on my older budget Android smartphone and picking that number for everyone. So, I might wind up with 30 particles, when most devices could comfortably handle 100+. I know that I *could* solve this problem using a micro-benchmarking approach, as discussed in the explainer <https://github.com/explainers-by-googlers/cpu-performance?tab=readme-ov-file#accessibility-privacy-and-security-considerations>, but it's not really a road I want to go down; it feels too sneaky, and a bit wasteful of the user’s device’s resources. I also teach animations, and wouldn’t really feel comfortable teaching the existing micro-benchmarking approach, but would happily share how to use the CPU Performance API. Thanks, —Josh On Wednesday, October 8, 2025 at 3:30:14 PM UTC-4 Rick Byers wrote: > I'm excited to see this work proceed! We've talked for many years about > having a coarse performance tier bucket for devices and personally I think > it's long overdue and we should be bold in launching something despite the > inevitable debate. > > I was just talking with a web developer a couple weeks ago who was > lamenting having to provide a lowest-common-denominator user experience > because they had no way to reliably progressively enhance their UI on more > capable devices. I suggested Device Memory hints as a likely useful proxy, > but I don't actually have any good data on the extent to which device > memory correlates with device performance (I'm sure it does but also that > it's imperfect), do you? I filed a couple issues > <https://github.com/explainers-by-googlers/cpu-performance/issues?q=is%3Aissue%20state%3Aopen%20author%3Arbyers> > > for my questions / thoughts. > > Thanks, > Rick > > On Wed, Oct 8, 2025 at 9:38 AM 'Nikos Papaspyrou' via blink-dev < > [email protected]> wrote: > >> *Contact emails* >> [email protected] >> >> *Explainer* >> https://github.com/explainers-by-googlers/cpu-performance >> >> *Specification* >> None >> >> *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/explainers-by-googlers/cpu-performance >> >> *TAG review* >> None >> >> *TAG review status* >> Pending >> >> *Risks* >> >> >> *Interoperability and Compatibility* >> None >> >> *Gecko*: No signal >> >> *WebKit*: No signal >> >> *Web developers*: No signals >> >> *Other signals*: >> >> *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* >> None >> >> *Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> Yes. However, testing this feature will inevitably be limited. Tests >> cannot assert that a particular hardware combination will yield a >> particular integer value, and are restricted to non-undefined-ness and >> non-zero-ness. >> >> >> *Requires code in //chrome?* >> True >> >> *Tracking bug* >> https://issues.chromium.org/449760252 >> >> *Estimated milestones* >> >> Intent to ship roughly by the end of 2025, in M145. >> >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/5189864286978048?gate=5145253552193536 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> Nikos Papaspyrou <[email protected]> >> >> -- >> > 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%3DHydj6Q7pz6i_y3j1ON20a270NFGx%2BKD11Q3VdfTXvtCDg%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMHN%3DHydj6Q7pz6i_y3j1ON20a270NFGx%2BKD11Q3VdfTXvtCDg%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/f05b6a41-f8e8-47cd-b72c-7714d8bef75dn%40chromium.org.
