v146 · capabilities · performance

CPU Performance API

A way for web apps to ask "how powerful is this device?" — a coarse hint that lets them pick between a heavyweight and a lightweight code path without trying to fingerprint the CPU. Designed to pair with the Compute Pressure API for dynamic adaptation.

concepts

  1. Device Tier Readout

    Reads the CPU Performance API and pairs it with hardwareConcurrency, deviceMemory, and a quick synthetic benchmark. Useful for picking a quality preset on first load.

  2. Video Conference Tier Adapter

    The canonical WICG motivating use case: a conferencing UI picks resolution, framerate, simulcast layers, blur and noise suppression from the device tier — no proprietary benchmarks, no fingerprinting.

  3. Tier policy router

    A live policy table mapping the CPU tier onto product feature flags — particle budget, ML preload, shadow quality, telemetry cadence. Switch the tier and watch the dispatched config recompute.

  4. Game quality preset

    A canvas mini-game bound to a low/mid/high preset derived from the tier. Particles, shadows, post-FX and entity budget all change; FPS counter shows the actual cost.

  5. Compute Pressure Pairing

    CPU tier is static (hardware capability); Compute Pressure state is live (current load). A live dashboard shows both signals together, a decision matrix maps tier × pressure to quality settings, and a PressureObserver demo automatically steps quality when the CPU is saturated.

  6. Adaptive Resource Loader

    A resource manifest table showing which modules get loaded eagerly, deferred, or skipped entirely at each CPU tier. Simulate a page load for any tier and watch the load sequence play out — with a summary of bytes saved vs a high-tier baseline.

why it shipped

Web apps want to ship one bundle that adapts to the device. On a beefy laptop you can fire up heavy 3D physics; on an entry-level phone you want a simpler render path. The existing knobs — navigator.hardwareConcurrency, navigator.deviceMemory — are too coarse and too easy to misread (24-core SoCs and 2-core e-cores both report numeric values that don't reflect real performance). A dedicated CPU Performance signal gives Chrome a chance to expose a calibrated tier that the platform can derive however makes sense per-device, without leaking model-specific fingerprints.

references