Lighthouse を使用して Web サイトの速度を最適化する

[アーティクル]
03/29/2023

このチュートリアルでは、DevTools で Lighthouse やその他のツールを使用して、Web サイトの読み込みを高速化する方法を見つける方法について説明します。

Lighthouse ツールは、サードパーティの Web サイトでホストされているコンテンツへのリンクを提供します。 Microsoft は、これらのサイトのコンテンツと収集される可能性のあるデータに対して責任を負わず、制御も行いません。

前提条件

Visual Studio Code をインストールしてソースコードを編集します。
Node.js をインストールして、ローカル Web サーバーとして使用します。

概要

このチュートリアルでは、 Margie の旅行、旅行画像、テキストの説明、いくつかの JavaScript ベースのユーザー操作、対話型マップを含む架空の旅行 Web サイトのパフォーマンスを向上させます。

Web サイトのソースファイルは、MicrosoftEdge/Demos > travel-site にあります。

手順 1: Web サイトをローカルに設定する

最初に、後で変更できるように、Web サイトをローカルに設定します。

Web サイトのソースコードをローカルで取得する: Demos リポジトリをダウンロードまたは複製します。
Visual Studio Code でダウンロードまたは複製したフォルダーを開きます。
Visual Studio Code で、[ターミナルの表示>] を選択します。または、 Ctrl キーを押しながら'キーを押します。

Visual Studio Code では、エクスプローラー サイドバーにソースファイルが表示され、ターミナルが表示されます。
ターミナルで、「」と入力 npx http-server してローカル Web サーバーを起動します。

このローカル Web サーバーは、Visual Studio Code を閉じると停止します。
Microsoft Edge で、に http://localhost:8080/travel-site 移動して Web サイトを開きます。

手順 2: サイトを監査する

サイトの読み込みパフォーマンスを向上させるために設定するたびに、常に監査から始めます。

監査には、次の 2 つの重要な機能があります。

後続の変更を測定するための ベースライン が作成されます。
これは、パフォーマンスを最も向上させる変更に関する 実用的なヒント を提供します。

ベースラインを確立する

ベースラインは、パフォーマンスを向上する前にサイトがどのように実行したかの記録です。

Microsoft Edge で、Web ページを右クリックし、[検査] を選択して DevTools を開 きます。または、 Ctrl + Shift + I (Windows、Linux) または Command + Option + I (macOS) を押します。
DevTools の [メイン] ツールバーで、[Lighthouse] タブを選択します。そのタブが表示されない場合は、[その他のタブ ] () ボタンをクリックするか、[その他のツール] () ボタンをクリックします。
[パフォーマンス] カテゴリを選択し、他のすべてのカテゴリをクリアします。ここでは、他の既定のオプションをそのまま使用します。以下のオプションがあります:
- モード: Web ページの読み込み中にテストを実行するには、このオプションを [ナビゲーション] (既定値) に設定します。一定期間にテストを実行するには、オプションを Timespan に設定します。 Web ページでテストを今すぐ実行するには、オプションを [スナップショット] に設定します。
- デバイス: モバイルユーザーエージェント文字列とモバイルビューポートをシミュレートするには、このオプションを [モバイル] に設定します。シミュレーションなしで Web ページをテストするには、このオプションを [デスクトップ] に設定します。
- カテゴリ: このオプションを使用すると、 Lighthouse で使用できるテストのサブセットのみを実行できます。
[ ページ読み込みの分析] をクリックします。
10 秒から 30 秒後に、サイトのパフォーマンスのレポートが表示されます。

レポートエラーの処理

Lighthouse レポートにエラーが表示される場合は、InPrivate ウィンドウから Lighthouse をもう一度実行し、他のタブは開かないようにしてください。 InPrivate ウィンドウから Lighthouse を実行すると、監査プロセスが干渉なく実行されます。

Lighthouse レポートの上部にあるエラー

InPrivate ウィンドウを開くには:

