Lighthouse: ウェブサイトの速度を最適化する

Kayce Basques
Sofia Emelianova
Sofia Emelianova
GitHub

概要

Lighthouse パネルを使うと、ウェブサイトを包括的に監査できます。[Lighthouse] パネルでは、ウェブサイトに関する次の分析情報を確認できるレポートが生成されます。

  • パフォーマンス
  • ユーザー補助
  • ベスト プラクティス
  • SEO

その他多くの指標

次のチュートリアルでは、Chrome DevTools で Lighthouse の使用を開始する方法について説明します。

Lighthouse でウェブサイトの品質を高めるその他の方法については、Lighthouse のドキュメントをご覧ください。

チュートリアルの目標

このチュートリアルでは、Chrome DevTools を使用してウェブサイトの読み込みを高速化する方法について説明します。

続いて、このチュートリアルの動画をご覧ください。

前提条件

このウェブ開発入門クラスで学ぶ内容に似た、基本的なウェブ開発の経験が必要です。

負荷のパフォーマンスに関する知識は必要ありません。

はじめに

Tony と申します。トニーは猫界で非常に有名です。また、ファンが自分の好きな食べ物を紹介できるウェブサイトも作成しています。ファンはサイトを気に入っていますが、サイトの読み込みが遅いという苦情が絶えません。トニーからサイトの速度を上げるように頼まれました。

猫のトニー。

ステップ 1: サイトを監査する

サイトの読み込みパフォーマンスを改善する際は、必ず監査から始めてください。監査には 2 つの重要な機能があります。

  • これにより、その後の変化を測定するためのベースラインが作成されます。
  • 最も効果的な変更に関する実用的なヒントが提供されます。

設定

まず、トニーのウェブサイトの新しい作業環境を設定してから、後で変更できるようにします。

  1. Glitch でウェブサイトのプロジェクトをリミックスします。新しいプロジェクトがタブで開きます。このタブはエディタタブと呼ばれます。

    元のソースと、[リミックス] をクリックした後のエディタ タブ。

    プロジェクト名が tony からランダムに生成された名前に変わります。これで、コードの編集可能なコピーが作成されました。後でこのコードに変更を加えます。

  2. エディタタブの下部にある [プレビュー] > [新しいウィンドウでプレビュー] をクリックします。新しいタブでデモが開きます。このタブはデモタブと呼ばれます。サイトの読み込みに時間がかかることがあります。

    [デモ] タブ。

  3. デモとともに DevTools を開く。

    DevTools とデモ。

ベースラインを確立する

ベースラインは、パフォーマンスを改善する前のサイトのパフォーマンスの記録です。

  1. [Lighthouse] パネルを開きます。 [その他] パネルの背後に隠れている場合があります。

    Lighthouse パネル。

  2. Lighthouse レポートの設定をスクリーンショットの設定と一致させます。各オプションの説明は次のとおりです。

    • [ストレージを消去] をオンにします。このチェックボックスをオンにすると、すべての監査の前に、ページに関連付けられているストレージがすべて消去されます。サイトを初めて訪問したユーザーの行動を監査したい場合は、この設定をオンのままにします。再訪問時のエクスペリエンスを表示する場合は、この設定を無効にします。
    • JS サンプリングを有効にする。このオプションはデフォルトでオフになっています。有効にすると、パフォーマンス トレースには詳細な JavaScript 呼び出しスタックが追加されますが、レポートの生成が遅くなる可能性があります。トレースには、Lighthouse レポートの生成後に、 ツールメニュー > [View Unthrottled Trace] からアクセスできます。 JS サンプリングなし（左）と JS サンプリングあり（右）のパフォーマンス トレース。
    • スロットリングのシミュレーション（デフォルト）: 。このオプションは、モバイル デバイスでの一般的なブラウジング環境をシミュレートします。「シミュレーション」と呼ばれるのは、監査プロセス中に Lighthouse が実際にスロットリングされないためです。代わりに、モバイル環境でのページの読み込み時間を推定します。一方、DevTools のスロットリング（高度）の設定では、実際には CPU とネットワークがスロットリングされますが、監査プロセスが長くなるというトレードオフがあります。
    • [モード] > [ナビゲーション（デフォルト）] に移動します。このモードでは 1 回のページ読み込みが分析されるため、このチュートリアルではこれを必要とします。詳細については、3 つのモードをご覧ください。
    • [デバイス] > [モバイル] の順に選択します。[モバイル] オプションを選択すると、ユーザー エージェント文字列が変更され、モバイル ビューポートがシミュレートされます。デスクトップ オプションでは、モバイルでの変更が無効になります。
    • [カテゴリ] > [ パフォーマンス] の順に選択します。有効にしたカテゴリが 1 つの場合、Lighthouse は、対応する一連の監査のみを含むレポートを生成します。他のカテゴリは、表示される最適化案の種類を確認したい場合は有効にしたままにしておきます。関連性のないカテゴリを無効にすると、監査プロセスが若干早くなります。

  3. [ページ読み込みを分析] をクリックします。10～30 秒ほど経つと、[Lighthouse] パネルにサイトのパフォーマンスのレポートが表示されます。

    サイトのパフォーマンスに関する Lighthouse レポート。

