🚡 👩🏽‍🍳 🕦 ブラウザーのリソースを節約し、Webを中断しない方法。 Yandexレポート 💅🏻 👩🏽‍🤝‍👩🏼 🥀

デバイスのパフォーマンスは向上していますが、メモリとプロセッサに対するWebの要求はますます厳しくなっています。タブ間のリソースの適切なレンダリングとスマートな割り当ては、この問題を解決する重要な部分です。 Konstantin Kramlikh PurplePowderは、カンファレンス「I Frontend」での講演で、ChromiumプロジェクトとYandex.Browserの両方で生産性を向上させ、リソースを節約するアルゴリズムに専念しました。

それらのいくつか-たとえばHibernateテクノロジー-は、別の投稿で既にソートされています。ボーンレポートでは、タブの切り替えの観点からだけでなく、コンテンツ、タイル、ページレイヤーのレンダリング方法も考慮して、問題をより広範囲にカバーしています。

最後に、Webインターフェースの開発者は、Webサイトのパフォーマンスの問題を特定して解決する方法を学ぶことができます。

-私の名前はKostyaです。Yandex.Browserチームの内部コンポーネント開発グループの責任者です。ブラウザでは、ブラウザでのすべてのデコードから、すべてのHTML5ビデオから、レンダリング、レンダリング、その他の同様のプロセスに至るまで、5年余りにわたってさまざまなことを行ってきました。

過去1年半から2年間、私はブラウザーのリソースの節約に関連するプロジェクト（CPU、メモリー、バッテリー）に携わってきました。

あなたは言う-コスティア、2019年の庭で、リソースの問題はどこにありますか？必要なデバイスを任意のリソースで購入できます。しかし、オープンMozilla統計に目を向けると、ユーザーの半分が4 GB以下のメモリを持っていることがわかります。また、1つまたは2つの物理コアを持つ多くのユーザーは、視聴者のかなりの部分を占めています。この世界では私たちは生きています。

このタブは頻繁に表示されますか？これは、RAMと古いコンピューターがほとんどない一般ユーザーの場合に正確に起こります。

どうする問題は誰にも秘密ではありません、彼らは3年前に積極的にそれと戦い始めました。それ以来、ナットはさまざまな方法で徐々に締め付けられてきました。 2016年ごろにStack Overflowを行った例を紹介します。これは非常に単純なスニペットです。これはタイトルを更新するだけで、この関数の最後の起動から経過した時間を設定します。理想的には何を入手すべきですか？タイトルの100ミリ秒ごとに+ -100と記述する必要があります。ラッキー。

しかし、開いて開くとどうなりますか？誰かがこれに遭遇しましたか？ Stack Overflowに質問がありました：なぜCookie Clickerがバックグラウンドタブで機能しなくなるのですか？これは、ブラウザーでのCPU使用量を削減することを目的とした最初のChromiumイニシアチブの1つでした。そのアイデアは、ユーザーが今タブを使用していなければ、今はそれを必要としないということでした-それにJSを付けましょう。

ブラウザは、このタブのCPU負荷を約1％に維持しようとします-あらゆる種類のタイマー、JS実行などの一時停止を開始します。これは明るい未来の最初のステップの1つです。

ブラウザでしばらくすると、バックグラウンドタブがまったく機能しなくなるという状況になります。これは私が話している明るい未来です。前回のBlinkOnで発言したChromiumの計画によると、2020年にはそうする予定です。タブをロードし、バックグラウンドの場合は何もしません。これには常に準備が必要です。

Yandex.Browserでは、このような問題も処理しましたが、あまり明確に解決せず、Web全体を破壊することはありませんでした。プロセッサのデコードをオフにし、ビデオカードのデコードのみを残す省エネモードを作成しました。また、FPSを下げ、現在不要でユーザーがバッテリーを節約する必要のあるアニメーションを無効にします。これにより、約1時間のバッテリー寿命が延長されました。 ixbtなど、 checkedなど、誰でもチェックできます。

Kostya、あなたはウェブを「壊した」、一部のユーザーを助けたが、もっと賢いものは思いつかなかったと言う人もいると思う。ハードコアを追加！ブラウザはどのようにページを描画しますか？