Microsoft Edge ツールバー (DevTools ツールバーの上) にある [設定など ] (...) ボタンをクリックします。
[ 新しい InPrivate] ウィンドウをクリックします。
Lighthouse で新しいベースラインを確立します。

レポートを理解する

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

レポートの上部にある数値は、Web ページの全体的なパフォーマンススコアです。後でコードを変更すると、表示される数が増えるはずです。スコアが高いほど、パフォーマンスが向上します。

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

指標

[ メトリック] セクションでは、Web ページのパフォーマンスを定量的に測定できます。

[メトリック] セクション

各メトリックは、パフォーマンスのさまざまな側面に関する分析情報を提供します。例:

[最初のコンテンツフルペイント ] は、コンテンツが最初に画面に表示されるタイミングを示します。これは、ユーザーがページの読み込みを認識する上で重要なマイルストーンです。
Time To Interactive は、レンダリングされたページがユーザーの操作を処理する準備ができているポイントをマークします。

[ ビューの展開] をクリックして、各メトリックの説明を表示します。次に、[ 詳細情報 ] をクリックして、それに関するドキュメントを読みます。

[展開されたメトリック] セクション

スクリーンショット

[ メトリック] セクションの下には、読み込み中のページの外観を示すスクリーンショットのコレクションがあります。

読み込み中のページの外観を示す一連のスクリーンショット

機会

[ 営業案件] セクションには、この特定の Web ページの読み込みパフォーマンスを向上させる方法に関する具体的なヒントが示されています。

[営業案件] セクション

営業案件をクリックして詳細情報を表示し、[ 詳細情報 ] をクリックして、営業案件が重要な理由と、それを修正する方法に関する具体的な推奨事項を確認します。

詳細情報を含む拡張された営業案件と、

診断

[ 診断 ] セクションでは、ページの読み込み時間に影響する要因について詳しく説明します。

[診断] セクション

合格した監査

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

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

手順 3: 実験

レポートの [ 営業案件 ] セクションには、Web ページのパフォーマンスを向上させる方法に関するヒントが表示されます。このセクションでは、推奨される変更をコードベースに実装し、変更後にサイトを再度監査して、その変更がサイトの速度にどのように影響するかを測定します。

画像のサイズを変更する

レポートは、適切なサイズの画像を提供することが、ページのパフォーマンスを向上させる最も良い機会の 1 つであることを示しています。イメージのサイズ変更は、ネットワークペイロードのサイズを小さくするのに役立ちます。ユーザーが幅 500 ピクセルのモバイルデバイス画面で画像を表示している場合、1500 ピクセル幅の画像を送信しても意味がありません。理想的には、最大で 500 ピクセル幅の画像を送信します。

レポートの [ 営業案件 ] セクションで、[ 画像のサイズを適切に設定 ] をクリックして、サイズを変更する画像を表示します。 Lighthouse には、読み込み時間を短縮するためにサイズを変更できる 4 つの .jpg ファイルが一覧表示されます。

最適化する 4 つの画像と潜在的なデータ節約を示す [営業案件] セクション

これらのイメージのサイズを変更する前に、これらのイメージを表示するためにサーバーがブラウザーに送信する必要があるデータの量を確認します。

ネットワーク ツールを開きます。

ツールが空の場合は、ページを更新します。
[ フィルター ] テキストボックスに「」と入力 .jpg して要求の一覧をフィルター処理し、4 つの画像のみを表示します。

ネットワークツールでの要求のフィルター処理の詳細については、「 ネットワーク 機能のフィルター要求リファレンス」を 参照してください。
ネットワーク ツールの下部のツールバーを確認して、画像が原因で転送されたデータの量を確認します。

下部のツールバーは、4 つの画像がこの Web ページで転送された合計 17.3 MB のデータの 16.4 MB を提供していることを示しています。

次に、イメージのサイズを変更し、新しい監査を実行します。

