Intensive Wake Up Throttling in Chromium Explained

This article explores Intensive Wake Up Throttling in the Chromium web browser, a feature designed to significantly improve battery life and CPU performance. It explains what the mechanism is, the specific conditions required to trigger it, and the exact technical process of how it restricts JavaScript setTimeout calls in hidden background tabs to executing only once per minute. Finally, it covers the exceptions that allow critical background web applications to bypass this restriction.

What is Intensive Wake Up Throttling?

Intensive Wake Up Throttling is a power-saving mechanism implemented in Chromium-based browsers (such as Google Chrome and Microsoft Edge) starting in version 88.

Before this feature existed, web pages running in background tabs could continuously execute JavaScript tasks, waking up the CPU multiple times per second. Even if a user was not actively looking at a tab, poorly optimized scripts, analytics trackers, and ad networks could drain laptop batteries and slow down the active foreground tab. Intensive Wake Up Throttling solves this by aggressively limiting how often JavaScript timers are allowed to run when a tab is hidden from view.

How It Restricts setTimeout to Once Per Minute

In JavaScript, developers use setTimeout and setInterval to schedule code to run after a set amount of time. Normally, if a tab is in the background, Chromium applies standard throttling, which limits these timers to firing at most once per second (1000ms). Intensive Wake Up Throttling takes this much further by clamping timer execution to once every 60 seconds.

The browser enforces this one-minute restriction using the following rules and mechanics:

  • The Grace Period: When a user switches away from a tab, making it hidden, a grace period begins. Originally set to 5 minutes (and later reduced to 10 seconds for pages loaded in the background), the tab is only subject to standard 1-second throttling during this window. Once the grace period expires, intensive throttling activates.
  • Timer Nesting Level: The restriction specifically targets "chained" timers. When a setTimeout callback schedules another setTimeout, the browser increments a counter known as the nesting level. Once the nesting level reaches 5 or greater, the timer is flagged for intensive throttling. setInterval calls automatically count as repeating timers and are subject to the same rule after 5 iterations.
  • Timeout Clamping: Once intensive throttling is active and the nesting level reaches 5, Chromium overrides the delay specified by the developer. For example, if a developer writes setTimeout(myFunction, 500) to run a task in half a second, Chromium ignores the 500 millisecond request and forces a minimum delay of 60000 milliseconds (1 minute).
  • Timer Alignment: Instead of letting multiple throttled timers wake up the CPU at random times throughout the minute, Chromium aligns them. All intensively throttled timers in the same tab (and across same-origin tabs) are batched together to execute simultaneously on a single, synchronized 1-minute mark. This maximizes the amount of time the CPU can remain in a low-power sleep state.

Conditions Required for Throttling

Chromium will not blindly throttle every hidden tab, as doing so would break legitimate background functionalities. For a hidden tab to be restricted to the once-per-minute limit, it must be completely silent and inactive regarding user-perceivable tasks.

A hidden tab will bypass Intensive Wake Up Throttling if it meets any of the following criteria:

  • Audio Playback: The tab is actively playing audio (e.g., music streaming services or podcasts).
  • Real-Time Connections: The page has an active WebSocket or WebRTC connection. This prevents chat applications, multiplayer games, and video conferencing tools from disconnecting.
  • Hardware Access: The tab is actively communicating with USB, Bluetooth, or WebMIDI devices.
  • Picture-in-Picture: The tab is currently displaying a video in Picture-in-Picture mode or casting content to an external screen.
  • IndexedDB Activity: The page is in the middle of an active IndexedDB transaction, preventing data corruption.

Impact on Web Development

Because setTimeout cannot be relied upon for precise timekeeping in hidden tabs, developers must adjust how they build web applications:

  1. Avoid Polling: Using setTimeout to repeatedly poll a server for updates in the background will be delayed to once per minute. Developers should use WebSockets or Server-Sent Events (SSE) for real-time data.
  2. Measure Time Accurately: Developers should not calculate passed time by counting how many times a setTimeout has fired. Instead, they should use the Date.now() or performance.now() APIs to check the actual system clock when the timer finally executes.
  3. Use Web Workers for Heavy Tasks: Depending on the specific Chromium version and task type, offloading background processing to Service Workers or using the Web Push API is the recommended way to handle background notifications and state updates without relying on active tab timers.