簡単に言えば、レイヤーの概念は、ブラウザーがページをレイヤーに分割して個別に描画しようとすることです。これは、一部のアニメーションが実行され、静的なものを強制的に再描画しないようにするために行われます。ブラウザはこれを異なるヒューリスティックで行います。たとえば、ビデオ要素を選択して別のレイヤーに入れようとします。これは、明らかに迅速かつ頻繁に再描画されます。そして、それがどこかに表示される場合、その下のすべてを再描画する必要はありません。

さらに、各レイヤーは256 x 256の長方形のタイルに分割されています。インスペクターでは、このようなものを見ることができます。たくさんのタイルに分割されたフレームがあります。

それは何で、なぜ必要なのですか？まず、レンダリングの優先順位を決定します。私たち全員が描く巨大なソーセージがある場合、ユーザーがViewPortで今持っているものだけを見るのであれば、なぜ私たちはすべてこれを描く必要があるのですか？

このアプローチを使用して、最初にViewPortでユーザーに表示されているものだけを描画し、次にタイルの周りを1つ描画してからスクロールの方向に描画します。ユーザーが下にスクロールする場合-下に描く、上にスクロールする-上。これらすべてのタイルは、これらのタイルに割り当てがあり、それらを描画できる場合にのみ描画されます。その後、ユーザーはそれらを見ることができます。または多分決して。

また、障害を持つ多くの人に役立ちます。ユーザーがページを開いて作品を選択し、すべてを再描画する必要がないとします。以前のレンダリングのほとんどを残すことができます。ここで6枚のタイルを再描画します。すべてが正常になります。

このレベルでは、いくつかの非常に成功した最適化が行われました。たとえば、Chromiumは2017年頃にそのような最適化を行いました。

レンダリングが小さい場合は、それだけを行います。その後、カーソルが点滅し、カーソル領域のみを再描画しますが、このタイルの領域全体は再描画しません。すべてを再描画しないように、CPUを大幅に節約します。

また、メモリの節約にも役立ちます。ここで問題は何ですか？全体が白い長方形。 256 x 256テクスチャ、ピクセルあたり4バイトになると想像してください。この領域は、座標、幅、高さ、色の5つの数字でエンコードできるように見えますが。

Chromiumでは、モノクロ領域の最適化が行われました。ブラウザがこの長方形にレンダリングがないこと、完全にモノクロであり、透明ではなく、他の条件を満たしていることを理解している場合、ビデオカードに指示します-白い長方形を描画し、テクスチャ全体を選択しないでください。

ここで他に最適化できるものは何ですか？残りのタイルを見ると、小さなコンテンツと白い色の大きな領域があります。 Yandex.Browserでは、これについて考え、アダプティブタイルと呼ばれるメカニズムを作成しました。

1つの小さな長方形、タイルがあります。タイルの中央にはほとんどコンテンツがありません。私たちはそれを選択し、そのすぐ下にテクスチャーを作ります。他のすべてもビデオカードについて話しているいくつかの領域に分割されています。このサイズの白で描画するだけです。

ページは、赤で強調表示されているすべてのものの保存も開始します。より複雑なページでは、このように見えます。

まだ多くのレイヤーがあり、各レイヤーはこのように描かれていることを理解することが重要です。各レイヤーで、ある程度のメモリを節約できます。このアプローチにより、すべてのユーザーの平均でビデオメモリの約40％を節約できました。

もっとハードコア！彼らはここで少しのメモリを節約し、ウェブを「破壊」しました。ウェブをさらに「破壊」しませんか？

Chromiumにはポリシーのようなものがあります。ユーザーがバックグラウンドタブを使用しない場合、ユーザーがタブを残した場合、それらは必要ありません。メモリがなくなってブラウザが横になった場合、ユーザーが長い間使用していない最も古いタブを取り、それを強制終了します。彼女はインターフェースに残りますが、プロセスはもう存在せず、すべてのJSは死にます。それは大丈夫ですか？フロントエンドパーティーでこのような質問をし、「何をしているの？」以外の答えを期待するのは奇妙です。