Visual Studio Code で、エクスプローラー内のフォルダーを開きます/travel-site/assets/img/optimized/。このフォルダーには、Web ページに表示されているが、既に最適化されている 4 つの画像のコピーが含まれています。これらの画像は幅 1000 ピクセルで、より最適化された .webp 形式を使用します。

イメージのサイズ変更は、オペレーティングシステムによって異なります。たとえば、Windows 上のイメージのサイズを変更するには、 PowerToys を使用できます。詳細については、「 Image Resizer ユーティリティ」を参照してください。
ファイルを /travel-site/index.html 開き、次のように 4 つのイメージパスを置き換えます。
- ファイルassets/img/optimized内のの assets/img/ 4 つのインスタンスをに置き換えます。
- ファイル.webp内のの .jpg 4 つのインスタンスをに置き換えます。
Lighthouse で、[監査の実行] () をクリックして、ベースラインレポートを失わずにメイン Lighthouse ページに戻ります。
[ ページ読み込みの分析 ] をもう一度クリックして、変更が読み込みパフォーマンスにどのように影響するかを確認します。

スコアが 18 から 26 に増加しました。保存したデータの量を確認するには、前と同じように ネットワーク ツールを使用します。

ネットワークツール。4 つの画像要求が再び表示され、転送されたデータの合計量が少なくなります

Web ページ上の画像では、16.4 MB ではなく 360 KB のデータのみを転送する必要があります。

画像のサイズを自動的に変更する

小さなアプリの場合は、このような 1 回限りのサイズ変更を実行するだけで十分な場合があります。ただし、大規模なアプリの場合は、画像を管理するための次の戦略を検討してください。

ビルドプロセス中にイメージのサイズを自動的に変更します。
ビルドプロセス中に各イメージの複数のサイズを作成し、コードで使用 srcset します。実行時に、ブラウザーはデバイスに最適なサイズを選択します。詳細については、「web.dev のレスポンシブイメージ」を参照してください。
イメージを要求するときに動的にサイズを変更できるイメージ CDN を使用します。
少なくとも、各イメージを最適化します。これは多くの場合、大きな節約を生み出すことができます。

最適化 とは、イメージファイルのサイズを小さくするプログラムを介してイメージを実行することを意味します。その他のヒントについては、「web.dev での高速読み込み時間で画像を最適化する」を参照してください。

未使用の JavaScript を減らす

最新の Lighthouse レポートには、Web ページに未使用の JavaScript コードが含まれており、必要な場合にのみこのコードを読み込むと、ページの読み込み時に転送されるデータの量が減ると記載されています。

[ 未使用の JavaScript を減らす ] をクリックして、最も未使用のコードを含む JavaScript ファイルを表示します。

未使用の JavaScript メッセージを示す Lighthouse 営業案件セクション

報告された JavaScript ファイルはドメインから www.bing.com のものです。つまり、未使用のコードは、Web ページで使用されている Bing Map コンポーネントから取得されます。 Margie の旅行デモ Web サイトを下にスクロールして、マップを表示します。

デモ Web サイトのマップコンポーネント

未使用のコードの量を確認し、使用されていないその他のリソースを見つけるには、 カバレッジ ツールを使用します。

DevTools で、 Ctrl + Shift + P (Windows、Linux) または Command + Shift + P (macOS) を押してコマンドメニューを開き、「」と入力 Coverageし、一覧で [カバレッジの表示 ] を選択します。
カバレッジ ツールで、[インストルメント化の開始] をクリックし、ページを更新)。 カバレッジ ツールは、ページに読み込まれた JavaScript コードと CSS コードが実際に実行された量の概要を示します。

カバレッジレポートは、Bing Map の依存関係に、ページの読み込み時に使用されないコードが含まれていることを確認します。デモ Web サイトのマップは、ページが最初に読み込まれたときに表示されません。ページのそのセクションがユーザーに表示される場合にのみ、Bing Map を読み込むことでパフォーマンスを向上させる良い機会があります。

