The next changes in the Chrome browser are unlikely to please the developers of Slack, Discord and other programs that work in browser tabs. The beta version of Chrome 56 introduces a new mechanism for optimizing timers for background tabs .

At first glance, the initiative of developers looks like a good thing. The September implementation plan (Intent to Implement) explains the reasons that led the developers to such a decision.
')
The main reason is that some poorly designed applications (for example, analytics scripts and javascript ads) consume a lot of CPU resources, although they are in the background. This negatively affects the performance of the browser and consumes battery power on mobile devices. Such processing of activity in the background tabs is completely useless. The idea is to set the maximum limit of computing resources that can be given to the background application.

The implementation of the plan is as follows:

• Each WebView component will have a budget (in seconds) for running timers in the background.
• The timer can not start if the budget is negative.
• After the timer is completed, its running time is subtracted from the budget.
• The budget is automatically replenished with time (at 0.01 from the budget with every second of real time).

The developers decided that the inhibition of background tabs does not interfere with the user. Tabs with active sound in Chrome are not considered to be background, so that innovation does not affect them.

Three types of background pages were the most worrying:

• who use a timer to change the favicon, like Gmail does;
• which use timers to play sound, for example, for the sound of an incoming message in the messenger (applies to almost all instant messengers and group chats);
• the newly opened page, which started loading, and the user at this time opens a new tab with the expectation that this page will load to the end in the background.

Preliminary tests showed that the implementation of the inhibition of the background tabs did not break the Gmail functionality, although it slowed down some notifications in those messengers and programs that actively use CPU resources. Overall, the implementation worked well and really reduced power consumption and increased browser performance in active tabs.

The problem with loading pages was decided so that the timer budget does not extend to loading pages at all, that is, they are not actually considered to be background.

It would seem that the developers have thought of everything and everything is fine. A slight slowdown with the arrival of notifications in the messenger is not such a big problem.

But in reality, it turned out that notifications in background applications may arrive a few minutes late . This already specifically breaks the functionality of such applications. The creators will have to look for ways to get around this built-in “power saving mode” Chrome. It seems obvious reception with constant sound playback at zero volume. Perhaps they will come up with something else.

It would seem that background applications need only reduce CPU consumption in order to meet the computational budget that the browser allocates for them. But this is not an option. In reality, many applications really need to do a lot of work in the background. For example, popular programs like Slack and Discord constantly synchronize channels, parse new messages from hundreds of users in dozens of channels to determine when to disturb the user with a notification, and when not to do so.

Slack and Discord are not the only such programs, there are so many other web applications that are actively running in the background. For example, exchanges for bitcoin trading in real time. To test the new Chrome mode, the developer of one of such resource-intensive applications launched the setInterval process in the background tab of Chrome 56 with execution every second and fixing the real time of execution. Here is what real time he recorded in the log:

1002
1003
1000
1012
1001
1965
1962
1089
2078
1832
1071
6917
34402
136717
76192
38682
6030

As you can see, after five seconds, the background tab began to stand out from the budget, which the browser allocated to it. And after 22 real seconds, the budget was completely over (delayed the event by 136 seconds).

That is, now the timers in web development cannot be relied at all . Negative consequences are expected by sites that keep open WebSocket connections.

Chrome developers recommend migrating relevant processes to Service Workers. it is necessary to work, of course, rewriting the code and solving compatibility problems. But there everything should work fine. Of course, until such time as the Chrome developers decide to slow down the background Service Workers, too.

Developers of such applications that run in the background are encouraged to use the Page Visibility API so that the application does not do work in the background that will still be invisible to the user.

  var doVisualUpdates = true; document.addEventListener('visibilitychange', function(){ doVisualUpdates = !document.hidden; }); 

This technique allows you to reduce CPU utilization by 75%

Other innovations in Chrome 56

The official release of the stable version of Chrome 56 (Blink engine version 537.36) is scheduled for January 2017 (approximately January 31 ).

In the next official version of Chrome 56, developers do not plan to include activity suppression in the background tabs. This experiment will continue on the beta channel, and after collecting user feedback, it is planned to roll it out in Chrome 57 (March 14, 2017). Now developers are discussing what changes to make in the mechanism of suppression of background tabs. The discussion page discusses various options for exclusion: meta tags, fixed tabs, explicit user permission to display notifications.

A new feature in Chrome 56 is that it will, by default, consider HTTP pages containing a password field unsafe. Such pages will be marked with a prominent red indicator.



Over time, all sites that have not switched to HTTPS will receive a similar indicator.