The Compute Pressure API: Adaptive UIs based on CPU load

Key takeaways

• The Compute Pressure API lets you observe high-level system pressure states instead of relying on requestAnimationFrame timing heuristics.
• Pressure is reported as one of four states: nominal, fair, serious, or critical.
• Useful for applications that run sustained heavy work (WebAssembly, WebGL/WebGPU, continuous video processing).
• The API is heavily quantized and rate-limited for privacy. It only delivers updates while the document is visible.
• Currently supported in Chromium-based browsers (Chrome and Edge 125+). Not available in Safari or Firefox.

When to use it

Use Compute Pressure when:

• Your app performs continuous heavy computation in workers
• You render complex 3D scenes or run WebGPU workloads
• You process live video or audio on the client
• You have observed devices heating up and throttling under load

Don’t use it when:

• You’re building a content site, blog, or typical e-commerce experience
• Your performance problems stem from main-thread JavaScript, long tasks, or layout thrashing rather than sustained hardware load

In short: PressureObserver tells your application when the device is under significant compute or thermal pressure. Reduce fidelity (lower resolution, pause background work, disable animations) before the operating system is forced to throttle the CPU.

Audience: Developers building performance-sensitive client-side applications, especially those using WebAssembly, WebGL/WebGPU, or continuous media processing.

Why this API exists

Modern web applications can generate sustained CPU and GPU load. When hardware runs near its limits for long periods, devices heat up. Operating systems respond with thermal throttling: they lower clock speeds to protect the silicon.

From the user’s perspective this looks like:

• Dropped frames
• High input latency (poor INP)
• Fans spinning up and battery draining quickly

Developers previously tried to detect this by measuring gaps between requestAnimationFrame callbacks. That approach is unreliable because frame drops can also result from long tasks, garbage collection, or other tabs competing for resources.

The Compute Pressure API provides an OS-informed signal, removing the need for timing heuristics.

Browser support and constraints

Browser	Support
Chrome	125+
Edge	125+
Safari	Not supported
Firefox	Not supported

Privacy and security constraints

Because low-level hardware metrics are sensitive, the API includes protections:

1. Secure contexts only — Available only over HTTPS (and localhost).

2. Visibility requirement — Updates are delivered only while the document is visible and focused. Background tabs receive no updates.

3. Quantization — The API never exposes raw CPU percentages or clock speeds. It reports one of four coarse states.

4. Permissions Policy — Cross-origin iframes are blocked by default. The embedding page must explicitly allow the feature:

   <iframe src="..." allow="compute-pressure"></iframe>

These constraints make the API unsuitable for fingerprinting or high-resolution timing attacks.

Technical Caveats

• Source Limitation: The specification outlines multiple sources, but currently, only "cpu" is supported in Chromium.
• Interval is a request: The sampleInterval is treated as a request by the browser. The user agent may deliver updates less frequently than requested based on battery saver mode or system constraints.
• Global Pressure: The API reports the system’s overall compute pressure, not the isolated contribution of your origin. If another tab is generating extreme load, your application will still receive a serious or critical state.

Using PressureObserver

The surface is intentionally similar to other observer APIs.

if ('PressureObserver' in window) {
  const observer = new PressureObserver((records) => {
    const latest = records[records.length - 1];
    adaptToPressure(latest.state);
  });

  // Request updates every 2 seconds. The browser may deliver less frequently.
  observer.observe('cpu', { sampleInterval: 2000 })
    .catch((error) => {
      if (error.name === 'NotAllowedError') {
        console.warn('Compute Pressure blocked by Permissions Policy');
      } else {
        console.error('PressureObserver failed:', error);
      }
    });
}

Choosing a sample interval

sampleInterval is specified in milliseconds. Hardware thermal states change relatively slowly. Very short intervals are rarely useful and can cause UI fidelity to thrash. A value of 2000 (2 seconds) or 5000 (5 seconds) is standard.

The four pressure states

State	Meaning	Suggested response
nominal	System is lightly loaded	Full fidelity is fine
fair	Moderate load, still comfortable	Continue normal operation
serious	Elevated pressure; approaching limits	Reduce non-essential work
critical	High pressure; system needs relief	Drop to minimum viable fidelity immediately

Exact mapping from underlying hardware metrics to these states is implementation-defined. The states are ordered and intended for progressive degradation.

Implementing adaptive degradation

Map pressure levels to application fidelity using a state manager.

// Assumptions for this example:
// `searchWorker` is an active Web Worker instance.
// `renderer` is an initialized WebGL/Three.js context.

class PerformanceManager {
  constructor() {
    this.fidelity = 'high'; // 'high' | 'low' | 'minimal'
  }

  adapt(state) {
    switch (state) {
      case 'nominal':
      case 'fair':
        this.setFidelity('high');
        break;
      case 'serious':
        this.setFidelity('low');
        break;
      case 'critical':
        this.setFidelity('minimal');
        break;
    }
  }

  setFidelity(level) {
    if (this.fidelity === level) return;
    this.fidelity = level;

    // Manage background work
    if (level === 'low' || level === 'minimal') {
      searchWorker.postMessage({ command: 'PAUSE' });
    } else {
      searchWorker.postMessage({ command: 'RESUME' });
    }

    // Manage DOM animations
    document.body.classList.toggle('reduce-motion', level === 'minimal');

    // Manage rendering engine
    if (level === 'minimal') {
      renderer.setResolutionScale(0.5);
      renderer.setTargetFPS(30);
    } else if (level === 'low') {
      renderer.setResolutionScale(0.75);
      renderer.setTargetFPS(60);
    } else {
      renderer.setResolutionScale(1.0);
      renderer.setTargetFPS(60);
    }
  }
}

CSS support for reduced motion under pressure

.reduce-motion * {
  animation: none !important;
  transition: none !important;
}

This effectively reduces compositor and main-thread work when the system is under high pressure.

Limitations and progressive enhancement

• Chromium-only: Always feature-detect and treat this API as an enhancement.
• Not a replacement for fundamentals: It does not replace avoiding long tasks, efficient rendering, and proper use of workers.
• Abrupt transitions: On many devices, the transition into serious or critical can be abrupt.

Treat Compute Pressure as one signal among others, not as a complete performance strategy.

Summary

The Compute Pressure API gives web applications a standardized way to monitor when the device is under significant compute or thermal pressure. By responding to the serious and critical states, developers can reduce workload before the OS throttles the CPU, preserving responsiveness and battery life.

FAQ

How do I detect thermal pressure in the browser?

Create a PressureObserver, call observe('cpu'), and react to the reported state (nominal, fair, serious, or critical).

Does Safari support the Compute Pressure API?

No. As of 2026, it is supported only in Chromium-based browsers (Chrome and Edge 125+).

Can this API be used for fingerprinting?

No. States are coarse, updates are rate-limited, and observations only occur while the document is visible in a secure context.

What is the difference between serious and critical?

serious indicates elevated pressure and signals a need to reduce non-essential work. critical indicates the system needs immediate relief; drop to the lowest practical fidelity.

From the team at

Web Specification Studio

We build digital products and explore the modern web standards behind them.

About the team

Related posts

• scheduler.yield() and Prioritized Task Scheduling
• Interaction to Next Paint (INP): Diagnosing and Optimizing Main Thread Blocking
• Core Web Vitals in 2026: What Actually Moves Rankings