Intersection Observer API を使用して、マップがユーザーに表示されるタイミングを検出します。 Intersection Observer API を使用すると、ターゲット要素 (この場合はマップ) と Web ページのビューポートの交差部分の変化を観察できます。詳細については、「MDN での交差オブザーバー API 」を参照してください。

Visual Studio Code でファイルを /travel-site/index.html 開き、ファイルの下部まで下にスクロールします。 Bing Map API は、タグを使用して <script> 読み込まれます。

この行の下には、適切な場所でマップを構成して読み込む別の行があります。 <script src="assets/map.js"></script>
これらの 2 行を削除し、代わりにこの新しい行を追加します。 <script src="assets/map-on-demand.js"></script>
Visual Studio Code でファイルを /travel-site/assets/map-on-demand.js 開き、コードを読み取って、Bing Map コンポーネントを読み込んで初期化する方法を理解します。そのコードのスニペットと、その動作の説明を次に示します。
```
const MAP_CONTAINER_EL = document.querySelector('.place-discover-map');

const mapElIntersectionObserver = new IntersectionObserver(loadMapOnDemand);
mapElIntersectionObserver.observe(MAP_CONTAINER_EL);

let map = null;

function loadMapOnDemand(entries) {
   if (map) {
     return;
   }

   if (!entries.some(entry => entry.isIntersecting)) {
     return;
   }

   const script = document.createElement('script');
   script.type = 'text/javascript';
   script.src = 'https://www.bing.com/api/maps/mapcontrol?callback=GetMap&key=Ap_eazGgpq5468v9MXr7Wu0zh30LQActgaT-tI_QxZQSm-Bd5qJxVKs_2B7NsqR4';
   document.body.appendChild(script);
}

function GetMap() { /* ... */ }
```
コードは、変数を mapElIntersectionObserver 新しい IntersectionObserver オブジェクトに初期化します。その後、このオブザーバーは、マップを MAP_CONTAINER_EL 含むページ上の要素である要素の監視を開始します。

ユーザーがスクロールすると、オブザーバーの loadMapOnDemand コールバック関数が実行されます。マップが既に存在する場合、またはマップコンテナー要素が現在のビューポートと交差していない場合、この関数は何も実行しません。

ユーザーがマップコンテナー要素がビューポートに表示されるポイントまでスクロールし、マップがまだ初期化されていない場合、コードは新しい script 要素を作成し、その src 属性を Bing Map API に設定し、を script ページに挿入します。

ファイルの map-on-demand.js 残りの部分は、ファイルと map.js 同じです。 Bing Map API が読み込まれるとすぐに、関数が GetMap 実行されます。 GetMap では、コンテナー要素にマップが構成され、表示されます。
変更を Visual Studio Code に保存し、Microsoft Edge で Web ページを更新し、 Lighthouse ツールで新しい監査を実行して、変更が読み込みパフォーマンスにどのように影響するかを確認します。

Lighthouse スコアは 31 になりましたが、これは以前からの改善ですが、最適化する必要がある点が増えています。

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

Lighthouse ツールの [営業案件] セクションに表示される次の営業案件は、レンダリングブロッキングリソースの排除に関連しています。

レンダリングブロッキングリソースは、ブラウザーがページを表示する前にダウンロード、解析、および実行する必要がある外部 JavaScript または CSS ファイルです。 Web ページの読み込み時に処理する必要があるレンダリングブロッキングリソースが多いほど、Web ページがブラウザーに表示され始める必要が長くなります。ページの初期状態を正しく表示するために必要なコア CSS と JavaScript コードのみを実行してください。

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

[ レンダリングブロックリソースを排除 する] をクリックして、ブロックしているリソースを表示します。