その後、それはあまり行きませんでした。 Chromiumブログからの実際のコメントは次のとおりです。あなたは私のすべてのアプリケーションを壊しました。ある種のゲームがありました-そしてホップ、それは状態がありません。アンロードハンドラーが機能しなかったことを理解することが重要です。このタブを配置しただけです。その後、ユーザーはそこに戻り、何も起こらなかったようにネットワークからリロードします。

その後、このアプローチは一時的に放棄され、より思慮深い真剣なアイデアを思いつきました。彼らは彼女を捨てと呼びました。

ポイントは何ですか？これはタブの削除と同じですが、制御のみです。スマートワードPage Lifecycle APIと呼ばれます。タブがあり、ユーザーが長時間タブを表示していない場合、タブはフリーズ状態になります。ブラウザはイベント中に次のように言います：今私はあなたを凍らせています。イベント処理後、何も実行されません。必要なことを行い、準備をします。

その後、再開イベントを通じて凍結状態を終了できますが、おそらく何も起こりませんでした。または、ブラウザが本当にメモリをすぐに解放する必要がある場合は、それを取得して強制終了します。しかし、ユーザーがこのタブに戻った場合、それをリロードし、ドキュメントの廃棄フィールドを設定します。

現時点では、これらのイベントをすでにサブスクライブしてキャッチし、何らかの方法で処理できます。タブが本当に削除されている場合、破棄されたフィールドを確認できます。これは、破棄後に復元されたことを意味します。以前の状態を復元できます。

Yandex.Browserで私たちは数年前に考えました：複雑な基本的なアプローチを使用しない理由。彼らは彼を休止状態と呼びました。

ポイントは何ですか？いくつかのタブ、ある種のJSが実行されている、ある種の状態があります。タブごとに個別のプロセスが作成されます。ここではビデオを再生でき、ここではフォームに何かを残します。 Hibernateが到着し、プロセスはありません。私達は皆それらを得た。しかし、これらのタブに切り替えると、プロセスが戻り、状態全体が配置され、ビデオは適切な瞬間から再生され続け、フィールド内のすべてのテキストはそのまま残ります。

私たちは何をしましたか？各レンダラー内には3つの最も重要なものがあります。JS全体を実行するV8、DOM全体を保存するBlink、およびすべてをタブなどで接続するための何らかのブラウザーバインディングです。

たとえば、サンプルを考えてみましょう。ここで、onloadが発生するのを待ち、DOMツリーに新しいdiv要素を追加します。ブラウザの場合、次のようになります。

当然、DOMツリーがあり、いくつかのフィールド、関連するオブジェクトがあり、そのようなエンティティがあります。

V8では、各ノードの状態が保存され、これらのノードはバインダーのレイヤーを介して点滅オブジェクトに関連付けられます。私たちは何をしましたか？ V8からシリアライザーを取得し、V8の状態全体をシリアライズし、関連するすべてのオブジェクトをBlinkで見つけ、さらにDOMツリー全体を保存してシリアライズし、ディスクに書き込み、圧縮および暗号化するシリアライザーを作成しました。そして、そのようなスナップショットから回復するようブラウザに教えました。つまり、ユーザーがそのようなタブに移動すると、そのタブを展開し、解読してユーザーに表示し、完全に復元します。（ Hibernateに関する別の投稿 - 約）

現在、Hibernateは安定した全員に公開されており、各ユーザーが平均1つまたは2つのタブを保存できるようになっています。つまり、彼は平均して常に1つのタブ、またはおそらく2つのタブを保存しています。これにより、10個を超えるタブを持っているユーザーのメモリが節約されます-あなたと同じですが、私たちは代表ではありません。

ブラウザがどのように手助けをしようとしているのかを説明しましたが、今度は各自がサイトを高速化し、パフォーマンスを改善するために何かをすることができます。今日すぐに来て、することができます。

まず、メモリの問題があるかどうかを理解する必要があります。

特定の症状があります。サイトが劣化し始めるか、フェードが表示されます。通常、これは、ガベージコレクターがトリガーされ、全世界が凍結され、何も描画されないことを意味します。または、サイトの速度が絶えず低下することもあります-これも起こります。

問題があるかどうかを理解する必要があります。 JSメモリで何が起こるかを見てみましょう。

彼女が前後にジャンプしたり、継続的に成長する場合、これは良い症状ではありません。または継続的に成長しています。

