【ITニュース解説】Why is PageSpeed Insights worse than my local Lighthouse score?

Webサイトのパフォーマンスを評価する上で、Googleが提供する「PageSpeed Insights」と、Chromeブラウザの開発者ツールに内蔵されている「Lighthouse」は非常に強力なツールである。しかし、同じWebサイトのURLを入力してパフォーマンススコアを計測すると、ローカル環境で実行したLighthouseのスコアが90点台なのに、PageSpeed Insightsでは60点台に落ち込む、といった現象が頻繁に発生し、多くのシステムエンジニア志望者や開発者を悩ませている。このスコアの大きな乖離は、どちらかのツールが間違っているわけではなく、それぞれの計測環境や条件が異なるために生じるものだ。ここでは、この違いがなぜ生じるのか、そしてどのように評価すれば良いのかを、システムエンジニアを目指す初心者にも分かりやすく解説する。

まず、PageSpeed InsightsとローカルLighthouseは、どちらもWebページのパフォーマンスを監査する「Lighthouse」という同じエンジンを利用している。しかし、そのエンジンが稼働する「機械（環境）」が根本的に異なる。PageSpeed Insightsのラボ（実験室）データは、Googleが管理する共有のサーバーインフラ上でLighthouseが実行される。一方、ローカルLighthouseは、開発者自身のノートパソコンやデスクトップPC上で実行される。この違いが、スコアの乖離の最大の原因となる。

開発者のPCは一般的に高性能であり、WebサイトのJavaScript処理などを高速に実行できる。しかし、PageSpeed Insightsの共有サーバーは、多くのリクエストを処理するために負荷が分散され、個々のWebサイトに割り当てられるCPU性能は、開発者のPCほど強力ではない場合が多い。さらに、PageSpeed Insightsはモバイル環境でのパフォーマンスを模倣するために、CPUに約4倍の処理速度低下（スローダウン）を適用する。これにより、たとえ同じLighthouseエンジンを使ったとしても、処理にかかる時間が大きく変わり、特にWebページが読み込まれる際に発生する「長いタスク」の処理時間に影響が出る。

この「長いタスク」の処理時間は、「Total Blocking Time（TBT）」という指標に特に敏感に影響する。TBTは、ページ読み込み中に50ミリ秒を超えてメインスレッドをブロックしたすべてのタスクの合計時間を指す。高性能なローカルPCでは、多くのタスクが50ミリ秒のしきい値をわずかに下回って完了するため、TBTは低く抑えられる。しかし、PageSpeed Insightsのような比較的低速な環境では、同じタスクが50ミリ秒を超えてしまい、TBTが大幅に増加する傾向にある。TBTはパフォーマンススコアに強く影響するため、TBTが跳ね上がると、たとえページの表示開始時間（First Contentful Paint）がほとんど変わらなくても、全体のパフォーマンススコアは大きく低下することになる。

また、Webサイトのネットワーク環境もスコアに影響を与える。PageSpeed Insightsは、Googleが設定した限られた地域の中からテストロケーションを選択する。一方、開発者のPCは、オフィスや自宅の光回線に接続され、コンテンツ配信ネットワーク（CDN）のエッジサーバーに近い位置にあることが多い。これにより、ネットワークの遅延（レイテンシ）も異なり、初期読み込み（コールドロード）時のデータ取得にかかる時間に差が生じ、これもスコアに影響を及ぼすことがある。

ローカルLighthouseのスコアがPageSpeed Insightsよりも高く出る別の理由は、開発者のローカル環境が持つ「汚染」にもある。Webブラウザにインストールされた拡張機能は、スクリプトを挿入したり、ネットワークの挙動を変えたりすることがある。また、一度アクセスしたWebサイトのデータがブラウザのディスクキャッシュやサービスワーカーに保存されていると、次に同じサイトを訪問した際に、一部の処理がスキップされ、読み込みが速くなる。クッキーバナーや同意レイヤーも、ローカル環境ではすでに承認済みで表示されない場合がある。さらに、アンチウイルスソフトやVPN、その他のバックグラウンドプロセスが、Webページの読み込みに影響を与えるノイズとなることもある。PageSpeed Insightsは、これらの影響がないクリーンな「コールドロード」（キャッシュなどの影響を受けない初回読み込み状態）でテストを実行するため、ローカル環境とのスコア差は必然的に大きくなる。

公正な比較を行うためには、こうした環境の違いを理解し、適切な方法で評価する必要がある。クライアントへの報告や、Webサイトの改善効果を測る際には、以下のような点を考慮すると良い。

まず、Webサイトの変更前と変更後を比較する際は、必ず「同じツール」で比較することが重要である。例えば、ローカルLighthouseで94点だったものが、変更後に88点になったのであれば、それは有用な変化の兆候となる。しかし、ローカルLighthouseで94点だったサイトが、PageSpeed Insightsで61点だったからといって、そのサイトが悪化したと結論付けるのは間違いである。それぞれのスコアは、異なる環境での結果であり、単純に並べて比較できるものではない。

次に、計測する環境の「戦略」を一致させるべきである。モバイル環境のパフォーマンスを計測するなら、ローカルLighthouseでもPageSpeed Insightsでもモバイル設定で計測する。デスクトップ環境ならデスクトップ設定で揃える。

また、公開するスコアや共有する基準を設定する際は、「コールドロード」を優先して計測する。ローカル環境で計測する際には、ブラウザのシークレットウィンドウを使用し、拡張機能をすべて無効にするか、Lighthouseのコマンドラインインターフェース（CLI）をクリーンなプロファイルで実行することが推奨される。これにより、ローカル環境の「汚染」を最小限に抑え、PageSpeed Insightsに近い状態での計測が可能になる。

PageSpeed Insightsには、Lighthouseの「ラボデータ」だけでなく、「Chrome UX Report（CrUX）」から取得される「フィールドデータ」も表示される。フィールドデータは、実際のChromeユーザーがWebサイトを訪問した際のパフォーマンスデータを集計したものであり、実際のユーザー体験を反映する。しかし、ローカルLighthouseが提供するのはラボデータのみである。ローカルのラボスコアを、PageSpeed Insightsのフィールドデータと比較するのは誤りである。フィールドデータは、実際のユーザーのデバイスやネットワーク、訪問状況（初回訪問か再訪問かなど）を総合的に反映したものであり、実験室のシミュレーションであるラボデータとは目的も計測方法も異なる。クライアントとのコミュニケーションで、どちらのデータを基準にするかを明確に合意しておくことが不可欠だ。

クライアントへの報告や、日々の開発における基準としては、PageSpeed Insightsのラボデータや、定期的に自動監視ツールで計測されたスコアなど、「安定した共有可能な基準」を優先することが推奨される。これにより、「私のPCとあなたのPCではスコアが違う」という議論を避け、全員が同じ基準でパフォーマンスを評価できるようになる。ローカルLighthouseは、開発中にWebサイトの特定の部分をデバッグしたり、改善効果を素早く確認したりするのに非常に役立つが、唯一の「真実の数値」として扱うべきではない。

PageSpeed InsightsがローカルLighthouseよりも「正確」であるとは一概には言えない。クライアントと共有するコールドロードの診断基準としてはPageSpeed Insightsが適しているが、開発中の高速な検証にはローカルLighthouseが効率的である。どちらのツールも、実際のユーザー体験を示すフィールドデータを補完する役割を担う。

まとめると、PageSpeed InsightsとローカルLighthouseのスコアが異なるのは、実行環境（CPU性能、ネットワーク）と、計測時の条件（コールドロード、拡張機能の有無など）が違うためであり、どちらが「嘘をついている」わけではない。システムエンジニアを目指す上では、この違いを理解し、目的に応じて適切なツールと計測方法を選び、一貫した基準でパフォーマンスを評価する能力が求められる。まずは一つのWebサイトを選び、クリーンな環境でローカルLighthouseとPageSpeed Insightsのラボデータをそれぞれ実行し、それぞれの結果と環境の違いを記録してみることが、理解を深める第一歩となるだろう。