"L'enfer est plein de bonnes volontés ou désirs"
Chrome 56 introduces a commendable optimization to throttle background tabs' timers. From the Intent to Implement, the gist is:
![]()
Chrome 56 introduces a commendable optimization to throttle background tabs' timers. From the Intent to Implement, the gist is:
- Each WebView has a budget (in seconds) for running timers in background.
- A timer task is only allowed to run when the budget is non-negative.
- After a timer has executed, its run time is subtracted from the budget.
- The budget regenerates with time (at rate of 0.01 seconds per second).
This is generally a Good Thing. Browser vendors should be concerned about battery life, and this will do a lot to help. Unfortunately, this implementation is ignoring the new reality: the browser is no longer just a reading device; it is the world's largest application platform.
This will break the web.
When idle, your application's timers may be delayed for minutes. Aside from terrible hacks like playing zero-volume sounds, you have no control over this. Avoiding expensive CPU work is not a panacea; that some applications must do significant work in the background, including syncing data, reading delta streams, and massaging said data to determine whether or not to alert the user.
Worse yet, the heuristic is based on local CPU time; faster clients may have no issue and face no throttling, but slower devices often will, causing cascading processing and notification delays.
Popular applications like Slack and Discord, as well as our own application (BitMEX, a Bitcoin trading site) will be hugely and adversely affected by this. What good is the user granting the Notification permission if we can't do the processing necessary to even fire the notifications?
Before you think this sounds alarmist, here's real data from a few days ago, where I ran a simple `setInterval` every second while our application ran and recorded the actual time elapsed. This shows timer delays on a site that does a medium amount of background processing:
Gone are the days when you could count on timers to fire semi-reliably.
This has dire ramifications for sites that keep WebSocket subscriptions open. In fact, we've already begun work with Primus to remove client-side heartbeat timers which will make it into a new semver-major soon. Emulation libraries like socket.io may have more trouble.
The recommendation from the Chrome team is to move this work to Service Workers. While it's great to have a way out, this recommendation involves significant compromises, development work, and compatibility fallbacks. And who's to say that Chrome won't have to start throttling noisy Service Workers in the future?
If you run an application that counts on background timers firing reliably, please leave a respectful comment explaining your use case in the Intent to Ship thread before this rolls to Stable. The team is listening and has already acknowledged their intent to make this throttling less aggressive. More data points would be very useful to them to ensure Chrome 56 does not break the web.