このページは Cloud Translation API によって翻訳されました。

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

Kayce Basques

Sofia Emelianova

概要

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

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

その他多くの指標

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

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

チュートリアルの目標

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

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

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

前提条件

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

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

はじめに

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

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

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

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

設定

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

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

プロジェクトの名前は tony からランダムに生成された名前に変わります。これで、コードの編集可能なコピーが用意されました。後でこのコードに変更を加えます。
エディタタブの下部にある [プレビュー] をクリックします。新しいウィンドウでプレビューします。デモが新しいタブで開きます。このタブはデモタブと呼ばれます。サイトの読み込みに時間がかかることがあります。
デモと一緒に DevTools を開きます。

ベースラインを確立する

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

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

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

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

説明はここまでです。変更を加えましょう。テキスト圧縮を有効にするために数行のコード:

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

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

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

app.use(express.static('build')) の前に app.use(compression()) が配置されていることを確認してください。

注: 通常は npm i -S compression などで compression パッケージをインストールする必要がありますが、これはすでに完了しています。
Glitch がサイトの新しいビルドをデプロイしてくれるのを待ちます。左下隅の幸せな絵文字は、デプロイが成功したことを示します。

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

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

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

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

[Lighthouse] パネルを開き、上部のアクションバーで [Perform an audit...] をクリックします。
設定は前と同じままにして、[ページの読み込みを分析] をクリックします。

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

実際のテキスト圧縮

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

画像のサイズ変更

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

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

レポートで [適切なサイズの画像を使用] をクリックして、サイズを変更する必要がある画像を確認します。4 枚の画像すべてが必要以上に大きいようです。
エディタタブに戻り、src/model.js を開きます。
const dir = 'big' を const dir = 'small' に置き換えます。このディレクトリには、サイズ変更された同じ画像のコピーが格納されます。
ページを再度監査して、この変更による読み込みのパフォーマンスへの影響を確認します。

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

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

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

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

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

レンダリングをブロックするリソースを排除する

最新のレポートによると、レンダリングブロックリソースの排除が最大のチャンスです。

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

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

[レンダリングをブロックするリソースを排除する] をクリックして、ブロックしているリソースを確認します。 lodash.js と jquery.js。
ご使用のオペレーティングシステムに応じて、次のキーを押してコマンドメニューを開きます。
- Mac: Command+Shift+P
- Windows、Linux、ChromeOS: Ctrl+Shift+P
「Coverage」と入力し、[Show Coverage] を選択します。

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

このスクリーンショットでは、jQuery ファイルと Lodash ファイルの約 74% と 30% が使用されていないことがわかります。
[jquery.js] 行をクリックします。DevTools で、[Sources] パネルでファイルを開きます。コード行の横に緑色のバーがある場合は、その行が実行されています。コード行の横にある赤いバーは、実行されておらず、ページの読み込み時には不要です
jQuery コードを少しスクロールします。「実行される」行の一部実際には単なるできます。コメントを削除する圧縮ツールでこのコードを実行することも、このファイルのサイズを削減する方法の 1 つです。

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

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

[ネットワーク] タブをクリックし、コマンドメニューをもう一度開きます。
「blocking」と入力して [Show Request Blocking] を選択します。[リクエストのブロック] タブが開きます。
[ パターンを追加] をクリックし、テキストボックスに「/libs/*」と入力し、Enter キーを押して確定します。
ページを再読み込みします。jQuery リクエストと Lodash リクエストは赤色で表示され、これはブロックされたことを表します。「ページは引き続き読み込まれ、インタラクティブであるため、これらのリソースは特に必要ないようです。
[ パターンをすべて削除] をクリックして、/libs/* ブロックパターンを削除します。

一般に、[リクエストのブロック] タブは、特定のリクエストに対するできません。

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

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

対応する <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>

サイトが再ビルドされて再デプロイされるまで待ちます。
[Lighthouse] パネルからページを再度監査します。総合スコアが回復しているはずです。

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

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

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

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

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

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

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

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

通常、モバイルデバイスにはノートパソコンやデスクトップよりも多くのハードウェア制約があるため、これらの設定を使用すると、低性能のデバイスを使用している場合と同様にページが読み込まれます。
[] [再読み込み] をクリックします。 DevTools はページを再読み込みし、ページを読み込むために必要なすべての処理を可視化します。このビジュアリゼーションを「トレース」と呼びます。

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

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

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

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

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

React にはカスタム速度の測定方法がたくさんありますが、トニーのアプリは React の開発モードを使用しているようです。React の本番環境モードに切り替えると、パフォーマンスが向上する可能性があります。
[タイミング] をもう一度クリックして、そのセクションを閉じます。
[Main] セクションに移動します。このセクションには、メインスレッドのアクティビティが時系列で表示されます。左から右に並べますY 軸（上から下）には、イベントが発生した理由が示されます。

この例では、Evaluate Script イベントによって (anonymous) 関数が実行され、それに伴って __webpack__require__ が実行され、さらに ./src/index.jsx が実行されました。
[Main] セクションの一番下までスクロールします。フレームワークを使用する場合、上位アクティビティのほとんどはフレームワークによって発生するため、通常は制御できません。通常、アプリによって発生したアクティビティは一番下に表示されます。

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

注: 通常、フレームワークが行う呼び出しは制御できませんが、フレームワークが非効率的に実行されるようにアプリを構成している場合があります。フレームワークを効率的に使用できるようにアプリを再構成することで、メインスレッドでの作業を削減できます。そのためには、フレームワークがどのように機能するか、またフレームワークをより効率的に使用するためにコードにどのような変更を加えることができるかについて、深く理解する必要があります。
下部の [ボトムアップ] タブを開きます。このタブには、最も時間がかかったアクティビティの詳細が表示されます。[Bottom-Up] セクションに何も表示されない場合は、[Main] セクションのラベルをクリックします。

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

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

本番環境モードを使用し、JavaScript アクティビティを削減するのにかかる時間ページの読み込みを高速化できます本番環境モードで開始します。

エディタタブで webpack.config.js を開きます。
"mode":"development" を "mode":"production" に変更します。
新しいビルドがデプロイされるまで待ちます。
ページを再度監査します。

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

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

不要な 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 でツイートしてください。