レポートのエラーの処理

Lighthouse レポートでエラーが発生した場合は、他のタブを開かずにシークレット ウィンドウからデモタブを実行してみてください。これにより、クリーンな状態から Chrome を実行できます。特に Chrome 拡張機能は監査プロセスを妨げる可能性があります。

エラーのあるレポート。

レポートについて理解する

レポートの上部にある数値は、サイトの全体的なパフォーマンス スコアです。後でコードを変更すると、この数は増加します。スコアが高いほどパフォーマンスが優れていることを意味します。

全体的なパフォーマンス スコア。

指標

[指標] セクションまで下にスクロールし、[表示を展開] をクリックします。指標のドキュメントを読むには、[詳細...] をクリックします。

[Metrics] セクション。

このセクションでは、サイトのパフォーマンスを定量的に測定します。各指標は、パフォーマンスの異なる側面に関する分析情報を提供します。たとえば、コンテンツの初回ペイントは、コンテンツが画面に最初にペイントされたときを示します。これは、ユーザーがページの読み込みを認識する際の重要なマイルストーンです。一方、インタラクティブになるまでの時間は、ページがユーザー操作に対応できる状態になったことを示します。

スクリーンショット

次は、ページの読み込み時にどのように表示されるかを示す一連のスクリーンショットです。

読み込み中のページのスクリーンショット。

最適化

次に、改善できる項目セクションがあります。このセクションには、この特定のページの読み込みパフォーマンスを改善する方法に関する具体的なヒントが記載されています。

[最適化] セクション。

最適化案をクリックすると詳細を確認できます。

テキスト圧縮の可能性についての詳細。

[詳細...] をクリックすると、機会が重要な理由と、問題を解決するための具体的な推奨事項に関するドキュメントが表示されます。

診断

[診断] セクションには、ページの読み込み時間に影響する要因に関する詳細情報が表示されます。

[診断] セクション。

監査に合格した

[合格した監査] セクションには、サイトの評価が表示されます。クリックしてセクションを展開します。

[Passed audits] セクション。

ステップ 2: テスト

Lighthouse レポートの [Opportunities]（最適化）セクションで、ページのパフォーマンスを向上させるためのヒントを確認できます。このセクションでは、コードベースに推奨される変更を実装し、変更ごとにサイトを監査して、サイト速度への影響を測定します。

テキスト圧縮を有効にする

レポートによると、ページのパフォーマンスを改善するための最適化案として、テキスト圧縮を有効にすることが示されています。

テキスト圧縮とは、テキスト ファイルをネットワーク経由で送信する前に、そのサイズを小さく（圧縮）することです。メールに添付する前にフォルダを圧縮してサイズを小さくするようなものです。

圧縮を有効にする前に、テキスト リソースが圧縮されているかどうかを手動で確認する方法は次のとおりです。

[ネットワーク] パネルを開き、 [設定] > [大きなリクエスト行を使用する] をオンにします。

