Re: [w3ctag/design-reviews] Incubation: CPU Performance API (Issue #1198)

nickie left a comment (w3ctag/design-reviews#1198)

> Reopening for clarification on the following:
> 
> 1. Why a CPU measurement, not existing targeted APIs? The motivating use cases (video conferencing, ML model selection) depend on GPUs/NPUs, not CPU. Why not extend MediaCapabilities or WebCodecs isConfigSupported() instead? Have you talked to those WGs?

This API is about CPU performance, not GPU/NPU or anything else. It is not about codecs nor is it related to other special-purpose APIs. I think that all this is clearly stated in the explainer and the spec. Whether this API is useful for video conferencing or ML applications depends a lot on the particular application and how much CPU performance affects it. Communications with interested partners and the feedback that we have received (some linked above) suggest that it is useful and that is why we propose its adoption.

> 2. What do apps actually do with a static number? What's the concrete application behavior? Is it "download flexible code up front"? Where's the evidence that's how apps will use it, and that it's better for users than adapting dynamically?

While both static and dynamic information are useful, the CPU Performance API is designed to be a proxy for the user’s device hardware class. That is, a powerful device shouldn't be exposed as a low-tier one just because other heavy applications are running, or the battery is low. This stability is important so that when an app has to make up-front decisions that depend on the user's hardware, it can be right most of the time. This includes "download flexible code up front" as you mentioned, and other concrete use cases in the explainer below.

> In particular, web applications may want to use performance information to:
> 1. Control non-essential tasks and requests; e.g., allow or block 3rd party scripts, use or avoid heavy libraries.
> 2. Adjust the complexity of web content; e.g., the resolution and format for images and video, the compression level for uploading data, enable or disable computationally heavy operations such as animations, improve resource management (lazy loading, prefetching, prerendering).
> 3. Improve real user monitoring; e.g., better understand if users have faster or slower devices, focus development effort more appropriately.
> 4. Run computations on the client side vs. on the server side; e.g., use server-side rendering, run AI applications and LLMs on the client side.
> 5. Select ads that are better suited for the user device.

If necessary, this application can also obtain dynamic information through a complementary API like [Compute Pressure](https://github.com/w3c/compute-pressure). But obtaining dynamic information is something that a web application is generally able to do on its own, while there’s no reliable way for a web application to obtain static information about the user device hardware class, so it can make better up-front decisions. In this way, the API solves the immediate use case of several interested partners.

Coming to the last point about ads, which as I can see in [Marcos's comment](https://github.com/w3ctag/design-reviews/issues/1198#issuecomment-4341573837) may have been misinterpreted as "better user tracking for ads", this was never the intention of this API and, as is obvious from the spec, we tried as hard as possible to limit the use of this API for fingerprinting.

Insofar as ads may contain videos or other computationally expensive material, then without knowledge of the device's performance tier, ads may try to provide the highest-performance experience, occasionally overwhelming the device's capabilities and providing a worse user experience. This API gives all vendors of content a chance at tailoring their experience to the device's capabilities.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1198#issuecomment-4742889631
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1198/4742889631@github.com>