Lighthouse には、デモ Web ページで使用されるスタイルシートの一覧 (、home.cssmap.css、、など) base.cssが表示されます。
カバレッジ ツールをもう一度開きます。Ctrl + Shift + P (Windows、Linux) または Command + Shift + P (macOS) を押し、「カバレッジ」と入力し、[カバレッジの表示] を選択します。
[カバレッジのインストルメント化を開始する] をクリックし、ページを更新して () カバレッジレポートを表示し、[URL フィルター] フィールドに「」と入力cssして CSS ファイルのみを表示します。

レポートには、 contact-form.css ファイルと gallery.css ファイルがまったく使用されていないことが示されています。どちらも 100% 未使用バイトです。
レポート内の contact-form.css ファイルをクリックします。 DevTools は 、ソース ツールでファイルを開きます。コード行が実行された場合は、その横に青いバーが表示されます。赤いバーは、コード行が実行されなかったことを意味し、Web ページの読み込みに間違いなく必要ありません。

このソースファイルには赤いバーのみが表示されます。これは、Web ページにこのファイルがまったく必要ないことを意味します。

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

Visual Studio Code で、ファイルを /travel-site/index.html 開きます。
ファイルの上部付近で、ページ上のスタイルシートを読み込むタグの <link> 一覧を見つけます。
ファイルと gallery.css ファイルを読み込む 2 行のコードをcontact-form.css削除します。
変更を Visual Studio Code に保存し、Microsoft Edge で Web ページを更新し、 Lighthouse ツールで新しい監査をもう一度実行して、変更が読み込みパフォーマンスにどのように影響するかを確認します。

重要でない CSS を自動的に削除する

前の手順ではスコアが若干改善されましたが、 Lighthouse は他の CSS ファイルに対して、ページの初期レンダリングをブロックするようにフラグを設定します。

Web ページでは残りの CSS ファイルが使用されるため、削除できません。ただし、次の 2 つのグループに分割できます。

Web ページのレンダリングをブロックする必要がある重要な CSS コードは、読み込み時にユーザーが表示する Web ページの部分のスタイルとレイアウトに視覚的に影響するためです。

たとえば、Web ページのタイトルでは、ファイル内の header h1 CSS ルールが /travel-site/assets/base.css 使用されます。
ページの読み込み時に表示されないページの一部をレンダリングするために使用される重要でない CSS コード。

たとえば、 /travel-site/assets/desktop.css ファイルは、ビューポートがより 665px大きい場合にのみ必要です。

このように CSS コードを自動的に分割するには、 クリティカル ツールを使用します。詳細については、「重要なプロジェクトリポジトリ」を参照してください。

その後、ページの初期レンダリングをブロックしない方法で、重要でない CSS コードを読み込むことができます。詳細については、「web.dev で重要でない CSS を延期する」を参照してください。

また、CSS コードを縮小し、不要な空白文字やコメントを削除することもできます。詳細については、「web.dev での CSS の縮小」を参照してください。

画像の幅と高さを明示的に設定してレイアウトシフトを減らす

Lighthouse レポートの [診断] セクションでは、明示的widthなイメージ要素と height イメージ要素の定義が提案されています。 [ Image 要素に明示的な幅と高さがありません ] をクリックすると、詳細情報が表示されます。

イメージの明示的な幅と高さの設定に関する Lighthouse 診断セクション

レポートには、Web ページの上部にある画像に明示的 width な属性と height 属性がないため、レイアウトのシフトが発生する可能性があります。

レイアウトシフトは、Web ページの一部が最初に 1 つの場所に表示された後、ページの読み込み中に別の位置に移動したときに発生します。たとえば、イメージが読み込まれると、イメージが完全に読み込まれるまで、そのイメージに予約する領域がブラウザーに認識されません。

Web ページに画像を読み込むことによって発生するレイアウトのずれを防ぐには、次のいずれかの操作を行います。

HTML コードで各イメージとwidthheight属性を定義します。
CSS プロパティを使用して CSS のスペースを予約します aspect-ratio 。

