Lighthouseでサイト速度を測定し、改善点を見つける方法
Lighthouseは、ウェブページのパフォーマンス、アクセシビリティ、ベストプラクティス、および検索エンジン最適化(SEO)における問題点や改善の可能性を特定する自動監査ツールです。Chrome DevToolsでページの読み込みを分析し、遅い指標に関係するリクエスト、ファイル、実行タスクをたどり、1つの要素を変更して、同じ条件で再度測定します。単一のスコアはすべての訪問者の体験を表すものではなく、ページの検索ランキングを決定するものでもありません。
LighthouseとPageSpeed Insights:違いは何ですか?
公式のLighthouse概要では、Chrome DevTools、コマンドライン、またはNodeモジュールを通じて監査を実行する方法が説明されています。初心者は、拡張機能をインストールせずにデスクトップ版Chromeに含まれているパネルから始めることができます。この方法は、サインイン済みのページやローカル開発ページにも便利です。
PageSpeed Insightsのドキュメントでは、ラボデータとフィールドデータを区別しています。ラボデータは、特定の条件下で生成されたLighthouseの診断結果です。実際のユーザー体験データは、過去28日間の収集期間をカバーするChrome User Experience Report(CrUX)から取得されます。ページ単位のサンプルが少ない場合は、オリジン(同じスキーム・ホスト・ポートで識別される範囲)全体のデータが表示されるか、実ユーザーデータ自体が利用できないことがあります。ラボ結果があるからといって、その特定のページの実際の訪問者統計が利用できるわけではありません。
公開URLを素早く確認するには、PageSpeed Insights にURLを入力し、分析して、モバイルとデスクトップの結果をそれぞれ選択してください。サインイン後にのみ表示されるページや、外部からアクセスできないローカルURLの場合は、外部サービスではなくローカルのDevToolsを使用してください。プライベートURLやアクセス・トークンを外部の分析サービスに送信しないでください。
レポートの測定値は、その対象URLと実行条件を示します。公開されている例のURLを使用したデモは、ガイドを公開しているウェブサイトや自身のウェブサイトを測定するものではありません。レポートを読む際には、実際のユーザー体験のセクションとLighthouseの診断セクションを区別して読んでください。
まずページと測定条件を選択してください
- 対象: テストするURLを指定してください。ホームページだけでなく、代表的な記事、一覧ページ、または商品ページを含めてください。異なるテンプレートを同じページのビフォーアフターの結果のように組み合わせないでください。
- 状態: 初回訪問か再訪問か、サインイン状態、および同意バナーの扱いを記録してください。ログイン不要の公開ページの場合、別のプロファイルやシークレットウィンドウを使用すると、拡張機能の影響を減らすのに役立ちます。
- 環境: ChromeとLighthouseのバージョン、モバイルまたはデスクトップの選択、ネットワークおよびCPUスロットリングの方法、測定時間を記録してください。同時に大きなダウンロードや他の重い作業を実行しないようにしてください。
- ストレージ: ストレージをクリアすると、初回訪問時に近い状態にサイトのストレージをリセットします。ログイン状態や同意状態に影響を与える可能性があるため、重要な作業を含むセッションで安易に有効にしないでください。サインイン済みページを監査する場合は、必要な状態を保持する設定を選択し、その後の比較でも一貫して使用してください。
管理者としてサインインした状態で監査を行うと、匿名の訪問者が使用するものとは異なるスクリプト、ツールバー、キャッシュポリシーが読み込まれることがあります。一般の読者に関する質問の場合は、公開ページを別途測定してください。対象がサインインユーザー向けの機能である場合は、その状態を明示的に記録してください。
Chrome DevToolsでページの読み込みを分析する
- デスクトップのChromeでページを開きます。例えば、公開アドレスが正しいこと、ページがエラー画面にリダイレクトされていないことを確認します。
- DevToolsを開きます。例えば、WindowsではF12またはCtrl+Shift+Iで開けます。Lighthouseタブが非表示の場合は、タブオーバーフローメニューやDevToolsメニューの「その他のツール」から見つけます。メニュー名はブラウザの言語やバージョンによって異なることがあります。
- 初回のページロード監査では、モードで「ナビゲーション」を選択します。デバイスでは「モバイル」または「デスクトップ」を選択します。モバイルモードは、あらゆる実機のスマートフォンのパフォーマンスを再現するのではなく、選択された制約のあるラボテストです。
- カテゴリで「パフォーマンス」を選択し、必要に応じて「アクセシビリティ」「ベストプラクティス」または「SEO」を追加します。ストレージのクリア設定やスロットリング設定を確認し、比較中は値を変更しないようにします。
- 「ページ読み込みを分析」またはあなたのバージョンでの同等の開始ボタンを選択します。ページがリロードされるため、未完成のフォームや保存していない作業は事前に保存してください。分析中はページに触れず、レポートが出るまで待ちます。
- 要求されたURL、最終URL、設定およびバージョンを確認します。レポートをHTMLまたはJSONとして保存し、エクスポートメニューで選択可能な場合は必要な形式を選びます。レポートには内部のアドレスや診断情報が含まれる場合があるため、共有する前にその内容を考慮してください。
基本的なロード監査以外のシナリオでは、別のモードを選択してください。Lighthouseのユーザーフロー文書では、Navigationは単一のナビゲーション、Timespanは操作を含む可能性のある期間、およびSnapshotは現在のページ状態として区別されています。TimespanやSnapshotの結果をNavigationの完全なパフォーマンススコアであるかのように比較しないでください。メニューが開いているときのアクセシビリティなど、特定の状態に関する質問の場合はSnapshotを考慮してください。
スコアを見る前に、メトリクスと診断の手がかりを確認してください
パフォーマンススコアの説明は、スコアを変換されたメトリック値の加重平均として説明しています。診断警告の数を減らしても、スコアが同じ割合で上がるわけではありません。スコアは90〜100が良好、50〜89が改善が必要、0〜49が不良として表示されます。これらの範囲は1回の実行のスコアを解釈するものであり、実際のユーザーに対して許容されるすべての遅延を定義するものではありません。
| メトリック | 測定対象 | 最初に確認すべき手がかり |
|---|---|---|
| FCP: ファーストコンテンツフルペイント | 最初のコンテンツが表示されるまでの時間。 | 初期サーバー応答とレンダーブロッキングのスタイルやスクリプト。 |
| LCP: 最大コンテンツの描画 | ビューポート内の大きなメインコンテンツが表示されたとき。 | レポートで特定された要素、およびその画像リクエストの開始、転送、表示の遅延。 |
| TBT: 総ブロッキング時間 | 読み込み中の長時間のメインスレッドタスクのブロッキング部分の合計。 | 長時間のJavaScript実行、不要な起動スクリプト、サードパーティコード。 |
| CLS: 累積レイアウトシフト | 予期せぬレイアウトの移動量。 | 予約スペースのない画像や広告、遅れて挿入された要素。 |
| スピードインデックス | 表示可能なコンテンツがどれだけ早く表示されるか。 | 初期表示の遅延期間を、視覚的な記録とともに考慮する。 |
TBT ドキュメンテーションでは、50ミリ秒を超えるタスクを「長いタスク」と定義し、50ミリ秒を超える分をブロッキング時間としてカウントします。TBTは、ユーザー操作に対する応答性に関するInteraction to Next Paint (INP)とは異なる指標です。実際のユーザーによるCore Web Vitals(LCP、INP、CLS)をフィールドデータで個別に確認してください。
レポートのインサイトと診断を展開して、影響を受ける要素やリソースを確認してください。初期ビューポート内の LCP 要素が画像である場合は、その転送サイズとリクエストのタイミングから始めます。大きなレイアウトシフトの場合は、画像や広告のためのスペースが確保されているかを確認してください。重要なファーストスクリーン画像を単に遅延読み込みしたり、すべてのスクリプトを同じ方法で遅延させたりすると、必要な表示や機能に悪影響を及ぼす可能性があるため、まず原因と使用状況を特定してください。
より詳しく調査するためには、ChromeのLighthouseおよびPerformanceパネルのガイドで説明されているように、Performanceパネルでの記録とInsightsを続けてください。高いAccessibilityやSEOスコアは、完全なアクセシビリティ準拠や高い検索ランキングを保証するものではありません。キーボードの使用や実際のコンテンツの質など、自動チェックでは検出できない事項もレビューが必要です。
一つの項目を変更し、同じ条件で再測定する
- ユーザーに大きな影響を与える問題で、具体的な原因があるものを一つ選んでください。例えば、最初のビューポートに表示される画像が大きすぎる場合、まず表示サイズに適した画像で試してみます。
- 元のファイル、設定、およびレポートを保持してください。変更はローカルまたはテスト環境で行い、デプロイ後にキャッシュが新しいファイルを配信することを確認してください。必要な機能を隠したり、監査だけに別のページを表示してスコアを上げようとしないでください。
- 同じURL、ログイン状態、デバイスモード、スロットリング設定で測定を繰り返してください。生の指標と、繰り返し実行の範囲や中央値を比較し、最良のスコアだけを見ないでください。例えば、条件ごとに5回実行する場合は、変更前と変更後の両方でその回数を使用してください。
- 対象の指標が改善され、レイアウト、ボタン、フォーム、およびキーボード操作がまだ機能していることを確認してください。変更が役に立たない場合や機能が壊れる場合は、保存したファイルと設定を復元し、別の原因を調査してください。
測定の変動性に関するガイドでは、ネットワーク、デバイス、サーバー、ページの変更により、コードが変更されていなくてもスコアが変わる可能性があることを説明しています。広告や同意バナーの状態も比較条件に含まれます。報告書には日時、URL、ツールのバージョン、設定、指標、変更内容を記録し、十分な収集期間とサンプルが揃った後に実ユーザーメトリクスを評価してください。
分析が失敗した場合、または結果が大きく異なる場合
ページの読み込みに失敗した場合、アクセスがブロックされている場合、またはリダイレクトが失敗する場合は、スコアを解釈する前に最終的なURLと正常なHTTPレスポンスを確認してください。外部のテストに対してプライベートページを公開するために認証を解除しないでください。ローカルでの測定の場合は、ログインとストレージのクリア設定を確認してください。拡張機能が関与している可能性がある場合は、拡張機能の影響が少ない環境で同じターゲットを再度テストしてください。
PageSpeed InsightsとPCのスコアの差は、必ずしも失敗を意味するわけではありません。まず、Lighthouseのバージョン、サーバーへのアクセス経路、デバイスおよびスロットリング設定、クッキーの状態を比較してください。モバイルとデスクトップのスコアを一致させようとしないでください。各条件内での変更前後を比較し、実際の訪問者の指標を考慮してください。




