loke.dev
Header image for The Silent Throttle: Why Your Performance Logic Is Incomplete Without the Compute Pressure API

The Silent Throttle: Why Your Performance Logic Is Incomplete Without the Compute Pressure API

Discover how to prevent thermal throttling from ruining your user experience by implementing adaptive performance scaling based on real-time hardware telemetry.

· 9 min read

Your user's cooling fan is a more accurate profiler than Chrome DevTools. You can spend weeks shaving 50ms off your main-thread execution time, but if the user is running your app on a fanless MacBook Air in a 90-degree room while sharing their screen on Zoom, your "optimized" code is going to run like a slideshow. Most performance logic today assumes a static environment, but the reality is that hardware is a moving target.

We’ve spent a decade obsessing over the "Critical Rendering Path" and "Core Web Vitals," yet we’ve remained almost entirely blind to the physical state of the machine running our code. When a device hits its thermal limit, the operating system doesn't ask for permission; it simply downclocks the CPU. Your 3.2GHz processor is suddenly a 1.1GHz processor. If your app doesn't know this has happened, it will continue trying to push 60 frames per second until the entire UI locks up.

This is where the Compute Pressure API changes the game. It provides a window into the hardware's stress level, allowing us to pivot from "static performance" to "adaptive performance."

The Invisible Wall of Thermal Throttling

Thermal throttling is the silent killer of web performance. It’s the reason why an app feels buttery smooth for the first five minutes and then starts stuttering for no apparent reason.

In the browser, we usually measure performance through proxies: requestAnimationFrame delta times, Long Tasks, or the PerformanceObserver. These tell us that things *are* slow, but they don't tell us *why*. Is the main thread busy because of a complex calculation, or is the main thread slow because the CPU has been throttled to 25% of its capacity to prevent the battery from melting?

If you treat a throttled CPU the same as a busy CPU, your mitigation strategies will fail. For example, if the CPU is throttled, adding more Web Workers won't help—it might actually make things worse by increasing the thermal load. The only solution is to do less work.

Enter the Compute Pressure API

The Compute Pressure API offers high-level states that represent the "pressure" the system is under. Instead of giving us raw CPU percentages (which would be a privacy nightmare and hard to interpret), it gives us categorized buckets.

As of the current implementation (largely spearheaded by Intel and Google), we get four primary states:

1. Nominal: The system is running cool. You have plenty of headroom. Push all the pixels you want.
2. Fair: There’s some pressure, but it’s manageable. Maybe the fans are spinning up.
3. Serious: The system is under significant pressure. Throttling is likely occurring or imminent.
4. Critical: The system is exhausted. If you don't scale back immediately, the OS will take drastic measures.

A Basic Implementation

Before we dive into the "why," let’s look at the "how." The API uses a PressureObserver. It’s remarkably similar to IntersectionObserver or ResizeObserver.

if ('PressureObserver' in window) {
  try {
    const observer = new PressureObserver((records) => {
      // The observer returns an array, but we usually care about the latest record
      const latest = records[0];
      
      console.log(`Current Pressure: ${latest.state}`);
      console.log(`Source: ${latest.source}`); // Currently only 'cpu' is supported
      
      handlePressureChange(latest.state);
    });

    // We start observing the 'cpu' source
    await observer.observe('cpu', {
      // Sample interval is a hint to the browser
      sampleInterval: 1000 
    });
  } catch (err) {
    console.error("Compute Pressure API failed to initialize:", err);
  }
} else {
  console.log("Compute Pressure API is not supported in this browser.");
}

The sampleInterval is important. You don't need millisecond-level precision for thermal states. Hardware temperature doesn't change that fast, and reacting too quickly can lead to "flapping"—where your app rapidly toggles features on and off, creating a jarring user experience.

Why Your Current Performance Logic is Incomplete

Most "adaptive" web apps use one of two triggers:
1. Network Quality: Using navigator.connection to downgrade images.
2. Device Memory: Using navigator.deviceMemory to prune caches.