詳細については、「web.dev での累積レイアウトシフトの最適化」の「ディメンションのない画像」を参照してください。

次の手順では、CSS プロパティを aspect-ratio 使用してレイアウトのシフトを回避します。

Visual Studio Code でファイルを /travel-site/assets/home.css 開き、セレクターを持つ CSS 規則を .hero-image img 検索します。
CSS ルールを次のように変更します。
```
.hero-image img {
  width: calc(100% + 2 * var(--main-margin));
  position: relative;
  left: calc(-1 * var(--main-margin));
  aspect-ratio: 1.5;
  object-fit: cover;
}
```
この変更の前に、CSS ルールにはプロパティが既に含まれていた width ため、ブラウザーはイメージに予約する水平領域の量を知っていました。プロパティを aspect-ratio 追加することで、予約する垂直領域の量をブラウザーに伝えます。プロパティを object-fit 追加すると、CSS のサイズが実際のイメージファイルのサイズと一致しない場合に画像が歪むのを防ぐことができます。
ファイルを /travel-site/assets/desktop.css 開き、同じ .hero-image img セレクターを持つ CSS 規則を検索します。

ファイルは desktop.css 、ビューポートがより 665px大きい場合にのみ使用されます。たとえば、ノート PC で使用する場合など、Web ページが大画面に表示される場合に使用されます。
CSS ルールを次のように変更します。
```
.hero-image img {
    width: 100%;
    position: static;
    aspect-ratio: 2.5;
    object-fit: cover;
}
```
今回は、CSS ルールに既にとがwidthobject-fit定義されています。ただし、イメージのを max-height 定義する代わりに、プロパティを aspect-ratio 使用して、ブラウザーがデスクトップデバイス上のイメージを予約する領域を正確に認識していることを確認します。
変更を Visual Studio Code に保存し、Microsoft Edge で Web ページを更新し、 Lighthouse ツールで新しい監査を実行して、変更が読み込みパフォーマンスにどのように影響するかを確認します。

スコアは最大 37 になりましたが、さらに重要なのは 、累積レイアウトシフト スコアが 0 に下がり、ページの読み込み時にレイアウトにシフトがなくなったことを示しています。

メインスレッドでの作業の削減

最新のレポートには、高い時間から対話型および合計ブロック時間のメトリック値が表示されます。つまり、Web ページには実行に時間がかかり、ページが数秒間使用できなくなるものが残っています。

[診断] セクションまで下にスクロールします。[メインスレッドの作業を最小限に抑え、JavaScript の実行時間を短縮する] と表示されます。メインスレッドは、次のようなページを表示するために必要なほとんどの作業をブラウザーが実行する場所です。

HTML の解析と実行。
CSS の解析と DOM 要素への適用。
JavaScript の実行。

この場合、最大のボトルネックは、ページの読み込み時にページが実行される JavaScript コードが多すぎるということです。

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

パフォーマンス ツールを開きます。
パフォーマンス ツールで、[プロファイルの開始] をクリックし、ページを再読み込み () し、ページが完全に読み込まれたら [停止] をクリックします。

DevTools は、ページを読み込むためにブラウザーが実行したすべての作業の視覚化を表示します。この視覚化は、 トレースと呼ばれます。

トレースには、アクティビティが左から右に時系列で表示されます。上部の CPU グラフと NET グラフでは、CPU とネットワークアクティビティの概要が表示されます。 CPU グラフの明るい茶色の領域は、ブラウザーがスクリプトアクティビティでビジー状態だった期間に対応します。この領域は、JavaScript の作業を減らすことでページの読み込みを高速化できる可能性がある手掛かりです。

CPU グラフの長いスクリプトアクティビティ

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

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

たとえば、次の図では、ブラウザーはほとんどの時間を Parse HTML イベントに費やしています。このイベントが実行されている限り、Web ページは完全には表示されません。このイベントにより、ブラウザーが JavaScript コードを実行するときに対応する長い Evaluate Script イベントが発生しました。 Evaluate Script イベントによって関数が(anonymous)実行され、関数がinitRatings実行されます。

