Chrome開発ツールを使用してパフォーマンスのボトルネックを見つける方法

序章

ソフトウェア開発のキャリアを進めるにつれて、機能するコードを書くこと以外の懸念が生じる可能性があります。 Web開発の世界では、機能的なソフトウェアを構築するだけでなく、最小限のリソースを使用しながら、必要なエクスペリエンスをシームレスに提供できるように、パフォーマンスを向上させることが適切になります。

通常、さまざまなパラメータをシミュレートおよび測定するツールがないと、アプリケーションのリソース消費プロパティについて予測を行うことができないため、これは非常に大きな作業になります。

この記事では、これらのツールの1つであるChromeデベロッパーツールについて説明します。具体的には、監査およびパフォーマンスタブの便利さを調べて、Webアプリケーションを評価し、パフォーマンスの問題を発見します。

これを実践的な試験にするために、Webサイトでパフォーマンスの問題を探し出し、それらを解決するためのさまざまな手法をテストします。このチュートリアルでは、 Scottch.io Webサイトについて説明しますが、これらの手順はどのWebサイトにも適用できます。

前提条件

このチュートリアルに従うために、GoogleChromeブラウザがコンピュータにインストールされています。

ステップ1—ブラウザの準備

WebサイトまたはWebアプリケーションのパフォーマンスを向上させる場合、考慮すべき2つの主要な側面があります。

負荷パフォーマンス
実行時のパフォーマンス

このチュートリアルでは、ロードパフォーマンスに焦点を当てます。 ロードパフォーマンスは、ページがロードされているときのページのパフォーマンスを指します。主な目的は、アプリケーションの速度と全体的なユーザーエクスペリエンスに影響を与えるパフォーマンスの問題を特定することです。

ロードパフォーマンスのテストを開始するには、監査を設定することから始めます。

Chromeブラウザを起動し、macOSではCOMMAND + SHIFT + Nを、WindowsまたはLinuxではCTRL + SHIFT + Nを押して、シークレットモードでタブを開きます。シークレットブラウザが開いたら、テストするWebサイトに移動します。

次に、macOSではCOMMAND + OPTION + Iを、WindowsまたはLinuxではCTRL + SHIFT + Iを押して、DevToolsを開きます。 DevToolsコンソールの場所を変更する場合は、ツールバーの3つの縦のドットをクリックして、ドック側オプションから選択します。

コンソールの配置に満足したら、Auditsタブに切り替えます。このツールを使用して、後続のアプリケーションの変更を測定するためのベースラインを作成し、どの変更がアプリケーションを改善するかについての洞察を受け取ります。

注： [監査]タブは、その他のパネル矢印ボタンの後ろに隠れている場合があります。

ここでの主な目的は、Scotchのパフォーマンスのボトルネックを特定し、パフォーマンスを向上させるために最適化することです。ソフトウェアエンジニアリングのボトルネックは、アプリケーションの容量が単一のコンポーネントによって制限されている状況を表しています。

次のステップでは、監査を実行してパフォーマンスのボトルネックを探します。

ステップ2—監査の実行

監査を実行するときは、Lighthouseというツールを使用します。 Lighthouseは、パフォーマンス、アクセシビリティ、プログレッシブWeb機能などの分野で、あらゆるWebページの品質を向上させるためのオープンソースの自動化ツールです。

ChromeDevToolsのAudits タブで、監査ツールを構成しましょう。次の設定が表示されます。

端末

これにより、ユーザーエージェントをモバイルオプションとデスクトップオプションの間で切り替えることができます。 2018年第3四半期の時点でWebトラフィックの半分以上がモバイルデバイスによって生成されているため、モバイルでScott.ioを監査します。

監査

この設定により、評価および改善するアプリケーションの品質を選択できます。この場合、パフォーマンスが主な懸念事項であるため、他のすべてのオプションのチェックを外すことができます。

スロットル

このオプションを使用すると、モバイルデバイスでのブラウジングの状態をシミュレートできます。 Simulated Fast 3G、4x CPUSlowdownオプションを使用します。これは実際には監査中に調整されませんが、モバイル条件下でページが読み込まれるまでにかかる時間を計算するのに役立ちます。

ストレージをクリアする

これにより、テストしたページのキャッシュされたすべてのデータとリソースをクリアして、初めての訪問者がサイトをどのように体験するかを監査できます。まだチェックされていない場合は、このオプションをチェックしてください。

上記のように監査を構成した後、レポートの生成をクリックし、サイトのパフォーマンスの詳細なレポートが準備されるまで待ちます。

ステップ3—監査レポートの分析

監査が完了すると、レポートは次のようになります。

右上の円内の数字は、サイトの全体的なパフォーマンススコアを1〜100のスケールで示しています。現在、 55 があります。これは、スコアとパフォーマンスを向上させるために提供された提案とともに、改善の可能性があることを示しています。レポートをセクションに分割し、個別に分析してみましょう。

メトリクスセクションでは、サイトのパフォーマンスのさまざまな側面に関する定量的な洞察を見つけることができます。

Metrics セクションのすぐ下には、最初のクエリの時点から完全に読み込まれるまでのページのさまざまなUI状態を示すスクリーンショットのグループがあります。

診断セクションには、通常、Webページの読み込み時間を決定する要因を示す追加のパフォーマンス情報が表示されます。

最後に、合格した監査セクションでは、Webページによって合格したパフォーマンスチェックを強調しています。

