Chromeブラウザーの次の変更は、Slack、Discord、およびブラウザーのタブで動作する他のプログラムの開発者を喜ばせる可能性は低いです。 Chrome 56ベータ版では、 バックグラウンドタブ用の新しいタイマー最適化メカニズムが導入されています 。



一見、開発者のイニシアチブは良いことのように見えます。 実装する9月の意図は、開発者をそのようなソリューションに導いた理由を説明しています。



主な理由は、設計が不十分なアプリケーション（分析スクリプトやjavascript広告など）がバックグラウンドにあるにもかかわらず、多くのCPUリソースを消費するためです。 これは、ブラウザのパフォーマンスに悪影響を及ぼし、モバイルデバイスのバッテリー電力を消費します。 バックグラウンドタブでのアクティビティのこのような処理は、まったく役に立ちません。 考え方は、バックグラウンドアプリケーションに与えることができるコンピューティングリソースの最大制限を設定することです。



計画の実装は次のとおりです。

• 各WebViewコンポーネントには、タイマーをバックグラウンドで実行するための予算（秒単位）があります。
• 予算がマイナスの場合、タイマーは開始できません。
• タイマーが実行されると、その稼働時間が予算から差し引かれます。
• 予算は時間とともに自動的に更新されます（リアルタイムの1秒ごとに予算から0.01ずつ）。

開発者は、バックグラウンドタブを解除してもユーザーの邪魔にならないと判断しました。 Chromeでアクティブなサウンドを持つタブはバックグラウンドとは見なされないため、イノベーションがタブに影響することはありません。



最大の懸念は、3種類のバックグラウンドページが原因でした。

• Gmailのように、タイマーを使用してファビコンを変更するユーザー。
• メッセンジャーの着信メッセージの音など、タイマーを使用して音声を再生します（ほぼすべてのインスタントメッセンジャーおよびグループチャットに適用されます）。
• ロードされたページを開いたばかりで、この時点でユーザーはこのタブがバックグラウンドで最後までロードされることを期待して新しいタブを開きます。

予備テストでは、バックグラウンドタブのブレーキをかけても、Gmailの機能が損なわれないことが示されましたが、インスタントメッセンジャーやCPUリソースを積極的に使用するプログラムでの通知は遅くなりました。 一般に、実装は正常に機能し、アクティブなタブでの消費電力とブラウザーのパフォーマンスを大幅に削減しました。



ページの読み込みに関する問題は、タイマーの予算がページの読み込みにまったく適用されないように、つまり実際にはバックグラウンドと見なされないように決定されました。



開発者はすべてを熟考し、すべてがうまくいくように思えます。 メッセンジャーへの通知の到着によるわずかな減速は、それほど大きな問題ではありません。



しかし、実際には、バックグラウンドアプリケーションの通知が数分遅れて到着することが判明しました。 これは、すでにそのようなアプリケーションの機能を明確に破壊しています。 クリエイターは、この組み込みのChromeの「省エネモード」を回避する方法を探す必要があります。 どうやらそれはゼロ音量で音を絶えず再生する受信のようです。 おそらく彼らは何か他のものを思い付くでしょう。



バックグラウンドアプリケーションは、ブラウザが割り当てる計算予算を満たすためにCPU消費を削減するだけでよいように思われます。 しかし、これはオプションではありません。 実際には、多くのアプリケーションはバックグラウンドで多くの作業を行う必要があります。 たとえば、 SlackやDiscordなどの人気のあるプログラムは、常にチャネルを同期し、数十のチャネルの数百人のユーザーからの新しいメッセージを解析して、通知でユーザーに通知するタイミングとしないタイミングを決定します。



SlackとDiscordだけがこのようなプログラムではなく、バックグラウンドでアクティブに動作する他の多くのWebアプリケーションがあります。 たとえば、リアルタイムでのビットコイン取引の交換。 新しいChromeモードをテストするために、このような要求の厳しいアプリケーションの開発者は、Chrome 56のバックグラウンドタブでsetInterval



プロセスを起動し、1秒ごとに実行してリアルタイムの実行時間を修正しました。 ログに記録されたリアルタイムは次のとおりです。



1002

1003

1000

1012

1001

1965

1962

1089

2078

1832

1071

6917

34402

136717

76192

38682

6030







ご覧のとおり、5秒後に、背景タブが、ブラウザーが割り当てた予算から外れ始めました。 そして、実際の22秒後、予算は完全に終わりました（イベントでの136秒の遅延）。



つまり、Web開発のタイマーはまったく頼ることができなくなります 。 負の結果は、開いているWebSocket接続を保持するサイトを待ちます。



Chrome開発者は、プロセスをService Workerに移行することをお勧めします。 もちろん、コードを書き直し、互換性の問題を解決するために、一生懸命働く必要があります。 ただし、すべてが正常に機能するはずです。 もちろん、Chrome開発者がバックグラウンドのService Workerの速度を落とすまでは。



バックグラウンドで実行されるこのようなアプリケーションの開発者は、ページ可視性APIを使用することをお勧めします。これにより、アプリケーションは、ユーザーには見えない作業をバックグラウンドで実行しません。

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この手法により、CPU使用率が75％削減されます。

Chrome 56のその他の革新

Chrome 56の安定バージョン（Blinkエンジンバージョン537.36）の公式リリースは、 2017年1月 （予定1月31日 ）に予定されています。



Chrome 56の次の公式バージョンでは、開発者はバックグラウンドタブでアクティビティ抑制を有効にする予定はありません 。 この実験はベータチャネルで継続され、ユーザーフィードバックを収集した後、Chrome 57で展開する予定です（2017年3月14日）。 現在、開発者は、バックグラウンドタブの抑制メカニズムにどのような変更を加えるかについて議論しています。 ディスカッションページでは 、メタタグ、固定タブ、通知を表示するための明示的なユーザー許可など、さまざまな例外が考慮されます。



Chrome 56の革新は、パスワードフィールドを含む安全でないHTTPページをデフォルトで考慮することです。 そのようなページには、目立つ赤いインジケータが付いています。







時間が経つにつれて、HTTPSに切り替えていないすべてのサイトで同様のインジケーターが受信されます。