この場合、DevToolsを使用していつでもスナップショットを取得できます。 JSのリークに悩まされている人はいますか？誰かが知らない場合、JSでリークが発生する可能性があります。

たとえば、ツリーに挿入されていないノードを追加するグローバル変数があります。あなたはそれらを忘れて、それから彼らは数百キロバイト、あるいはメガバイトさえ食べていることがわかります。

厳密に言えば、このような切り離されたノードをどうするかは明確ではありません。それらをツリーから引き出してから、挿入し直すことができます。通常、写真の状態または何か他のものが彼らに残っているからです。したがって、それらを見つけて問題を処理できます。

タイムラインでメモリ割り当てを確認することもできます。体系的な退院があり、何もきれいにしない場合-これも悪い兆候です。誰もがこれを理解していると思います。

そして、タブのレイヤーで遊ぶことができます。ブラウザーは通常、この点でヒューリスティックを使用して動作します。頻繁に変化すると見なされるオブジェクトを別々のレイヤーに分離しようとします。しかし、時にはあまりうまくいかず、多くのメモリを消費するレイヤーがたくさんあることがわかります。このような状況があるかどうかを常に確認し、一部のレイヤーを削除して、このレイヤーが占有しているメモリ量を確認できます。

問題の別の層はパフォーマンスです。 setTimeoutは、アニメーションには適していません。ブラウザがページをレンダリングする方法では機能しません。フェーズで動作しない場合があります。ブラウザはフレームを要求しましたが、setTimeoutが動作しなかったため、アニメーションはまだありません。または、何も描画する必要がない場合でも機能します。ユーザーは退出しましたが、まだバックグラウンド作業が残っていますが、setTimeoutを使用して作業します。

これは、ブラウザがこのページを描画する必要がある場合にのみコールバックが呼び出す正しいアプローチです。

また、ブラウザが1秒あたり60フレームを描画する場合、各フレームに約16ミリ秒が必要であることを思い出してください。

また、メインストリームを16ミリ秒より長く占有すると、フレームスキップが保証されます。これはユーザーにとってかなり不快なものです。サイトが動き始めます。したがって、すべてのハードワークはバックグラウンドスレッドに正しく配置され、単純に結果が返されます。

または、別のアプローチはマイクロタスクを使用することです。タスクキューを作成し、しばらくしてからクォータが終了するまで処理し、ブラウザに静かにページを描画させます。

当然、新しいレイヤーを追加できます。ブラウザはヒューリスティックに基づいて動作し、必要と思われるレイヤーを選択しようとします。ただし、この要素が今すぐアニメーション化されることがわかっている場合は、別のレイヤーでこの要素を選択する必要があることをブラウザーに明示的に通知することをお勧めします。その後、より効率的に描画されます。

最新の興味深いアプローチ-文句を言う。問題がある場合は、来て話をすることは常に役立ちます。たぶん、この問題は簡単に対処でき、お互いに助け合うでしょう。

少しの背景。この機能は現在機能しています。検索エンジンページの開発チームがやってきました。最初のスニペットのレンダリング時間などのメトリックがあります。ユーザーがクリックする必要のある最初のリンクを以前に表示し、そのリンクが正しい答えを提供する可能性が高い場合、できるだけ早くリンクすることをお勧めします。彼らはやってきて、今度はどうにかしてスピードを上げることができるかと尋ねました。

調査し、性能テストを実施し、プロトタイプを作成しました。サイトが最初に何を描画するかを教えてくれれば、これができることがわかりました。テストして、パフォーマンスが向上することを確認しました。現在、私たちはこれを少数の聴衆のために実稼働でテストしています。私たちはそれがどうなるのかを見ています。お楽しみに。

世界は静止していません。ユーザーはますます欲し始め、ブラウザは変化し、ウェブは変化しています。これは正常です。私たちは、食料品の機能を作るだけでなく、コンテンツの消費に関して最高の体験を得るためにあらゆる方法でユーザーを支援することも試みています。そして、一般的なブラウザでの変更に常に備える必要があります。当然、問題がある場合-来て、私たちはお互いに話し合い、助け合う準備ができています。

ここで、さまざまな便利なリンクを集めました。

ブラウザーのリソースを節約し、Webを中断しない方法。 Yandexレポート

More articles: