Lighthouse レポートを慌てずに読む方法
パフォーマンス監査で本当に重要な点と、安全に無視できる点を理解するための実践ガイド
目次
最初のルール：スコアはサイトそのものではない
初めて Lighthouse レポートを開くと、数字の壁、色分けされたボックス、聞いたこともない項目への警告が目に入ります。自然な反応は、慌てることです。スコアが赤い。失敗した監査が 17 個もある。きっとサイトが壊れているのでは？
おそらく、そうではありません。Lighthouse は診断ツールであり、成績表ではありません。スコアはラボ条件下で実行される合成ベンチマークです。多くの場合、スロットリングされた接続で、2017 年ごろのミドルレンジのスマートフォンをシミュレートしています。それが示すのは、その特定のシナリオでサイトがどう動くかであり、実際のユーザーが現実の環境でどう体験するかではありません。
これが重要なのは、多くのチームがスコアに固執し、文脈を見落とすからです。リアルタイムデータを扱う複雑な Web アプリなら、65 点でも問題ないかもしれません。逆に 95 点でも、最適化している対象を誤っていれば、体験は悪いままかもしれません。スコアは調査の出発点であって、成功指標ではありません。
最初に読むべきもの：Core Web Vitals
全体のパフォーマンススコアはいったん飛ばします。Metrics セクションまでスクロールし、3 つの数値を見てください。Largest Contentful Paint (LCP)、Cumulative Layout Shift (CLS)、Interaction to Next Paint (INP) です。これらが Core Web Vitals であり、Google がランキングシグナルとして使う唯一のパフォーマンス指標です。
- LCP は、表示領域内で最大の要素が描画されるまでの時間を測ります。目標：2.5 秒未満。4 秒を超えている場合、ユーザーは意味のあるコンテンツを見るまで長く待たされています。
- CLS は視覚的な安定性、つまり読み込み中にページがどれだけ動くかを測ります。目標：0.1 未満。0.25 を超えている場合、ボタンが動くことでユーザーが誤って別のものをクリックしている可能性があります。
- INP は応答性、つまりクリック、タップ、キー入力にページがどれだけ速く反応するかを測ります。目標：200ms 未満。500ms を超えている場合、サイトはもたついて感じられます。
この 3 つの指標は、実際のユーザーの不満と相関します。他のことを気にする前に、まずこれらを修正しましょう。
Opportunities と Diagnostics：違いを理解する
Lighthouse は検出結果を Opportunities と Diagnostics の 2 つのカテゴリに分けます。Opportunities は、推定される時間短縮効果の順に並びます。Diagnostics は追加の文脈であり、問題かもしれないし、そうでないかもしれない項目です。
まず Opportunities から見ます。Lighthouse が「Eliminate render-blocking resources」により 1.2 秒節約できると言っているなら、それは具体的な改善余地です。一方、「Reduce unused JavaScript」による節約が 0.1 秒なら、おそらくリファクタリングするほどの価値はありません。
Diagnostics はもう少し扱いが難しいです。「Avoid an excessive DOM size」は悪く聞こえますが、CLS が問題なく INP も速いなら、大きな DOM は誰にも害を与えていないかもしれません。Diagnostics は手がかりであり、命令ではありません。実際の指標と合致するものを調査しましょう。
通常は無視してよい監査
Lighthouse の警告の中には、過去の名残だったり、過度に厳しかったりするものがあります。不要な不安を最も生みやすい項目は次のとおりです。
- 「Does not use passive listeners to improve scrolling performance」 — これは、効果が出ることの少ないマイクロ最適化です。スクロールがカクついている証拠がない限り、飛ばして構いません。
- 「Image elements do not have explicit width and height」 — CLS には関係しますが、画像がレイアウトシフトを引き起こしている場合に限ります。CLS がすでに良好なら、監査のためだけにリファクタリングする必要はありません。
- 「Serve images in next-gen formats」 — 確かに WebP や AVIF は小さくなります。しかし画像がすでに最適化されており、LCP も速いなら、これは危機ではなく「あるとよい」程度です。
- 「Avoid enormous network payloads」 — Lighthouse は 1.6 MB を超えるものをフラグします。しかし、高速に読み込まれる 2 MB のページは、描画をブロックする 500 KB のページより優れています。合計サイズだけでなく、バイトが どのように 配信されるかに注目してください。
すべてが赤いときにすること
Lighthouse スコアが 50 未満で、ほとんどの監査が失敗している場合、たいてい次の 3 つの根本原因のいずれかです。
- 最適化されていないフォント。 Web フォントは今でも多くのサイトで最も簡単に得られるパフォーマンス改善です。2 つしか使っていないのに 6 種類のフォントウェイトを読み込んでいないか、WOFF2 ではなく WOFF ファイルを配信していないかを確認してください。
- 描画をブロックする CSS と JavaScript。 First Contentful Paint (FCP) が 3 秒を超えている場合、ブラウザの描画を何かが妨げています。
<head>内の大きな CSS ファイルや同期スクリプトを探してください。 - 大きすぎる画像。 LCP 要素が画像で、それが 4 MB なら、それが問題です。圧縮し、ファーストビューより下の画像を遅延読み込みし、レスポンシブ画像の構文を使いましょう。
これらのうち 1 つを修正して、Lighthouse を再実行します。20〜30 点上がることも珍しくありません。その後、次の項目に取り組みます。
ラボデータとフィールドデータ：現実確認
Lighthouse はラボで実行されます。遅い接続と遅いデバイスをシミュレートしますが、実際のユーザー行動、つまり人々がどうスクロールするか、何をクリックするか、不安定な Wi-Fi 上にいるかどうかまではシミュレートできません。
現実確認として、Lighthouse の結果を Chrome User Experience Report (CrUX) の フィールドデータ と比較してください。CrUX は、過去 28 日間に実際の Chrome ユーザーがサイトをどう体験したかを示します。Lighthouse では LCP が 4 秒でも、CrUX では 2 秒なら、CrUX を信頼してください。両方とも悪いなら、本当に問題があります。
CrUX データは PageSpeed Insights（Lighthouse の Web 版）や、Google Search Console の「Core Web Vitals」で確認できます。食い違いがある場合は理由を調べましょう。実際のユーザーはより高速なネットワークを使っているのかもしれません。Lighthouse が最適化されていない開発ビルドをテストしているのかもしれません。
Lighthouse を再実行するタイミング
Lighthouse にはばらつきがあります。同じページでも 3 回連続で実行すれば、3 つの異なるスコアが出ます。これはパフォーマンスが変動するためです。バックグラウンドプロセス、ネットワークの揺らぎ、ブラウザのヒューリスティックがすべて結果に影響します。
安定したベースラインを得るには、すべての拡張機能を無効にした シークレットモード で Lighthouse を実行するか、より一貫した結果を得るために --preset=desktop フラグ付きの CLI を使います。3 回実行してスコアを平均してください。大きな変動（10 点以上）が見られる場合は、別の問題があります。サーバーが遅いのか、ページが毎回異なるリソースを読み込んでいるのかもしれません。
大きな変更を加えた後は、毎回 Lighthouse を再実行します。新しいフォント戦略をデプロイしましたか？ LCP を確認します。画像を遅延読み込みしましたか？ CLS を確認します。サードパーティスクリプトを追加しましたか？ INP を確認します。パフォーマンスは一度きりの修正ではなく、守り続ける予算です。
Lighthouse の指摘を実行に移すためのツール
Lighthouse は、何が 遅いかを教えてくれます。しかし、それを どう 直すかを常に教えてくれるわけではありません。そのためには追加のツールが必要です。
- WebPageTest は、ページの読み込みをフレーム単位で見られるフィルムストリップビューを提供します。LCP や CLS の問題を診断するうえで不可欠です。
- Chrome DevTools Performance panel は、どの JavaScript がメインスレッドをブロックしているかを正確に示します。悪い INP スコアの原因を見つけるために使います。
- Image compressor tools を使うと、ブラウザ内で直接画像を最適化できます。サードパーティサービスにアップロードするより速く、プライバシー面でも優れています。Client-side image processing is a privacy win なのは、画像があなたのマシンから外に出ないためです。
Lighthouse は出発点です。これらのツールが、作業を最後まで進める助けになります。
重要なポイント
- Lighthouse スコアはラボベンチマークであり、現実世界のユーザー体験を測るものではありません。慌てる前に、CrUX のフィールドデータと比較しましょう。
- まず Core Web Vitals (LCP, CLS, INP) に集中してください。これらはユーザーの不満や SEO への影響と相関する指標です。
- Opportunities は推定される時間短縮効果で優先順位を付けます。実際のパフォーマンス問題と一致しない Diagnostics は無視しましょう。
- passive listeners や次世代画像フォーマットのような一部の監査は、マイクロ最適化です。まず大きな問題を修正してください。
- Lighthouse は 3 回実行し、結果を平均します。パフォーマンスは変動するため、1 回の実行だけでは誤解を招くことがあります。
FAQ
Q: Lighthouse スコアが実行するたびに変わるのはなぜですか？
A: Lighthouse は、ネットワーク速度、CPU 負荷、ブラウザのヒューリスティックなど、変動する条件下でパフォーマンスを測定します。より安定したベースラインを得るには、シークレットモードで 3 回実行し、スコアを平均してください。
Q: モバイルとデスクトップのどちらを先に最適化すべきですか？
A: モバイルです。Web トラフィックの多くはモバイルであり、モバイルデバイスはより遅いため、Lighthouse はデフォルトでモバイルシミュレーションを使います。モバイルスコアが良ければ、通常デスクトップスコアも問題ありません。
Q: Lighthouse スコアは 95 ですが、サイトはまだ遅く感じます。何が問題ですか？
A: Lighthouse が測るのはページ読み込みであり、読み込み後のインタラクティビティではありません。INP スコアを確認し、Chrome DevTools Performance panel を使って、ユーザーがクリックやスクロールをしたときに何が起きているかをプロファイルしてください。Lighthouse が検出しない JavaScript の問題があるかもしれません。
Q: 完璧な 100 点は必要ですか？
A: いいえ。90 点以上は非常に優秀です。100 点を追いかけると、ユーザーにとって重要でないものを最適化しがちです。LCP、CLS、INP という実際の指標に集中し、スコアそのものは無視しましょう。
Q: サードパーティスクリプトを多く使っている場合、Lighthouse を信頼できますか？
A: Lighthouse はサードパーティスクリプトを問題としてフラグしますが、必要なものと不要なものを常に区別できるわけではありません。「Avoid enormous network payloads」と「Reduce JavaScript execution time」の監査を使って最も影響の大きいものを特定し、維持する価値があるかを判断してください。
Sources
- "Lighthouse performance scoring" — Google Developers
- "Core Web Vitals" — web.dev
- "Chrome User Experience Report" — Google Developers
- "WebPageTest Documentation" — WebPageTest.org
よくある質問
Lighthouse スコアが実行するたびに変わるのはなぜですか？
モバイルとデスクトップのどちらを先に最適化すべきですか？
Lighthouse スコアは 95 ですが、サイトはまだ遅く感じます。何が問題ですか？
完璧な 100 点は必要ですか？
サードパーティスクリプトを多く使っている場合、Lighthouse を信頼できますか？
参考文献＆さらなる読み物
