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

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

Kayce Basques

Sofia Emelianova

概要

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

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

その他多くの指標

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

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

チュートリアルの目標

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

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

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

前提条件

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

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

はじめに

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

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

サイトの読み込みパフォーマンスの改善に着手する際は、常に監査です。監査には 2 つの重要な機能があります。

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

設定

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

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

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

で確認できます。

ベースラインを確立する

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

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

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

レポートエラーの処理

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

エラーのあるレポート。

レポートの見方

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

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

指標

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

[Metrics] セクション。

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

スクリーンショット

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

読み込み時のページの表示を示すスクリーンショット。

最適化

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

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

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

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

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

診断

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

[診断] セクション

合格した監査

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

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

ステップ 2: テスト

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

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

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

テキスト圧縮とは、Google スプレッドシートで送信する前に、テキストファイルのサイズを縮小（圧縮）することです。接続しますたとえば、メールを送信する前にフォルダを zip 圧縮してサイズを小さくする方法などです。

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

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

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

各 [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 の [Response Headers] セクションに 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 を使用する。
少なくとも、各画像を最適化してください。多くの場合、これによって大幅な費用削減が可能になります。最適化とは画像ファイルのサイズを小さくする特別なプログラムを介して画像を実行します。Essentials の画像の最適化をご覧ください。

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

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

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

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

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

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

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

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

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

[Network] タブをクリックし、コマンドメニューをもう一度開きます。
「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 の使用をご覧ください。
フレームワークを使用している場合は、本番環境モードがあるかどうかを確認します。このモードでは、ツリーシェイキングなどの手法を使用して、重要なレンダリングを妨げる不要なコードを取り除きます。

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

最新のレポートの [最適化] セクションには、少額のコスト削減の可能性が示されていますが、 [診断] セクションを見ると、最大のボトルネックがメインスレッドが多すぎるようです。できます。

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

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

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

モバイルデバイスは通常、ノートパソコンやデスクトップパソコンよりもハードウェアの制約が多いため、これらの設定により、性能の低いデバイスを使用しているかのようにページを読み込むことができます。
[refresh] [再読み込み] をクリックします。 DevTools でページが再読み込みされ、そのページを読み込むために必要なすべての操作が可視化されます。この可視化をトレースと呼びます。

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

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

[Overview] セクションに表示された黄色の部分は、CPU がスクリプトアクティビティにより完全にビジー状態であったことを意味します。これは、JavaScript の作業を減らすことでページの読み込みを高速化できる手がかりになります。

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

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

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

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

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

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

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

[セルフ時間] 列には、各アクティビティに直接費やした時間が表示されます。この例では、メインスレッドの時間の約 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 でツイートしてください。