These are "snapshot" metrics. They tell you about the device's potential, not its current reality. A device with 16GB of RAM can still be thermally throttled to the point where it can't handle a complex SVG animation.

If you aren't listening to compute pressure, you are essentially driving a car without a temperature gauge. You’re assuming that because you have a V8 engine, you can always go 100mph, ignoring the smoke pouring out of the hood.

Case Study: The Collaborative Canvas

Imagine you’re building a collaborative whiteboarding tool like Miro or Excalidraw. You have a complex canvas with thousands of objects, real-time cursors for twenty people, and a mini-map in the corner.

In a Nominal state, you want:
- 60fps animations.
- Anti-aliasing enabled.
- High-frequency cursor updates.
- Real-time drop shadows.

When the state hits Serious, you need to make sacrifices to keep the core experience functional.

function handlePressureChange(state) {
  switch (state) {
    case 'nominal':
      CanvasEngine.setQuality('high');
      CanvasEngine.enableShadows(true);
      Network.setCursorBroadcastRate(16); // 16ms updates
      break;
    
    case 'fair':
      CanvasEngine.setQuality('medium');
      // Maybe keep shadows but simplify math
      break;

    case 'serious':
      CanvasEngine.setQuality('low');
      CanvasEngine.enableShadows(false);
      CanvasEngine.disableMiniMap();
      Network.setCursorBroadcastRate(100); // Drop to 10hz
      break;

    case 'critical':
      // Survival mode
      CanvasEngine.stopAnimations();
      CanvasEngine.renderStaticFrame();
      Network.setCursorBroadcastRate(500); 
      UI.showNotification("Performance mode enabled to save battery/cool device");
      break;
  }
}

The leap from serious to critical is where most developers fail their users. When the state is critical, the goal isn't "smoothness"—the goal is "functionality." You are essentially trying to prevent the browser tab from crashing or the user's laptop from becoming a literal lap-burner.

The Strategy of Progressive Degradation

Don't just flip a switch. Effective use of the Compute Pressure API requires a hierarchy of features. You need to know what to kill first.

I like to categorize features into three buckets:

1. Essential: Core functionality (e.g., text being readable, ability to save).
2. Enhancements: Non-essential visuals (e.g., hover effects, smooth scrolling, transitions).
3. Luxury: Computationally expensive candy (e.g., background blur, particle effects, high-res previews).

When the PressureObserver reports fair, you kill the Luxury. At serious, you trim the Enhancements. At critical, you start stripping the Essential features down to their most basic, static versions.

Managing State Transitions (The Debounce Problem)

One "gotcha" with hardware telemetry is oscillation. If you turn off background blur, the CPU usage drops. Because the CPU usage drops, the pressure state might go from serious back to fair. If you immediately turn the blur back on, the pressure goes back to serious.

You end up in a loop. To solve this, you need a "cooldown" period or a more sophisticated state manager.

class PressureManager {
  constructor() {
    this.lastState = 'nominal';
    this.cooldownTimer = null;
    this.COOLDOWN_MS = 10000; // Wait 10s before upgrading performance
  }

  onPressureChange(newState) {
    const weights = { nominal: 0, fair: 1, serious: 2, critical: 3 };
    
    // If the new state is worse, react immediately
    if (weights[newState] > weights[this.lastState]) {
      this.applyState(newState);
      this.resetCooldown();
    } 
    // If the new state is better, wait to see if it stays that way
    else if (weights[newState] < weights[this.lastState]) {
      this.queueUpgrade(newState);
    }
  }

  applyState(state) {
    this.lastState = state;
    // Dispatch events or trigger UI updates...
    console.log(`Applying performance profile: ${state}`);
  }

  queueUpgrade(newState) {
    if (this.cooldownTimer) clearTimeout(this.cooldownTimer);
    
    this.cooldownTimer = setTimeout(() => {
      this.applyState(newState);
    }, this.COOLDOWN_MS);
  }
}

