Although this sounds like a good idea in many ways, the possibility of impacting notification services and messengers does seem like a serious drawback.
The core idea is to limit the processing power that background tabs get in Chrome once the feature lands.
- 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).
The only pages that appear to be exempt from the throttling are those that play audio.
While the change aims to tackle background pages that use an excessive amount of CPU, it may impact any background page, e.g. messengers, chat rooms, notification services, that does something in the background.
While Google states that the implementation won’t break any functionality, some web developers think otherwise.
Samuel Reed mentions on his blog that web application timers may be delayed for minutes (Google reduced the maximum to 30 seconds in the meantime), and that this will impact popular applications like Slack or Discord.
Other web developers have voiced their concern on the official Blink Development forum as well. At least one developer raised the question whether affected sites and services would start to loop a small audio file that is inaudible to the user to avoid the throttling.
Chrome would indicate that audio is playing in its interface, but it could very well happen that sites implement this, at least in the short run.
Google did test the implementation on Gmail and did not notice any issues with the service’s notification system.
Google’s developers also want to make sure that cases where users are multi-tasking are unaffected (switching between different tabs regularly). Ideas mentioned by Google are to either delay the throttling for a period of time before it kicks in, or setting a generous initial budget.