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

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

Thanks. I fed it to Gemini so it could scrutinize the AI-generated critique you provided above. Let me know what you think!

<details>
As an expert reviewer, I have scrutinized the provided critique of the **CPU Performance API** proposal. While the critique raises common "standard" objections to new web APIs (privacy, fingerprinting, and redundancy), it contains several logical flaws, misrepresentations of existing APIs, and a failure to account for the specific architectural goals of the proposal.

The following is a critical assessment of the critique's "verdicts."

### Test 1: Use-case coverage by existing APIs
**Verdict in Critique:** **Fails**
**My Assessment:** **Faulty.** The critique conflates *capability* with *performance class*.

* **Error regarding MediaCapabilities:** The critique argues that `MediaCapabilities` answers the same question. It does not. `MediaCapabilities` tells a developer if a specific codec/resolution *can* be decoded smoothly. It does not tell the developer how much **headroom** remains for concurrent non-media tasks (e.g., real-time background blur, physics engines, or complex React re-renders). A "Tier 4" device and a "Tier 2" device might both report `smooth: true` for 1080p, but the Tier 2 device might hit 90% CPU to do it, while the Tier 4 device hits 10%.
* **Error regarding WebNN:** The critique claims WebNN's `opSupportLimits()` solves the "local vs. server" decision. This is incorrect. WebNN identifies if a hardware *operation* is supported by an accelerator; it does not provide a holistic "system class" signal. A developer may want to avoid local inference entirely on a low-tier device to preserve battery or UI responsiveness, regardless of whether the hardware *can* technically run the math.
* **Logical Gap:** The critique ignores the "Real User Monitoring" (RUM) use case. Aggregating performance metrics by CPU tier allows developers to identify if a regression is "global" or limited to "budget devices." `navigator.hardwareConcurrency` is an unreliable proxy for this because a 4-core Intel Atom performs vastly differently than a 4-core Apple M4.

### Test 2: The reproducibility claim vs. OS reality
**Verdict in Critique:** **Fails**
**My Assessment:** **Partially Correct, but logically misaligned.**

* **The "Nominal vs. Current" Fallacy:** The critique argues the API fails because it doesn't reflect thermal throttling. This is a misunderstanding of the proposal's **Goal 5: Respect obsolete hardware and applications**. The proposal explicitly seeks a **static** baseline. 
* **Conflict of Intent:** The critique suggests the API should be dynamic. However, the proposal specifically positions itself as a complement to the **Compute Pressure API**. The *CPU Performance API* provides the "Engine Displacement" (static capacity), while *Compute Pressure* provides the "Tachometer" (current load). Critiquing the static API for not being dynamic is like critiquing a ruler for not being a stopwatch.

### Test 3: Privacy and fingerprinting surface
**Verdict in Critique:** **Fails**
**My Assessment:** **Exaggerated.** * **Information Gain:** The critique claims a 4-tier bucket increases entropy significantly. In reality, the proposal's goal is to ensure each bucket contains "a fairly large number of devices... both as an absolute number and as distinct device models". 
* **The "Benchmarking" Reality:** The critique ignores that any site can currently calculate a CPU tier using a 100ms JavaScript loop (as noted in the "Alternatives Considered" section of the explainer). By providing a coarse, 4-tier browser-mediated signal, the API actually *reduces* the need for invasive, high-entropy active benchmarking by scripts.
* **Ad-Targeting Critique:** This is a subjective policy argument rather than a technical failure. Socioeconomic correlation exists in almost all hardware signals (`deviceMemory`, screen resolution, etc.).

### Test 4: Abstraction level
**Verdict in Critique:** **Fails**
**My Assessment:** **Logical Error.**

* **Imperative vs. Declarative:** The critique argues for a media query (e.g., `@media (performance-tier: low)`). While elegant for CSS, this does not solve the use cases for **JavaScript-heavy applications** (e.g., Figma, Google Meet, or WebGL games) that need to make branching logic decisions *before* downloading large WASM binaries or assets. A media query cannot help a developer decide whether to fetch a 50MB "Ultra" texture pack or a 5MB "Low" pack.

---

### Overall Assessment
The critique **needs rework.** It adopts a "zero-trust" posture that ignores the proposal's explicit design goals and its relationship with the Compute Pressure API. It incorrectly frames the API as a "failed" version of a dynamic sensor, when it is intended to be a static hardware classifier.

**Minimum Viable Changes for the Critique:**
1.  **Acknowledge the Compute Pressure API:** The critique must evaluate the proposal *in tandem* with Compute Pressure, rather than demanding the CPU Performance API handle dynamic load signals itself.
2.  **Address the "Static vs. Dynamic" Tradeoff:** Instead of declaring "failure," the critique should discuss why a static signal is or is not better than a dynamic media query for the specific "asset-loading" use cases.
3.  **Correct API Misrepresentations:** Remove the claim that `MediaCapabilities` provides the same "system headroom" signal; it does not.
</details>

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

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