v152 · 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. Quality Tier Selector

    The canonical use case from the WICG explainer: a video call tile that scales resolution, virtual backgrounds, noise reduction, and face retouch to the CPU tier. Plus an "AI inference: local or server?" router that flips at tier 3+.

  3. Adaptive Animation

    Reads the CPU tier and picks an animation complexity preset — static on tier 0, opacity pulse on tier 1, translation on tier 2, orbital on tier 3, full particle system on tier 4+. Simulate each tier with the in-page buttons.

  4. Adaptive Image Decoding

    Tier 0 devices choke on a feed of AVIF / JPEG-XL decodes. Reads the tier, picks the codec that fits the 500ms decode budget for a 30-image feed, and emits the right <picture> tree — with a graceful WebP / JPEG fallback for the lower end.

  5. Tier Distribution Simulator

    Before adopting tier-gated code paths, model the population from a checked-in RUM export. Pick an aggregate audience segment, fine-tune the histogram, and see how much of your audience lands on each path — then read the heuristic for "ship heavy by default" vs "gate behind a toggle".

  6. Server Adaptation Echo

    Combine a coarse CPU tier with a concrete app scenario, fetch a live echo route, and inspect the selected server profile through JSON and Server-Timing. Shows how device adaptation can cross the client/server boundary without leaking model-specific details.

  7. Worker Pool Calibrator

    Reads your CPU tier and hardwareConcurrency, then runs a real parallel workload across 1–N worker threads to find where throughput peaks. Produces a tier-aware pool-size recommendation with copyable code that adapts to the device class — high-tier devices get more threads; entry-level devices stay within thermal headroom.

  8. API Safety Harness

    12 edge-case tests: API availability, return type, value range, stability across repeated calls, hardwareConcurrency and deviceMemory companions, prefers-reduced-motion integration, graceful fallback estimation, tier-gated feature flags, secure context requirement, and Compute Pressure API pairing. All run in-page with no server required.

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