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

Kayce Basques
Sofia Emelianova
Sofia Emelianova
GitHub

概要

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

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

など、さまざまな指標を把握できます。

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

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

チュートリアルの目標

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

この記事を読み進めるか、または下にあるこのチュートリアルのビデオ版をご覧ください。

前提条件

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

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

はじめに

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

猫のトニー。

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

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

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

設定

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

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

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

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

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

    [デモ] タブ。

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

    DevTools とデモ。

ベースラインを確立する

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

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

    Lighthouse パネル。

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

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

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

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

レポートのエラーの処理

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

エラーのあるレポート。

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

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

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

指標

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

[指標] セクション。

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

スクリーンショット

次に、ページの読み込み時の様子を示すスクリーンショットの一覧を示します。

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

最適化

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

[最適化] セクション。

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

テキスト圧縮の機会の詳細。

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

診断

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

[診断] セクション。

監査に合格した

[合格した監査] セクションには、サイトが正しく機能している項目が表示されます。クリックしてセクションを開きます。

[Passed audits] セクション。

ステップ 2: テスト

Lighthouse レポートの [改善できる項目] セクションには、ページのパフォーマンスを改善する方法に関するヒントが表示されます。このセクションでは、コードベースに推奨される変更を実装し、変更ごとにサイトを監査して、サイト速度への影響を測定します。

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

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

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

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

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

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

[サイズ] セルには 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(compression()) は app.use(express.static('build')) の前に配置してください。

    server.js の編集。

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

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

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

    [サイズ] 列に、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」と入力し、[Show 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. [ネットワーク] タブをクリックし、コマンド メニューをもう一度開きます。

  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] セクションには、節約の余地がわずかながら示されていますが、[Diagnostics] セクションまでスクロールすると、最大のボトルネックとしてメインスレッド アクティビティの過剰が示されています。

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

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

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

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

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

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

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

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

トレースの [概要] セクション。

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

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

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

    [タイミング] セクション。

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

  2. [タイミング] をもう一度クリックして、そのセクションを閉じます。

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

    メイン セクション。

    この例では、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 までツイートしてください。