パフォーマンスツールの [メイン] セクションのイベント

ページの initRatings 読み込みを高速化するために関数を最適化します。

Visual Studio Code でファイルを /travel-site/assets/rating.js 開き、コードを読み取ります。

このファイルのコードは、Web ページに 5 つの顧客レビューを表示する役割を担います。各レビューには、いくつかの星、見積もり、著者で構成される評価があります。これらのレビューは、関数で使用されるサーバー側 API から取得されます getRatings 。関数は initRatings 、各レビューのページに DOM 要素を作成します。
関数で initRatings 、JavaScript コードをより高速にする方法を見つけます。

この Web ページは単なるデモであり、コードの速度を for 低下させるループが導入されました。実際には、次のような JavaScript ファイルでページ読み込みが遅くなる方法は多数あります。次に例を示します。
- DOM へのアクセス頻度が高すぎます。
- 大量の計算タスクを実行する。
- 大規模な JavaScript ライブラリまたはフレームワークの使用。
関数のforinitRatings先頭にあるループを削除し、変更を保存し、Microsoft Edge でページを再読み込みします。
Lighthouse ツールで新しい監査を実行して、変更が負荷パフォーマンスにどのように影響するかを確認します。
- スコアは 92 に上がりました。
- Time to interactive メトリックは 1.3 秒に下がりました。
- [ブロック時間の合計] メトリックが 0 秒に低下しました。

ページのパフォーマンスを分析する方法の詳細については、「パフォーマンス機能リファレンス)」を参照してください。

メインスレッドでの作業の削減 (現実世界)

パフォーマンス ツールは、Web ページが読み込むアクティビティを把握し、不要なアクティビティを削除する方法を見つける最も一般的な方法です。

のような console.log()アプローチを好む場合は、 User Timing API を使用すると、アプリライフサイクルの特定のフェーズを任意にマークアップして、各フェーズにかかる時間を追跡できます。

ほとんどのユーザーインターフェイスを生成するために JavaScript を使用する場合、Web ページの読み込みが遅くなることがよくあります。 Web ページのパフォーマンスを向上させるには、Web ページのユーザーインターフェイスを作成するコードをサーバー側に移動し、そのコードを HTML と CSS としてブラウザーに配信することを検討してください。

概要

サイトの読み込みパフォーマンスを最適化するように設定するたびに、常に監査から始めます。監査によってベースラインが確立され、改善方法に関するヒントが提供されます。
一度に 1 つの変更を行い、変更のたびに Web ページを監査して、分離された変更がパフォーマンスにどのように影響するかを表示します。

注:

このページの一部は、 Google によって作成および共有され、クリエイティブ・コモンズ属性 4.0 国際ライセンスに記載されている条件に従って使用される作業に基づく変更です。元のページはここにあり、 Kayce Basques (テクニカルライター、Chrome DevTools & Lighthouse) によって作成されています。

この作品は、クリエイティブ・コモンズ属性4.0国際ライセンスに基づきライセンスされています。

Lighthouse を使用して Web サイトの速度を最適化する

前提条件

概要

手順 1: Web サイトをローカルに設定する

手順 2: サイトを監査する

ベースラインを確立する

レポート エラーの処理

レポートを理解する

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

指標

スクリーンショット

機会

診断

合格した監査

手順 3: 実験

画像のサイズを変更する

画像のサイズを自動的に変更する

未使用の JavaScript を減らす

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

重要でない CSS を自動的に削除する

画像の幅と高さを明示的に設定してレイアウトシフトを減らす

メイン スレッドでの作業の削減

メイン スレッドでの作業の削減 (現実世界)

概要

その他のリソース

レポートエラーの処理

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

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

メインスレッドでの作業の削減

メインスレッドでの作業の削減 (現実世界)