This logic ensures that we degrade performance instantly to protect the user's hardware, but we are cautious about ramping back up. We want to be sure the system has actually stabilized.

Real-world Example: Video Conferencing

This is perhaps the most critical use case for the Compute Pressure API. Modern video apps are incredibly heavy. They do noise suppression, background blur, and face tracking—all on the client.

If a user is in a 1-on-1 call, it might be fine. But if four more people join, the CPU load spikes. If the user starts sharing their screen, the device might hit critical.

async function manageVideoPipeline(state) {
  const stream = await navigator.mediaDevices.getUserMedia({ video: true });
  const track = stream.getVideoTracks()[0];
  
  // This is a hypothetical interface for a background blur processor
  const blurProcessor = window.myBlurProcessor;

  if (state === 'critical') {
    // Disable heavy processing entirely
    blurProcessor.stop();
    // Reduce frame rate at the hardware level
    await track.applyConstraints({ frameRate: 15 });
  } else if (state === 'serious') {
    // Use a lighter blur algorithm
    blurProcessor.setQuality('low');
    await track.applyConstraints({ frameRate: 24 });
  } else {
    blurProcessor.setQuality('high');
    await track.applyConstraints({ frameRate: 30 });
  }
}

By reducing the frameRate via applyConstraints, you’re telling the camera and the browser's ingest pipeline to do less work. This reduces the heat at the source, which is much more effective than just trying to hide elements in the DOM.

The Privacy Elephant in the Room

You might be wondering: "Can I use this to fingerprint users?"

It's a valid concern. Any API that reveals hardware characteristics is a potential vector for fingerprinting. This is why the Compute Pressure API has built-in protections:

1. Rate Limiting: The browser doesn't give you real-time, high-resolution updates. It averages the data and throttles the callback frequency.
2. Generic States: You don't see "CPU Temperature: 94C." You see "Serious."
3. User Focus: Usually, browsers only provide this data to the active, visible tab. If your app is in the background, the observer will likely stop firing or return "nominal" to prevent cross-tab tracking.
4. Permissions: While currently available without a prompt in some implementations, it’s designed to be gated if necessary.

The "Gotchas" You'll Encounter

It's not all sunshine and low CPU temps. There are things that will trip you up:

* Virtual Machines: If a user is running your app in a VM (like Citrix or a cloud desktop), the compute pressure might reflect the host machine or a weirdly virtualized slice of it. It’s often less accurate here.
* Low-Power Mode: Some OS-level "Battery Saver" modes artificially throttle the CPU. The Compute Pressure API will reflect this as high pressure, even if the chip isn't "hot," because the *available* resources are low. This is actually a good thing—you still want to scale back.
* Browser Support: Currently, this is a Chromium-heavy API (Chrome, Edge, Opera). Firefox and Safari have historically been more conservative with the Generic Sensor APIs due to privacy concerns. You must feature-detect.

Beyond the CPU

While the current spec focuses on the CPU, the concept of "pressure" is expanding. There’s talk of adding gpu and even ram as sources. Imagine being able to detect that the GPU's VRAM is nearly full and automatically switching your 3D model to a lower LOD (Level of Detail) before the context is lost.

This moves us away from the "One Size Fits All" web. We’ve spent years making our designs responsive to screen size; it’s time we made our logic responsive to the silicon.

Summary: Stop Guessing

If you're building a "heavy" web application—whether that's a game, a creative tool, a communication suite, or a data visualizer—your performance logic is incomplete without the Compute Pressure API.

Stop guessing if the user's device can handle that next feature. Stop assuming that deviceMemory or a fast LCP means the user is having a good experience. Listen to the hardware. When the device says it’s struggling, believe it.

The goal of web performance isn't to be fast; it's to be reliable. And you can't be reliable if you're ignoring the physical reality of the machine. Implement a PressureObserver today. Even if all you do is log the data to your analytics for a month, you'll be shocked at how often your users are hitting that invisible wall.