ネットワーク パネルの [サイズ] 列に、サイズの大きいリクエスト行が表示されている。

[サイズ] セルには 2 つの値が表示されます。上部の値は、ダウンロードされたリソースのサイズです。下側の値は、未圧縮リソースのサイズです。2 つの値が同じ場合、リソースはネットワーク経由で送信されるときに圧縮されません。この例では、bundle.js の上限と下限の値はどちらも 1.4 MB です。

リソースの HTTP ヘッダーを調べて、圧縮を確認することもできます。

  1. bundle.js をクリックし、[ヘッダー] タブを開きます。

    [ヘッダー] タブ。

  2. [Response Headers] セクションで content-encoding ヘッダーを検索します。bundle.js は圧縮されていません。これは表示されないはずです。リソースが圧縮されている場合、このヘッダーは通常、gzip、deflate、または br に設定されます。これらの値の説明については、ディレクティブをご覧ください。

説明はこれで十分です。変更を加えましょう。次のコード行を追加して、テキスト圧縮を有効にします。

  1. エディタタブで server.js を開き、次の 2 行（ハイライト表示）を追加します。

    ...
const fs = require('fs');
const compression = require('compression');

app.use(compression());
app.use(express.static('build'));
...

  2. app.use(express.static('build')) の前に app.use(compression()) を配置してください。

    server.js の編集。

  3. Glitch がサイトの新しいビルドをデプロイするまで待ちます。左下にハッピーな絵文字が表示されれば、デプロイに成功しています。

前に学習したワークフローを使用して、圧縮が機能していることを手動で確認します。

  1. [デモ] タブに戻り、ページを再読み込みします。

    [Size] 列には、テキスト リソース（bundle.js など）について 2 つの異なる値が表示されます。bundle.js の 269 KB の最上位の値はネットワーク経由で送信されたファイルのサイズで、1.4 MB の最下位の値は圧縮されていないファイルサイズです。

    [サイズ] 列に、テキスト リソースの 2 つの異なる値が表示されるようになりました。

  2. bundle.js の [レスポンス ヘッダー] セクションに content-encoding: gzip ヘッダーが追加されます。

    [レスポンス ヘッダー] セクションに content-encoding ヘッダーが追加されました。

ページで Lighthouse レポートを再度実行し、テキスト圧縮がページの読み込みパフォーマンスに及ぼす影響を測定します。

  1. [Lighthouse] パネルを開き、上部にあるアクションバーの 追加する [監査を実行...] をクリックします。

    [監査を実行] ボタン。

  2. 設定は前回と同じにして、[ページ読み込みを分析] をクリックします。

    テキスト圧縮を有効にした後の Lighthouse レポート。

おめでとうございます！それは進歩ですね。全体的なパフォーマンス スコアが高くなっているはずです。これは、サイトの読み込み速度が上がっていることを意味します。

実際のテキスト圧縮

ほとんどのサーバーには、圧縮を有効にするためのこのような簡単な修正があります。テキストの圧縮に使用するサーバーの構成方法を調べてみてください。

画像のサイズを変更する

新しいレポートによると、画像の適切なサイズ調整も大きなチャンスです。

画像のサイズを変更すると、画像のファイルサイズが小さくなり、読み込み時間が短縮されます。ユーザーが 500 ピクセル幅のモバイル デバイスの画面で画像を表示している場合、1, 500 ピクセル幅の画像を送信しても意味がありません。送信する画像の幅は 500 ピクセル以下にすることをおすすめします。

  1. レポートで [適切なサイズの画像] をクリックして、サイズ変更が必要な画像を確認します。4 枚の画像すべてが必要以上に大きいようです。

    「適切なサイズの画像を使用」の改善案の詳細

  2. エディタタブに戻り、src/model.js を開きます。

  3. const dir = 'big' を const dir = 'small' に置き換えます。 このディレクトリには、サイズ変更された同じ画像のコピーが格納されます。

  4. ページを再度監査して、この変更が読み込みパフォーマンスにどのように影響するかを確認します。

    画像のサイズ変更後の Lighthouse レポート。

