ブログの表示が遅いと診断されたら、診断のとおりに直せば速くなるのでしょうか？
私はブログをWordPress（ワードプレス）からAstro（アストロ）という新しい作り方へ引っ越しました。その時にページの表示速度をGoogleの無料の診断ツールのLighthouse（ライトハウス）で測りました。トップページは合格でしたが記事のページだけ「遅い」と診断されました。
診断の内訳（ファイルごとの時間などの細かい数字）を読んで原因を決めましたが、同じ日に見直すとその結論は成り立ちませんでした。診断の数字には計算で出した予想とそのまま測った数字が混ざっていたからです。この記事では診断の予想だった所と測り直した方法を書いています。
診断ツールの数字を信じて直せば速くなるのではないのかのう？
拙者もそう思ったでござる！ところが診断の数字は全部が測った数字ではなかったでござる
こんな方におすすめ
- ブログやサイトの表示速度を診断ツールで測っている方
- 診断の「こう直すと速くなる」をどこまで信じてよいのか迷っている方
- 速さの原因を調べても結論が毎回ばらつく方
全体像
この記事でやったことの流れです。
この記事でやった流れ
診断ツールでブログの表示速度を測る
診断の内訳を読んで原因を決める
決めた原因を測定の元データから見直す
通信を実際に絞って何回も測り直す
診断が示した数字と直した後の実際の差を比べる
記事のページだけ遅いと診断された
診断ではトップページは目安に収まりましたが、記事のページだけは目安を大きく超えました。測ったのはページの一番大きな部分が表示されるまでの時間です。
正式にはLCP（エルシーピー）といい、Googleは2.5秒以内を良い目安としています。スマホの設定で同じ手順を3回ずつ測りました。
| ページ | 3回の結果 | 目安（2.5秒） |
|---|---|---|
| トップ | 2.1〜2.2秒 | 収まった |
| 記事 | 9.8・10.1・3.5秒 | 超えた |
この3回の結果の扱いにもしくじりがありました。
しくじり
結果がばらついたのに3回の真ん中の値を速さだと書いた
- 症状: 同じページを3回測って9.8秒・10.1秒・3.5秒とばらついたが真ん中の9.8秒を「記事の速さ」と書いた
- 原因: 約10秒と3.5秒が混ざっていて3回ではどちらが普通の速さか見分けがつかなかった
- 避け方: 結果がばらついたら 回数を増やして並べてから速さを決める
- 今回のやらかし: 3回のうち1回は3.5秒だったのに9.8秒を決まった速さとして書いた
診断の内訳を読んで私が出した結論は2つです。1つ目は通信は原因ではないということでした。32個のファイルがどれも1.4秒以内に読み込み終わっていたからです。
2つ目は原因は広告なので直さなくてよいということでした。広告の処理が突出して長かったからです。この2つは同じ日に見直すとどちらも成り立ちませんでした。
診断の数字には計算した予想とそのまま測った数字が混ざっていた
診断ツールの標準の測り方は通信を実際には絞りません。速い回線で1回読み込んだ結果から計算で「遅い回線ならこうなる」と予想します。
これに対して「実際に絞る」測り方は、通信をわざと遅い回線と同じ速さに制限して測ります。走るタイムにたとえると次の違いです。
2つの測り方
標準の測り方
荷物なしで1回走る
「重い荷物を背負ったらこのくらい」と計算する
実際に絞る測り方
重い荷物を背負って走る
そのまま測る
表示時間や点数は計算した予想です。ところが内訳の数字の作り方は項目ごとに違っていました。
ファイルごとの読み込み時間は荷物なしで走った時のそのままの数字です。一方でプログラムの実行時間の一覧は、測った値を4倍にした数字でした。パソコンの処理能力を4分の1に落とした想定の計算です。
診断を作っているGoogleの説明でも、標準は計算で予想する方式とされています。測定の時に裏で取られる生の記録（トレース）の数字は、診断の結果と合わないとも書かれています。
私の測定結果にも、測った時の回線の速さが残っていました。待ち時間（データが行って戻る時間）はミリ秒（1000分の1秒）で表します。通信の速さは1秒に送れるデータの量で、Mbps（メガビット毎秒）という単位で表します。
| 回線 | 待ち時間 | 速さ |
|---|---|---|
| 診断の想定 | 150ミリ秒 | 約1.6Mbps |
| 実測（記事の3回） | 0〜6.7ミリ秒 | 約88〜111Mbps |
診断の内訳にあった「1.4秒以内に読み込み終わった」は、手元の速い回線での数字でした。遅い回線の数字ではないので、通信は原因ではないという根拠にはなりません。
しくじり
速い回線で測った時間を見て「通信は関係ない」と決めた
- 症状: 診断の表でファイルの読み込みが終わるまでの時間がどれも1.4秒以内だったので「通信は遅さの原因ではない」と書いた
- 原因: その時間はスマホの遅い回線ではなく手元の速い回線で測った数字だった
- 避け方: 時間の数字を見たら どんな回線で測った数字かを確かめる
- 今回のやらかし: 同じ報告書に手元の回線の速さが書いてあったのに通信は無関係と書いた
広告が原因という見立ては合格したページと比べると崩れていた
標準の方式の測定では、広告の重さは合格したトップページと遅いと診断された記事のページでほぼ同じでした。処理時間は広告のプログラムがパソコンを使った時間で、通信量は広告のデータの大きさです。
| ページ | 処理時間 | 通信量 |
|---|---|---|
| 記事（9.8秒の回） | 29.1ミリ秒 | 約224KB |
| 記事（3.5秒の回） | 30.9ミリ秒 | 約224KB |
| トップ（合格） | 29.8ミリ秒 | 約224KB |
広告が原因なら合格したトップページでも同じように遅くなるはずでした。実際に絞った測定でも、広告の処理時間は記事が中央値159ミリ秒でトップが139ミリ秒と近い値でした。
私が広告の証拠にした583ミリ秒は、プログラムの実行時間の一覧にあった数字でした。この数字は測った値の4倍で、実際に測ったのは約146ミリ秒です。
さらに3.5秒の回では、同じ一覧の中で大きな作業が広告の行ではなく記事のページ本体の行に載っていました。次の表の数字はどちらも測った値の4倍です。
| 回 | 広告の行 | ページ本体の行 |
|---|---|---|
| 9.8秒の回 | 583ミリ秒 | 74ミリ秒 |
| 3.5秒の回 | 78ミリ秒 | 593ミリ秒 |
2つの合計は657ミリ秒と671ミリ秒でほぼ同じです。同じ大きさの作業が「広告」の行に載った回と「ページ本体」の行に載った回があっただけで、広告の処理が増えたり減ったりしたわけではありませんでした。
しくじり
「広告のせい」と決めたが合格したページも同じ広告だった
- 症状: 診断の表で広告の処理に時間がかかっていたので「遅いのは広告のせいで直さなくてよい」と書いた
- 原因: 合格したトップページにも同じ広告が入っていて処理時間もほぼ同じだった
- 避け方: 原因を疑ったら 合格しているページでも同じ数字かを確かめる
- 今回のやらかし: 直せない広告のせいにして 原因探しを終えていた
通信を実際に絞って9回測り直すと遅いページは出なかった
通信とCPU（計算をする部分）を実際に絞って9回測り直すと、記事のページは9回とも2.2秒から2.8秒に収まりました。このページでは標準の方式の3回が約10秒と3.5秒に分かれたので、実際に絞る方式でも測りました。設定を1つ変えるだけでこの方式になります。
| 測り方 | 回数 | 表示時間 |
|---|---|---|
| 標準（計算で予想） | 3回 | 3.5秒〜10.1秒 |
| 実際に絞る | 9回 | 2.2秒〜2.8秒 |
中央値（順番に並べた真ん中の値）は2.28秒で、目安の2.5秒以内でした。目安を超えたのは9回のうち1回（2.83秒）だけで、9.8秒に近い値は1回も出ませんでした。同じ時に測ったトップページは3回とも1.8秒でした。
しくじり
確かめていない遅さを直そうとしていた
- 症状: 記事のページが9.8秒と出たので原因を探して直す作業を始めた
- 原因: 9.8秒は計算した予想で実際に絞って測ると中央値2.28秒だった
- 避け方: 直し始める前に実際に絞った測定でも本当に遅いかを確かめる
- 今回のやらかし: 直そうとしたページは実際に絞って測ると直す前から中央値で目安に収まっていた
診断が示した数字は直した後に縮んだ時間とは別物だった
診断は、アイコン用の部品が表示を約1.3秒止めていると示しました。ところが直した後に実際に縮んだのは0.23秒でした。これはアイコン部品の除去と画像4枚の軽量化を合わせた差です。
記事のページだけ、外部のサービスからFont Awesome（フォント オーサム）というアイコン用の部品を読み込んでいました。サイト全体を調べると、実際に使っていたアイコンは6種類だけでした。
実際に絞って測った9回の診断では、この部品の欄に中央値で「1,341ミリ秒」と出ていました。この数字は部品が表示を止めていた時間です。外せば同じだけ縮むという数字ではありません。
標準の方式の診断では793〜1,072ミリ秒でした。診断には別に「節約できる見込み」も出ます。9回の中央値は直す前が0.65秒で直した後が0.15秒でした。差は約0.5秒です。
6種類のアイコンはページ自前の設定で描く図形に置き換え、同じ日に画像4枚の軽量化も入れました。数字は記事のページが9回とトップページが3回の中央値です。
| 項目 | 直す前 | 直した後 |
|---|---|---|
| 表示時間 | 2.28秒 | 2.05秒 |
| 通信量 | 約1.08MB | 約0.71MB |
| 変えていないトップ | 1.82秒 | 1.77秒 |
診断の数字と、実際に縮んだ時間
アイコンだけの差は分けて測りませんでした。アイコン用の部品を外しても、9回のうち7回はページ自前の設定ファイルが約0.75秒の間だけ表示を止め続けていました。
当時の記録には1,341ミリ秒を「推定値」と書いて、実際の0.23秒と並べていました。
しくじり
待たせていた時間を「縮む見込み」だと記録に書いた
- 症状: 診断の表に部品の時間が1,341ミリ秒と出ていたので「推定値1,341ミリ秒に対して実際の改善は0.23秒」と記録した
- 原因: 1,341ミリ秒は部品が表示を待たせていた時間で縮む見込みは別の欄に出ていた
- 避け方: 数字を使う前に 診断の画面の列名で何の数字かを確かめる
- 今回のやらかし: 「見込み」と書いた数字が見込みではなく 待たせていた時間だった
では診断の数字は使えぬということかのう？
そうではないでござる！予想の数字と測った数字を分けて読めば役に立つでござる
診断を読む時の4つの決まり
診断の数字は、何を数えた数字かを分けて読むと役に立ちます。
- 点数と表示時間は計算した予想として読みます。内訳の時間は何を数えた数字かを確かめてから読みます。
- 原因を疑ったら合格したページの同じ数字と並べます。広告の処理時間は合格したページと同じでした。
- 値が大きく分かれたら中央値を出す前に回数を増やして並べます。私は3回で約10秒と3.5秒に分かれたので9回に増やしました。
- 「止めていた時間」や診断の「節約できる見込み」は、直した後に縮む時間とは別物です。直す前と後を同じ手順で測り、変えていないページも並べます。
4つ目には実例があります。ページが表示されたあとに操作へ反応できなかった時間の合計（TBT）は、9回の中央値で189ミリ秒から215ミリ秒へ増えて見えました。変えていないトップページも182ミリ秒から192ミリ秒へ同じ向きに動いていたので、並べなければ直したせいで悪くなったと書いていました。
再現手順
- Node.js（プログラムを動かす無料のソフト）を入れたパソコンで、測りたいページを次のコマンドで測ります。
--throttling-method=devtoolsが通信とCPUを実際に絞る指定で、標準の計算方式で測る時はこの指定を外します。
npx [email protected] "測りたいURL" --throttling-method=devtools --output=json --output-path=out.json --chrome-flags="--headless" --quiet- 同じコマンドを9回以上繰り返します。出力ファイルの名前は回ごとに変えて、各ファイルの
audits["largest-contentful-paint"].numericValue（ミリ秒）を並べて最小と中央値と最大を見ます。 - 直す前と後で同じ手順を行い、変えていないページも一緒に測って並べます。
デメリット・注意点
測ったのは引っ越し前の試験用アドレスの記事1ページで、対照のトップページは3回です。1台のパソコンでの測定なので、ページや機材が変わると数字は変わります。実際の読者の端末での数字は、2026年9月23日の時点で「データなし」でした。
実際に絞る方式は通信を細かく再現したものではなく近似です。Googleは、多くのサイトでは標準の計算方式が同程度かそれ以上に正確としています。実際に絞る方式は1回に約30秒かかり、9回で約4分半でした。
同じ朝のPageSpeed Insights（Googleの診断サイト）の公式画面では、トップページの表示時間は6.1秒でした。1回の結果でLighthouseの版は13.5.0です。手元のコマンド版（13.4.1）の2.1〜2.2秒とは結果が違いました。
公式画面は1回だけで版も違うので、手元の数字と同じ条件の比較ではありません。
最後に
診断ツールの標準の数字は計算した予想です。原因を探す時と直した効果を確かめる時は、実際に絞った測定も何回か並べます。
まずは診断で「節約できる見込み」が出た項目を1つだけ直し、直す前と後を同じ手順で9回ずつ測って実際の差を見てみてください。
詳しい仕組みはLighthouseの公式文書にあります。
