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

Kayce Basques
Sofia Emelianova
Sofia Emelianova
GitHub

概要

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

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

その他多くの指標

以下のチュートリアルは、Chrome DevTools で Lighthouse を使用する際の参考になります。

Lighthouse を使用してウェブサイトの品質を改善するその他の方法について詳しくは、Lighthouse のドキュメントをご覧ください。

チュートリアルの目標

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

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

この動画は Chrome 68 で作成されました。

前提条件

このコースで学習する内容と同様の、基本的なウェブ開発の経験が必要です。 この Introduction to Web Development クラスを受講してください。

読み込みのパフォーマンスについて知っている必要はありません。

はじめに

Tony と申します。トニーは猫の社会で非常に有名です。彼は、 ウェブサイトを作成し、ファンがお気に入りのコンテンツを あります。ファンはサイトを気に入っていますが、YouTube が サイトの読み込みが遅い場合トニーからサイトの速度を上げるように頼まれました。

<ph type="x-smartling-placeholder">
</ph> 猫のトニー。
をご覧ください。

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

サイトの読み込みパフォーマンスを改善する際は、必ず最初に監査を行います。監査には 2 つの重要な機能があります。

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

設定

まず、移行のために新しい作業環境を設定する必要があります。 Tony のウェブサイト（変更を加えるため） 使用できます。

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

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

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

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

    [demo] タブ。

  3. デモと一緒に DevTools を開きます。

    DevTools とデモ。

ベースラインを確立する

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

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

    Lighthouse パネル。

  2. Lighthouse のレポート設定とスクリーンショット設定を一致させます。ここでは、Chronicle の さまざまなオプションがあります。

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

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

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

レポートエラーの処理

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

エラーのあるレポート。

レポートの見方

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

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

指標

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

[指標] セクション。

このセクションでは、サイトのパフォーマンスを定量的に測定できます。 各指標から、パフォーマンスのさまざまな側面に関する分析情報が得られます。例: First Contentful Paint は、コンテンツが初めて画面に描画されたタイミングを示します。これは、ユーザーの操作における重要なマイルストーンです。 Time To Interactive は、ページ読み込みの ユーザー インタラクションを処理するのに十分な準備が整っているように見えます。

スクリーンショット

以下に、ページの読み込み時のスクリーンショットを示します。

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

最適化

次の [最適化] セクションには、ページの読み込み速度を改善するためのヒントが表示されます。 向上します

[オポチュニティ] セクション

オポチュニティをクリックすると、詳細が表示されます。

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

[Learn more...] をクリックすると、最適化案が重要である理由と具体的な内容に関するドキュメントが表示されます。 最適化案が表示されます。

診断

[診断] セクションでは、ページの掲載順位に影響する要素について詳しく 読み込み時間が短縮されます

[診断] セクション

合格した監査

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

[合格した監査] セクション

ステップ 2: テスト

Lighthouse レポートの [Opportunities]（最適化）セクションで、ページの表示を改善するためのヒントを 向上しますこのセクションでは、コードベースに推奨される変更を実装し、 サイトの速度への影響を測定します。

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

レポートによると、テキスト圧縮を有効にすると、テキスト圧縮や パフォーマンス指標です

テキスト圧縮とは、テキスト ファイルをネットワーク経由で送信する前に、そのサイズを小さく（圧縮）することです。たとえば、メールを送信する前にフォルダを zip 圧縮してサイズを小さくする方法などです。

圧縮を有効にする前に、テキストが圧縮されていないかどうかを手動でチェックする方法がいくつかあります。 リソースが圧縮されます。

[ネットワーク] パネルを開き、 [設定] > 大きいリクエスト行を使用する。

大きなリクエスト行が表示されている [Network] パネルの [Size] 列

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

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

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

    [Headers] タブ。

  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 の最下位の値は圧縮されていないファイルサイズです。

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

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

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

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

  1. [Lighthouse] パネルを開き、上部のアクションバーで 追加する [Perform an audit...] をクリックします。

    [Perform an audit] ボタン

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

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

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

実際のテキスト圧縮

ほとんどのサーバーには、圧縮を有効にするためのこのような簡単な修正があります。その方法を テキストの圧縮に使用するサーバーを構成できます

画像のサイズ変更

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

画像のサイズを変更すると、画像のファイルサイズが小さくなるため、読み込み時間を短縮できます。ユーザーが 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 で、[Sources] パネルでファイルを開きます。コード行の横に緑色のバーがある場合は、その行が実行されています。コード行の横にある赤いバーは、実行されておらず、 ページの読み込み時には不要です

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

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

つまり、独自のコードを扱う場合、[カバレッジ] タブはコードの分析に役立ちます。 ページの読み込みに必要なコードだけを配布するようにしましょう。

ページの読み込みに jquery.js ファイルと lodash.js ファイルは必要ですか？[リクエストのブロック] タブでは、 リソースを利用できない場合の影響を 示しています

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

  2. 「blocking」と入力して [Show Request 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 レポート。

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

クリティカル レンダリング パスとは、ページの読み込みに必要なコードのことを指します。一般に ページの読み込み時に重要なコードのみを配布し、遅延読み込みを行うことで、ページの読み込みを高速化できます。 表示されます。

  • 完全に削除できるスクリプトが見つかる可能性は低いですが、 多くのスクリプトはページ読み込み時にリクエストする必要がないため、代わりに 使用できます。async または defer の使用をご覧ください。
  • フレームワークを使用している場合は、本番環境モードがあるかどうかを確認します。このモードでは、 ツリー シェイキング機能を使用します。これにより、重要なレンダリングを妨げる不要なコードを削除できます。

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

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

メインスレッドは、ページの表示に必要な処理（データの解析、 HTML、CSS、JavaScript の実行などです。

目標は、[Performance] パネルを使用して、メインスレッドが ページの読み込みを遅らせて 不要な作業を削除する方法を見つけることもできます

  1. [パフォーマンス] >設定] をタップします。 [Capture Settings] を選択して、[Network] を [Slow 3G] に、[CPU] を [6x speeddown] に設定します。

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

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

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

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

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

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

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

トレースを調査して、JavaScript の処理を減らす方法を見つけます。

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

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

    React にはカスタム速度の測定方法がたくさんありますが、トニーのアプリは React の開発モードを使用しているようです。React の本番環境モードに切り替えると、パフォーマンスが向上する可能性があります。

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

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

    メイン セクション。

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

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

    mineBitcoin のアクティビティ。

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

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

    [ボトムアップ] タブ。

    [ボトムアップ] セクションには、アクティビティまたはアクティビティ グループに関する情報のみが表示されます 選択します。たとえば、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 リポジトリで報告してください。
  • Chromium のバグで DevTools のバグレポートを報告します。
  • メーリング リストで機能と変更点について議論する。メーリング リストは、 質問できます。代わりに Stack Overflow を使用してください。
  • Stack Overflow で、DevTools の使用方法に関する全般的なヘルプを入手できます。バグを報告する際は、必ず Chromium バグを使用してください。
  • @ChromeDevTools でツイートしてください。