この変更は、全体的なパフォーマンス スコアにわずかな影響しか及ぼしていないようです。ただし、このスコアでは、ユーザーが節約できるネットワーク データの量が明確に示されません。以前の写真の合計サイズは約 6.1 MB でしたが、現在は約 633 KB にまで圧縮されています。これは、[ネットワーク] パネルの下部にあるステータスバーで確認できます。

画像のサイズ変更前後の転送データ量。

現実世界での画像のサイズ変更

小規模なアプリの場合は、このような 1 回限りのサイズ変更で十分な場合があります。ただし、大規模なアプリの場合、これは明らかにスケーラブルではありません。大規模なアプリで画像を管理するための戦略は次のとおりです。

  • ビルドプロセス中にイメージのサイズを変更します。
  • ビルドプロセス中に各画像の複数のサイズを作成し、コードで srcset を使用します。実行時に、ブラウザが実行されているデバイスに最適なサイズを選択します。相対的なサイズの画像をご覧ください。
  • リクエスト時に画像を動的にサイズ変更できる画像 CDN を使用する。
  • 少なくとも各画像を最適化してください。多くの場合、これによって大幅な費用削減が可能になります。最適化とは、画像ファイルをサイズを小さくする特別なプログラムで画像を実行することです。その他のヒントについては、重要な画像の最適化をご覧ください。

レンダリングを妨げるリソースの除外

最新のレポートによると、レンダリングをブロックするリソースの削除が最大の改善ポイントとなっています。

レンダリング ブロック リソースとは、ブラウザがページを表示する前にダウンロード、解析、実行する必要がある外部の JavaScript ファイルまたは CSS ファイルです。ページを適切に表示するために必要なコア CSS コードと JavaScript コードのみを実行することが目標です。

最初のタスクは、ページの読み込み時に実行する必要のないコードを見つけることです。

  1. [レンダリングを妨げるリソースを除外] をクリックして、ブロックしているリソース（lodash.js と jquery.js）を確認します。

    「レンダリングをブロックするリソースを減らす」改善案の詳細。

  2. オペレーティング システムに応じて、次のキーを押してコマンド メニューを開きます。

    • Mac の場合: Command+Shift+P
    • Windows、Linux、ChromeOS: Ctrl+Shift+P

  3. 「Coverage」と入力して [一致率を表示] を選択します。

    Lighthouse パネルからコマンド メニューを開く。

    ドロワーに [カバレッジ] タブが開きます。

    [カバー率] タブ。

  4. [] [再読み込み] をクリックします。[カバレッジ] タブには、ページの読み込み中に bundle.js、jquery.js、lodash.js で実行されているコードの量の概要が表示されます。

    カバレッジ レポート。

    このスクリーンショットでは、jQuery ファイルと Lodash ファイルの約 74% と 30% が使用されていないことがわかります。

  5. [jquery.js] 行をクリックします。DevTools で [ソース] パネルにファイルが開きます。横に緑色のバーが表示されている場合は、実行されているコード行を示しています。コード行の横にある赤いバーは、そのコードが実行されず、ページの読み込みで必要ないことを意味します。

    [ソース] パネルで jQuery ファイルを表示しています。

  6. jQuery コードを少しスクロールします。「実行」される行の一部は、実際にはコメントにすぎません。コメントを削除する圧縮ツールでこのコードを実行することも、このファイルのサイズを削減する方法の 1 つです。

つまり、独自のコードを使用している場合は、[Coverage] タブを使用してコードを 1 行ずつ分析し、ページの読み込みに必要なコードのみを配信できます。

