Intent to Prototype: CPU Performance API

247 views
Skip to first unread message

Nikos Papaspyrou

unread,
Oct 8, 2025, 9:38:50 AMOct 8
to blin...@chromium.org, Michael Lippautz, Dominic Farolino
Contact emails
niko...@chromium.org

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

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?
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.

--
Nikos Papaspyrou <niko...@google.com>

Jeffrey Yasskin

unread,
Oct 8, 2025, 10:08:38 AMOct 8
to Nikos Papaspyrou, blink-dev, Michael Lippautz, Dominic Farolino


On Wed, Oct 8, 2025, 6:38 AM 'Nikos Papaspyrou' via blink-dev <blin...@chromium.org> wrote:
Contact emails
niko...@chromium.org

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

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


From a TAG perspective, it will probably avoid a round trip if you can present this to the Privacy WG before sending the TAG review. 

Thanks, 
Jeffrey

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMHN%3DHydj6Q7pz6i_y3j1ON20a270NFGx%2BKD11Q3VdfTXvtCDg%40mail.gmail.com.

Rick Byers

unread,
Oct 8, 2025, 3:30:14 PMOct 8
to Nikos Papaspyrou, blin...@chromium.org, Michael Lippautz, Dominic Farolino
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 for my questions / thoughts.

Thanks,
   Rick

--

Josh Comeau

unread,
Dec 9, 2025, 1:36:17 PM (9 days ago) Dec 9
to blink-dev, Rick Byers, blin...@chromium.org, Michael Lippautz, Dominic Farolino, Nikos Papaspyrou
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, 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

Vincent Scheib

unread,
Dec 11, 2025, 2:18:02 PM (7 days ago) Dec 11
to Josh Comeau, blink-dev, Rick Byers, Michael Lippautz, Dominic Farolino, Nikos Papaspyrou, DeviceDev
Reply all
Reply to author
Forward
0 new messages