はじめに
先日、PageSpeed Insightsのパフォーマンススコア向上を目指して改善に取り組んだところ、多くの落とし穴にハマりました。
「なぜかスコアが上がらない」
「この数値は何を意味するのか？」
本記事では、私が実際にその中で知ったPageSpeed Insightsの読み解き方を共有します。
対象とする読者
- PageSpeed Insightsの指摘を元にWebサイトを改善しようとしている人
- PageSpeed Insightsのことを簡単に知っている人
- (具体的な改善方法は扱いません)
PageSpeed Insightsとは
Googleが提供するWebパフォーマンス計測ツールです。
URLを入力するだけで、そのページの読み込み速度やユーザー体験に関する様々なメトリクスを確認できます。
PageSpeed Insights
PageSpeed Insightsではパフォーマンス、ユーザー補助、おすすめの方法、SEOの4点のスコアが出力されますが、ここではパフォーマンスのみを取り扱います。
最初に理解しておきたかったこと
PageSpeed Insightsの改善活動を始める前に、改善活動を実施する全員が理解しておきたかったことを記載します。
改善対象はモバイルと考えた方がいい
Google 検索セントラル - モバイルサイトとモバイルファースト インデックスに関するおすすめの方法
Google のインデックス登録とランキングでは、スマートフォン エージェントでクロールしたモバイル版のサイト コンテンツを使用します。これをモバイルファースト インデックスと呼びます。
PageSpeed Insightsではモバイル/デスクトップの2種類のスコアが出力されますが、モバイルファーストの視点に基づいて、改善対象はモバイルと定義した方がいいです。
レスポンシブを採用しているサイトであれば、モバイルを改善すれば自動的にデスクトップも改善されることが多いので、この定義で基本的に問題ないと思います。
PageSpeed Insightsの測定環境を理解する
スコアの下部に記載されている内容を読み解きます。
重要なのは3箇所です。
計測環境は通信状態が悪い
最初、「計測結果の秒数が長すぎる。なんでそんなに時間がかかってるの？」と思いましたが、それの答えがここです。
Moto G Power のエミュレーション with Lighthouse 12.6.1低速 4G スロットリング
「モバイル + 通信状況が悪い」という環境下で測定されており、その中でもストレスなく表示されることを目指す必要があります。
開発に関わる人は高速な環境からアクセスすることが多く、忘れてしまいがちな観点でもありました。
最初のページ読み込み速度がスコアに反映される
以下の記述も重要です。
最初のページ読み込み
Webページは初回にキャッシュを作ることによって2回目以降の読み込みが速くなることが多いですが、これはスコアには影響しません。
例えばCache-Controlなどの調整は重要ですが、スコア向上とは別の観点で実施した方がいいでしょう。
Chromeの開発者ツールで近い状況を再現する
以下の画像のように設定することでPageSpeed Insightsの測定環境に近い状況を再現することができます。
ただし、これ以外の様々な環境要因の影響も大きく、同じ測定環境をローカル上に作ることは難しいようです。
PageSpeed Insightsには測定誤差がある (測定するたびに結果が変わる)
全く同じソースコードでほぼ同時に測定したとしても、スコアに差異があることがあります。
これはサーバの負荷状況、ネットワーク環境、Google側のエミュレータの状況などによるものなので、安定させる方法はありません。
「前回と今回を比較したところ、スコアが5点上がったので改修が成功した」と考えるのは誤った判断に繋がるかもしれません。
対策例としては、スコアを複数回計測し、平均値や中央値を採用することで測定誤差を低減するなどが考えられます。
Lighthouseのドキュメントにもスコアが安定しない原因についての記載がありました。
Lighthouse のパフォーマンス スコアリング
全体的なパフォーマンス スコアと指標の値が変動する主な原因は、Lighthouse ではありません。パフォーマンス スコアが変動する原因は、通常、基本的な状況の変化にあります。一般的な問題には次のようなものがあります。
- 配信される広告の A/B テストや変更
- インターネット トラフィックのルーティングの変更
- 高性能なデスクトップ パソコンや低パフォーマンスのノートパソコンなど、さまざまなデバイスでのテスト
- JavaScript を挿入したり、ネットワーク リクエストを追加または変更したりするブラウザ拡張機能
- ウィルス対策ソフトウェア
パフォーマンススコアは加重平均で計算される
Lighthouse のパフォーマンス スコアリング
パフォーマンス スコアは、指標スコアの加重平均です。必然的に、指標の重み付けが大きくなるほど、パフォーマンス スコア全体に対する影響も大きくなります。
パフォーマンススコアは以下の5点の指標を元に計算されます。
| 指標 | 加重 |
|---|---|
| FCP (First Contentful Paint) | 10% |
| SI (Speed Index) | 10% |
| LCP (Largest Contentful Paint) | 25% |
| TBT (Total Blocking Time) | 30% |
| CLS (Cumulative Layout Shift) | 25% |
これはPageSpeed Insightsのスコアにホバーすることで見ることもできます。
改善案の選択を迷っているようでしたら、比重が高いTBTの改善を優先した方がいいことになります。(修正は相互に関連してくるので、この基準だけで決められないことの方が多いと思いますけれど)
速度とスコアは対数関数(log)の関係になっている
Lighthouse のパフォーマンス スコアリング
Lighthouse のスコアリング曲線モデルでは、(中略)、そこから対数正規曲線の形状を設定します。
当初の私は「4秒から2秒に減らせば、スコアは2倍になるはずだ」と思っていたのですが、誤りでした。
Lighthouse スコア計算ツールを使用して所要時間とスコアの関係性を読み解いてみます。
FCP (First Contentful Paint) のスコア対応表
| FCPまでの表示速度（秒） | 6.0 | 5.0 | 4.0 | 3.0 | 2.0 | 1.0 |
|---|---|---|---|---|---|---|
| スコア | 4 | 10 (+6) | 24 (+14) | 50 (+26) | 85 (+35) | 100 (+15) |
※ ここではFCPを例として扱いますが、他の指標も同様です。
スコア対応表の読み解き方
- 同じ1秒の高速化でも「6秒から5秒」と「5秒から4秒」ではスコアの上がり方が違う
- 成果はスコアだけでなく速度・時間も見た方がいい
- 「10秒を6秒に高速化」を実施しても、スコアにほとんど寄与しない
- この時の修正を「スコア変化なし＝失敗」と思ってはいけない
- 「これでスタートラインに立つことができた。今後の改善でスコアがどんどん上がっていくはず」と考えた方がいい
調査・検討時に念頭に置いておきたかったこと
スコアアップに向けて改善プランを立てようとした際、うまく進められなかったことがありました。
振り返ってみて大切にするべきだったと感じる考え方を記載します。
推測するな、計測せよ
Webページに限らず、あらゆるパフォーマンス改善の文脈 (例えばサーバやプログラムコードの高速化など) でよく登場する言葉です。
実際に改善活動の中で推測が外れることは多くありましたし、PageSpeed Insightsの指摘通りに修正してもスコアが向上しないこともありました。
スコアが全てではありませんが、スコアを改善対象とするなら実際の計測結果に視点を置いて修正方針を考えなければいけません。
80:20の法則 (パレートの法則)
これもパフォーマンス改善の文脈でよく登場する言葉です。
言葉の定義は「一部の原因(20%)によって結果の多く(80%)が決まるという経験則」と解説されていて、今回の内容だと「一部のボトルネックの改修が全体の改善に繋がる」くらいの解釈でいいと思います。
私の経験則としてもこれが当てはまることは多く、この観点で原因を調査することはとても大切と感じています。
ボトルネックを解消しなければスコアは上がらない
これだけは有名な格言ではありませんが、覚えておきたい考え方です。
例えばFCP (First Contentful Paint) の場合、画面に表示される全要素のレンダリングが完了したタイミングをFCPの完了時間とします。
ここで重要なのは"全要素のレンダリング"という部分です。
下記のように並列に実行される処理A、B、Cがあった場合、AやCを改善してもスコアは改善されません。
# 改善前
処理A (開始)===========>(完了)
処理B (開始)==============>(完了)
処理C (開始)=======>(完了)
→ スコア50点
# 改善後 (処理A、Cを改善)
処理A (開始)==>(完了)
処理B (開始)==============>(完了)
処理C (開始)===>(完了)
→ スコア50点 (処理Bが変わっていないため向上しない)
このケースの場合、スコアだけでなく実際のユーザビリティにも影響がある可能性が高く、処理Bを改善することはとても重要と言えます。
改善した成果の記録
作業結果としてスコアが上がっていくのは嬉しいもので、モチベーション向上に繋がります。
そのため、スコア改善を始める前にスコアの記録を取り始めておいた方がいいでしょう。
GASを使用して日々のスコアを記録する
過去のスコアを取得するオフィシャルな方法は存在しないようです。
そのため以下の私の記事のように、スコアを毎日記録するGASを作って運用していくのがオススメです。
私が先日関わった改善活動では、GASを深夜に複数回実行し、その中央値を改善活動の成果と定めていました。
CrUX Visを参照して実際のユーザー環境の推移を参照する
スコアではなく実際のユーザー環境の評価になりますが、PageSpeed Insightsの画面内からリンクされている以下のサイトを参照するというのも手段です。
ここに表示されるのはPageSpeed Insightsの実際のユーザーの環境で評価するの時系列版と捉えていいと思います。
ただし、アクセス数が十分にあるページしか掲載されないとのことで、PageSpeed Insightsで「ウェブに関する主な指標の評価」が表示されたとしてもCrUX Visでは表示されないことも多いようです。
また、実際のユーザー環境での評価しか表示できないので、PageSpeed Insightsのスコアが知りたい場合、やはりGASなどでの独自実装が必要になります。
おわりに
スコアの改善活動を開始する前の自分に向けて、知っておきたかったことを書いてみました。
同じような活動を実施する方のお役に立てたらと思います。