ページの読み込みに jquery.js ファイルと lodash.js ファイルは必要ですか？[リクエストのブロック] タブでは、リソースが使用できない場合に何が起こるかを確認できます。

  1. [Network] タブをクリックし、コマンド メニューをもう一度開きます。

  2. 「blocking」と入力し、[リクエストのブロックを表示] を選択します。[リクエストのブロック] タブが開きます。

    [リクエストのブロック] タブ。

  3. 追加する [パターンを追加] をクリックし、テキスト ボックスに /libs/* と入力して Enter キーを押して確定します。

    「libs」ディレクトリへのリクエストをブロックするパターンを追加。

  4. ページを再読み込みします。jQuery と Lodash のリクエストは赤色で、ブロックされたことを示しています。ページは読み込まれ、インタラクティブであるため、これらのリソースはまったく必要ないように見えます。

    [ネットワーク] パネルに、リクエストがブロックされたことが示されます。

  5. [削除] をタップします。 パターンをすべて削除] をクリックして、/libs/* ブロック パターンを削除します。

一般に、[リクエストのブロック] タブは、特定のリソースが利用できないときのページの動作をシミュレートする場合に便利です。

次に、コードからこれらのファイルへの参照を削除し、ページを再度監査します。

  1. エディタタブに戻り、template.html を開きます。

  2. 対応する <script> タグを削除します。

    <head>
    ...
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <script src="/libs/lodash.js"></script>
    <script src="/libs/jquery.js"></script>
    <title>Tony's Favorite Foods</title>
</head>

  3. サイトが再ビルドされて再デプロイされるまで待ちます。

  4. [Lighthouse] パネルからページを再度監査します。全体的なスコアが再び向上しているはずです。

    レンダリングをブロックするリソースを削除した後の Lighthouse レポート

現実世界の重要なレンダリング パスを最適化する

クリティカル レンダリング パスとは、ページの読み込みに必要なコードを指します。一般に、ページの読み込み時に重要なコードのみを送信し、残りはすべて遅延読み込みすることで、ページの読み込みを高速化できます。

  • 完全に削除できるスクリプトを見つけることはほとんどありませんが、多くのスクリプトはページの読み込み中にリクエストする必要はなく、非同期でリクエストできることがよくあります。非同期または遅延の使用をご覧ください。
  • フレームワークを使用している場合は、本番環境モードがあるかどうかを確認します。このモードでは、クリティカル レンダリングをブロックしている不要なコードを削除するために、ツリー シェイキングなどの機能が使用される場合があります。

メインスレッドの処理を減らす

最新のレポートの [Opportunities] セクションには、少額のコスト削減の可能性が示されていますが、[診断] セクションまで下にスクロールすると、最大のボトルネックはメインスレッド アクティビティが多すぎることがわかります。

メイン スレッドでは、HTML、CSS、JavaScript の解析と実行など、ページの表示に必要なほとんどの処理がブラウザによって行われます。

目標は、[パフォーマンス] パネルを使用して、ページの読み込み中にメインスレッドが行っている作業を分析し、不要な作業を遅らせたり削除したりする方法を見つけることです。

  1. [パフォーマンス] > 設定] をタップします。 [キャプチャ設定] を開き、[ネットワーク] を [低速 3G]、[CPU] を [6 倍減速] に設定します。

    [パフォーマンス] パネルで CPU とネットワークのスロットリングを設定する

    通常、モバイル デバイスにはノートパソコンやデスクトップよりも多くのハードウェア制約があるため、これらの設定を使用すると、低性能のデバイスを使用している場合と同様にページが読み込まれます。

  2. [] 再読み込みをクリックします。DevTools はページを再読み込みし、ページを読み込むために必要なすべての処理を可視化します。このビジュアリゼーションを「トレース」と呼びます。

    パフォーマンス パネルのページ読み込みのトレース。

トレースには、左から右に時系列でアクティビティが表示されます。上部の FPS、CPU、NET のグラフには、フレームレート、CPU アクティビティ、ネットワーク アクティビティの概要が表示されます。

トレースの [Overview] セクション

[概要] セクションに黄色の壁が表示されている場合は、CPU がスクリプト アクティビティで完全にビジー状態であることを意味します。これは、JavaScript の処理を減らすことでページの読み込みを高速化できる可能性があることを示唆しています。

トレースを確認して、JavaScript の処理を減らす方法を探します。

  1. [タイミング] セクションをクリックして展開します。

    タイミングのセクション。

    React のユーザー タイミングの測定値が多数あります。Tony さんのアプリは React の開発モードを使用しているようです。React の本番環境モードに切り替えると、パフォーマンスが向上する可能性があります。

  2. もう一度 [タイミング] をクリックすると、セクションが閉じます。

  3. [Main] セクションを参照します。このセクションには、左から右に、メインスレッド アクティビティの時系列ログが表示されます。Y 軸（上から下）には、イベントが発生した理由が示されます。

    メイン セクション。

    この例では、Evaluate Script イベントによって (anonymous) 関数が実行され、__webpack__require__ が実行され、./src/index.jsx が実行されました。

  4. [Main] セクションの一番下までスクロールします。フレームワークを使用する場合、上位アクティビティのほとんどはフレームワークによって発生するため、通常は制御できません。通常、アプリが原因のアクティビティは下部にあります。

    mineBitcoin のアクティビティ。

    このアプリでは、App という関数によって mineBitcoin 関数が頻繁に呼び出されているようです。トニーはファンのデバイスを使って暗号通貨をマイニングしているようです。

  5. 下部の [ボトムアップ] タブを開きます。このタブには、最も時間がかかったアクティビティの詳細が表示されます。[ボトムアップ] セクションに何も表示されない場合は、[メイン] セクションのラベルをクリックします。

    [ボトムアップ] タブ。

    [ボトムアップ] セクションには、現在選択しているアクティビティまたはアクティビティ グループの情報のみが表示されます。たとえば、mineBitcoin アクティビティのいずれかをクリックすると、[ボトムアップ] セクションにはそのアクティビティの情報のみが表示されます。

    [自己時間] 列には、各アクティビティに直接費やされた時間が表示されます。この場合、メインスレッドの時間の約 82% が mineBitcoin 関数に費やされています。

本番環境モードを使用して JavaScript アクティビティを減らすと、ページの読み込みが速くなるかどうかを確認しましょう。本番環境モードで開始します。

  1. [エディタ] タブで webpack.config.js を開きます。
  2. "mode":"development" を "mode":"production" に変更します。
  3. 新しいビルドがデプロイされるまで待ちます。

  4. ページを再度監査します。

    本番環境モードを使用するように webpack を構成した後の Lighthouse レポート。

mineBitcoin の呼び出しを削除して、JavaScript アクティビティを削減します。

  1. [エディタ] タブで src/App.jsx を開きます。
  2. constructor の this.mineBitcoin(1500) の呼び出しをコメントアウトします。
  3. 新しいビルドがデプロイされるまで待ちます。
  4. ページを再度監査します。

不要な JavaScript 処理を削除した後の Lighthouse レポート。

いつものように、Largest Contentful Paint 指標や Cumulative Layout Shift 指標を減らすなどの対応が必要です。

実際のメインスレッドでの処理を減らす

一般的に、サイトの読み込み時に実行されるアクティビティを把握し、不要なアクティビティを削除する方法を見つけるには、[パフォーマンス] パネルを使用するのが最も一般的です。

console.log() に近いアプローチを希望する場合は、User Timing API を使用して、アプリのライフサイクルの特定のフェーズを任意にマークアップし、各フェーズの所要時間をトラッキングできます。

概要

  • サイトの読み込みパフォーマンスの最適化に着手する際は、常に監査から始めてください。監査によってベースラインが確立され、改善方法のヒントが提供されます。
  • 一度に 1 つの変更を行い、変更ごとにページを監査して、その変更がパフォーマンスにどのように影響するかを確認します。

次のステップ

ご自身のサイトの監査を実施しましょう。レポートの解釈や読み込みパフォーマンスの改善方法についてサポートが必要な場合は、DevTools コミュニティからサポートを受ける方法をご確認ください。

  • このドキュメントに関するバグは、developer.chrome.com リポジトリに報告してください。
  • DevTools に関するバグレポートは、Chromium のバグで報告してください。
  • 機能と変更点については、メーリング リストで議論してください。サポートに関する質問にはメーリング リストを使用しないでください。代わりに Stack Overflow を使用してください。
  • DevTools の使用方法については、Stack Overflow で一般的なヘルプをご覧ください。バグ リクエストを提出するには、常に Chromium バグを使用します。
  • @ChromeDevTools までツイートしてください。