おはようございます。最近、Mail.Ru Mailのページのスクロールが遅くなる問題を解決しました。 この問題は、網膜ディスプレイで特に顕著でした。 簡単な分析の後、ページのレンダリングが遅いことが主な問題の1つであるという結論に達しました。
この記事では、Chromeツールボックスの一部であるSkia Debuggerツールを使用して、ページのレンダリングプロセスを段階的に分析する方法と、それを使用して各要素をレンダリングするのにかかる時間に関する情報を取得する方法を示します。
多くの同様の最適化問題と同様に、この問題はさまざまな方法で解決できます。 かなりの時間がかかったため、レンダリングの最適化を行いました。 したがって、すぐにパフォーマンスが向上し、それに応じてスクロールの滑らかさが向上し、レンダリングが高速化されました。
最初に、ページのレンダリングにかかる時間を確認することにしました。 これには、 devtoolsの 「連続ページの再描画を有効にする」設定を使用できます。 このオプションにより、ブラウザはユーザーの操作なしでページを常に再描画します。 このモードでは、ページのレンダリング時間が表示されたパネルも表示されます。 devtoolsのこの機能およびその他の機能については、 この記事で詳しく説明しているため、ここでは重点を置きません。 測定を行った後、網膜上の解析されたページが100ミリ秒のオーダーでレンダリングされ、ページをスクロールすると速度が低下することがわかりました。 devtoolsでタイミングを記録するときに見ることができるデータは、ページ全体が描画された時間しか含まれておらず、犯人を見つける必要があるため、あまり有益ではありませんでした。
そこで、どのブラウザコンポーネントがレンダリングを担当し、どのログが減速の原因を理解するのに役立つかを探し始めました。 私はこの記事とChromium アーキテクチャを研究することから始めました。これはパブリックドメインで利用可能であり、概念的にはChromeアーキテクチャと違いはありません。
これらの記事では、レンダリングを担当するコンポーネントとそれが提供するログに興味がありました。 グラフィックコンポーネントを説明する章から、基本的にすべての作業はSkiaライブラリにかかっていることを学びました。 嬉しいことに、Skia Debuggerデバッガーは彼女のために開発されました。これは、プロジェクトのWebサイトのスクリーンショットから判断すると、私にとって必要でした。 しかし、残念ながら、それをインストールすることは私にとって簡単な作業ではありませんでした（デバッガー自体を組み立ててChromeを再構築する必要がありました）。
もう少し検索した後、 このビデオへのリンクを見つけました。 このデバッガーはChrome Canaryに組み込まれており、 --enable-skia-benchmarkingオプションを使用してブラウザーを起動することで使用できることがわかりました。Macでは、次のコマンドでこれを実行できます。
/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-skia-benchmarking
このパラメーターを使用してブラウザーを起動したら 、アドレスchrome：// tracingに移動します 。 次のタブが表示されます。
分析したいページでもう1つのタブを開きます。 私の場合、それはメールリストページでした。 chrome：//トレースタブに戻り、[記録]をクリックすると、ポップアップが開きます。 その中で、リストから「フレームビューア」を選択し、記録をクリックします。 その後、記録が開始され、分析されたタブで任意のアクションを実行できます。記録バッファーは非常に制限されており、比較的小さなデータが収まるため、複数のタブを開いたままにしないことをお勧めします。
関心のある手順を完了したら、[トレース]タブに戻って[停止]をクリックします。 その後、記録時にシステムで何が起こったかについての情報を含む図を作成します。 すべてのデータは、ブラウザプロセスごとにグループ化されます。 メッセージのリストを使用したプロセスに興味があります。タイトルで簡単に見つけることができます。 このプロセスでは、セクションcc :: Pictureを参照します。このセクションでは、ブラウザーで描画された最終画像が円で示されます。
それらの中には、ページ全体のレンダリングを含むものがあります。 これで、画面の下部に、ページの写真が表示されたウィンドウが表示されました。 右上隅にグラフが表示され、各描画機能にかかる合計時間を示します。 左側には、ページ要素のレンダリングのシーケンスと各要素に費やされた時間が記載されたタイムラインがあります。
タイムラインをスクロールすると、ページのこのような長いレンダリングの主な原因は、影付きのメッセージのリストのコンテナであることがわかりました。 この要素は、総ページレンダリング時間の約45％を要します。
box-shadowを通常の境界線に置き換えてページを書き直した後、レンダリングに費やす時間が45％から6.5％に短縮されたこと、そして別のSkia関数が使用されていることがわかりました。
「連続ページの再描画を有効にする」モードで最適化されたページを表示した後、レンダリングの加速も確認されました。
多くの人にとって、ボックスシャドウの問題は明らかであり、devtoolsを使用してページのスタイルを変更するだけで見つけることができます。 しかし、この記事では、代替ツールの使用方法についてお話ししたかったのです。 それらを使用して、ページに要素が描画される順序とその所要時間を理解する方法。
このツールには、以前説明したビデオで詳しく説明されているように、この記事では説明しなかったはるかに優れた機能があります。
ブラウザで行われるプロセスを理解することは、Webアプリケーションの効果的な最適化に必要な非常に重要な知識です。 しかし、最適化のためには、この最適化が与えた加速を測定し、問題の原因を理解できるツールも必要です。
「パフォーマンスに関して言えば、ありそうもない」 パフォーマンスを測定しないと、変更がプログラムを助けたのか、傷つけたのかを確実に知ることはできません。」
スティーブマッコネル「完璧なコード」第2回。 エディション、579ページ「コード最適化戦略」
レンダリングが最も難しい要素を特定することは、Webアプリケーションを最適化する上で重要なステップです。 Chromeの新機能で得られた知識は、レンダリングのボトルネックをデバッグして見つけるだけでなく、ページコンポーネントがストリーム全体のレンダリングプロセスに与える影響を理解するのにも役立ちます。 このツールの他の機能については、次の記事で説明します。