監査を分析したので、対処する必要のある問題がわかりました。

ステップ4—メトリクスセクションの問題への対処

この例では、5つのパフォーマンスの問題が強調されています。このステップでは、可能な修正について説明します。

最初の意味のあるペイント

First Meaningful Paint は、ページの主要なコンテンツが視覚的に利用可能になるタイミングを示します。監査によると、メインコンテンツが表示されるまでに約3.4秒かかります。これは、トレースの表示ボタンをクリックして確認できます。これにより、パフォーマンスタブに移動し、ロード期間中のさまざまなUI状態を確認して、特定の時間に何が発生するかを確認できます。

この時点で、ページのコンテンツが表示されることに注意してください。

これを改善するには、ページ/アプリケーション全体のクリティカルレンダリングパスを最適化する必要があります。これは、より良いエクスペリエンスを作成し、パフォーマンスを向上させるために、ユーザーの希望に応じてコンテンツの表示を優先することを意味します。これは、クリティカルリソースの数、クリティカルパスの長さ、およびクリティカルバイトの数を減らすことで実行できます。

スピードインデックス

Speed Index は、ページコンテンツが視覚的に表示される速度を示します。パフォーマンスタブに表示されているように、これには約7.2秒かかります。

以前に調べたメトリックのように、これを修正する1つの方法は、重要なレンダリングパスを最適化することです。 2番目の方法は、コンテンツの効率を最適化することです。これには、不要なダウンロードを手動で取り除き、圧縮による転送エンコーディングを最適化し、変更されていないリソースの再ダウンロードを防ぐために可能な限りキャッシュすることが含まれます。

最初のCPUアイドル

FirstInteractiveとも呼ばれるFirstCPU Idle は、ページが最小限のインタラクティブになると通知します（CPUは、クリックやスワイプなどのユーザー入力を処理するのに十分なアイドル状態です）。。監査から、これには約6.5秒かかります。この値を最小にすることは常に勝利です。

これを解決するには、スピードインデックスと同じ手順を実行する必要があります。

インタラクティブな時間

インタラクティブまでの時間は、ページが完全にインタラクティブになるまでにかかる時間を示します。この例の監査では、このメトリックの6.9秒が明らかになります。このコンテキストでの双方向性は、次の点を説明します。

このページには役立つコンテンツが表示されています。
イベントハンドラーは、ページ上で最も表示される要素に登録されています。
このページは、50ミリ秒以内にユーザーの操作に応答します。

これを修正するには、ページの読み込み中に発生する不要なJavaScript作業を延期または削除する必要があります。これは通常、コードの分割と遅延読み込み、圧縮、縮小、および未使用のコードとキャッシュの削除を通じて、ユーザーが必要とするコードのみを送信することで実現できます。コードの最適化について詳しくは、こちらをご覧ください。

推定入力レイテンシ

推定入力遅延は、ユーザー入力に対するアプリケーションの応答性を表します。監査では、このメトリックに約170ミリ秒が記録されます。アプリケーションは通常、ユーザー入力に応答するために 100ミリ秒を持ちますが、Lighthouseのターゲットは 50ミリ秒です。この不一致の理由は、Lighthouseがプロキシメトリック[ X218X]。これは、このメトリックを直接測定するのではなく、評価するためのメインスレッドの可用性です。

指定された時間より長くかかると、アプリが遅延していると認識される場合があります。推定入力レイテンシの詳細については、こちらをご覧ください。

このメトリックを改善するために、サービスワーカーを使用していくつかの計算を実行し、メインスレッドを解放することができます。もう1つの便利な方法は、CSSセレクターをリファクタリングして、実行する計算が少なくなるようにすることです。

ステップ5—機会セクションでの問題への対処

Opportunities セクションには、パフォーマンスを向上させることができる最適化がリストされています。

通常、Webページが読み込まれると、データを送受信するために他のオリジンに接続します。この場合のようにパフォーマンスを向上させるには、レンダリングプロセスの早い段階でそのようなオリジンへの接続を確立するようにブラウザに通知することをお勧めします。これにより、DNSルックアップ、リダイレクト、および数回のトリップの解決を待機する時間を短縮できます。クライアントが応答を受信するまで前後します。

これを修正するには、以下に示すように、リンクタグにrel属性を追加することで、このようなリソースを使用する意図をブラウザに通知できます。

<link rel="preconnect" href="https://scotchresources.com">

安全な接続では、これにはまだ時間がかかる可能性があるため、10秒以内に使用する必要があります。そうしないと、ブラウザが自動的に接続を閉じ、初期の接続作業がすべて無駄になります。

結論

Auditツールを使用したScotch.ioのパフォーマンスレポートを正常に受信し、特定されたボトルネックの解決策を検討しました。

Load は、一瞬ではありません。これは、1つのメトリックで完全にキャプチャできるエクスペリエンスではありません。ロードエクスペリエンス中には、ユーザーがそれを「速い」と「遅い」のどちらとして認識するかに影響を与える可能性のある複数の瞬間があります。

パフォーマンスは長い列車のようなもので、複数の別々のコーチが似ていて目的が統一されています。テストでは、アプリケーションの速度を累積的に向上させ、エンドユーザーのエクスペリエンスを向上させる小さなメリットに注意を払う必要があります。

さらに読むために、GoogleDevelopersサイトのWebFundamentalsセクションは素晴らしいリソースです。