JavaScript Compute Pressure Table

The states quantify whole-system CPU pressure, and each maps to a different class of action. Nominal: the machine is comfortable - run full quality, schedule background work freely (this is also the state to catch up on deferred analytics or sync). Fair: noticeable utilization, headroom exists - hold quality, stop ADDING background load, and let thresholds guide you if you defined custom bands. Serious: the system is struggling - shed optional compute: drop video to the next-lower rendition, halve particle counts, pause prefetch and speculation (prerender/speculation-rules are exactly the kind of work to cancel here). Critical: the machine is drowning - stop discretionary work outright: pause non-visible video processing, kill all non-essential timers and observers, show the user nothing but the core experience. Two design notes that separate good implementations: the ladder must be monotonic and sticky (quality returns more slowly than it drops - hysteresis prevents oscillation when the system sits near a boundary), and actions must be reversible state machines, not one-way switches, because pressure comes and goes and users notice when effects never return.

The delivery model is transition-driven and rate-limited by design - the API refuses to become the load it reports. A plain observe gives you a callback per state CHANGE (crossing between the browser's default bands), which is exactly the event quality adaptation needs and nothing more. The thresholds option reshapes the bands: your array of utilization cut-points (0 to 1) becomes the boundaries, so states fire when your buckets are crossed rather than the browser's - lower the count and you get fewer, coarser signals; place them around YOUR quality ladder's decision points and every callback becomes actionable. What you never get, deliberately: periodic readings, current-state polling on demand (there is no getCurrentPressure()), or sub-band detail. If you need time-series telemetry, this API is the wrong tool by privacy design - it quantizes precisely so the machine's load profile cannot be exfiltrated. The pattern that works with the grain: on each transition record, apply your ladder action and ALSO stamp a log line locally; over a session you reconstruct a pressure timeline from transitions, which is enough for tuning thresholds without any polling.

This is the API's flagship pattern, and the integration has a clean seam. The seam: your player already has a quality ladder (renditions, effects, camera resolution) and a controller that decides the current rung - Compute Pressure becomes one more input to that controller, joining network throughput (the classic input) and device class. The priority ordering matters: network still leads (bandwidth swings are bigger and faster than CPU states), pressure acts as the ceiling - the network may allow 1080p while a serious CPU state caps you at 720p, and the controller takes the min. The concrete wins reported by early integrations: video calls that drop camera resolution instead of stuttering when a screenshare or a background build hogs the CPU; streaming pages that pause speculation and preloads at serious; effect-heavy pages that degrade gracefully instead of dropping frames. The two adjustments that make it production-grade: hysteresis (drop at serious, restore only after nominal persists for a few seconds - the state API gives you transition records, your controller adds the dwell timer) and user-visible honesty (a quiet quality badge beats silent flapping; users forgive quality, not instability).

The limits are deliberate and knowing them prevents misdesign. Source coverage: the spec ships with 'cpu' only - no GPU pressure, no memory, no network, no temperature; GPU-adaptive rendering still keys off frame timing (requestAnimationFrame deltas), memory pressure off allocation failures and performance.memory where present, network off the Network Information API and throughput probes. System-wide scope: the signal is the machine's load, not your page's contribution - your tab cannot learn what its own work did to the CPU, which kills feedback-loop designs (measure-act-measure) but is precisely what makes cross-page coordination safe. Rate limiting and quantization: transitions arrive late and coarse enough to resist fingerprinting and side channels - do not build timing-sensitive logic on record timestamps. Browser scoping: Chromium-first shipping; unsupported engines throw on construction - the feature detect returns your current behavior, which must be a working (if unadaptive) page. And the honest architectural conclusion: Compute Pressure covers one input of an adaptive system; the production pattern composes it with the network, memory and frame-timing signals behind one quality controller, because real machines are constrained along several axes at once and users experience the worst one, not the average.