ブログの表示が遅くて、直しました。
読み込むデータ量を9MB から 2.2MB まで減らしました。画像297枚を軽くして、余計なプラグインを止めて、重複していた設定を整理して。数字の上では、たしかに4分の1になりました。
それなのに——体感がまったく変わりませんでした。
開いても、やっぱり待たされる。何が足りないのか分からず、しばらく途方に暮れました。
結論から書きます。私は、測る場所を間違えていました。
本当の原因は、テスト用に設定して忘れていた1枚のダミー画像でした。それが読者を毎回20.9秒待たせていました。
数字は良くなっていたのに
作業を終えた時点で、私が確認していた数字はこうでした。
| 項目 | 作業前 | 作業後 |
|---|---|---|
| ページのデータ量 | 9MB | 2.2MB |
| サーバーの応答 | 555ミリ秒 | 105ミリ秒 |
| ページ本体 | 536KB | 163KB |
どれも大幅に改善しています。ここまで減らせば速くなるはずだ、と思っていました。
でも実際に開くと、遅い。数字と体感が、まったく一致していませんでした。
「ログインしているから遅いのかも」も外れ
管理画面にログインした状態だと、表示を速くする仕組みが効かないことがあります。それかもしれないと思い、シークレットウィンドウで開いてみました。
(Chromeなら Ctrl + Shift + N、読者と同じ条件で表示を確認できます)
結果は、同じく遅い。つまり読者にも遅く見えているということでした。
測り方を変えたら、一発で見つかりました
それまで私が見ていたのは、ページのソースと速度測定ツールの点数でした。
そこで、方法を変えました。実際にブラウザで開いて、読み込まれたもの全部を1つずつ時間つきで並べるという測り方です。
出てきた結果が、これでした。
| 読み込んだもの | かかった時間 |
|---|---|
| picsum.photos の 1000.jpg | 20,944 ミリ秒(20.9秒) |
| 2番目に遅いもの | 954 ミリ秒 |
| 3番目 | 944 ミリ秒 |
1位が突出しています。2位の22倍です。
ページ全体の読み込み完了までが22.7秒だったので、そのほとんどがこの1枚でした。
picsum.photos とは何か
これはダミー画像を配るサービスです。
デザインを作っている途中、まだ本番の写真が用意できていないときに、仮の画像として使います。「とりあえず、ここに何か画像を置いておきたい」というときに便利なものです。
つまりテスト用です。本番のサイトで使うものではありません。
どこに入っていたか
テーマの設定から出力されたCSSの中に、こう書かれていました。
#st-headerbox { background-image: url("https://picsum.photos/1200/1000.jpg"); }ヘッダーの背景画像として設定されていました。おそらく、サイトのデザインを整えていた時期に「仮でこれを入れておこう」としたまま、消し忘れたのだと思います。
なぜ気づけなかったのか
理由は3つありました。
1. 画面には何も表示されていなかった
読み込みに失敗していたので、背景は真っ白のまま。見た目には何の異常もありませんでした。
2. ページのソースを検索しても出てこない
ページの中身を「picsum」で検索しても、0件でした。CSSファイルの中に書かれていたので、ページ本体には現れなかったのです。
3. エラーも警告も出ない
管理画面にも、ブラウザの表示にも、何の警告も出ませんでした。ただ静かに、読者を20秒待たせていただけです。
もうひとつ見つかったもの
同じ測り方で、もう1つ大きなものが見つかりました。
絵文字が、外部サーバーの画像に置き換えられていました。
| 数 | 合計時間 | |
|---|---|---|
| 絵文字の画像リクエスト | 27個 | 11,453 ミリ秒 |
WordPressの標準機能でした
私はトップページのデザインに絵文字を使っていました。🏠 や 💻 のような、カテゴリーの目印です。
WordPressには、絵文字を画像に置き換える機能が最初から入っています。どんな環境でも同じ見た目になるように、という配慮です。
ただしその画像は、外部のサーバーから1つずつ読み込まれます。絵文字を27個使えば、27回の通信が発生します。
ここでも、ソースを見ただけでは分からなかった
ページのソースを見ると、絵文字はただの文字として書かれています。画像には見えません。
画像に置き換わるのは、ブラウザで開いたあとです。JavaScriptが動いて、文字を画像に差し替えます。
つまり、ソースを見る限りは何の問題もないのに、実際に開くと27回の通信が発生するという状態でした。
直した結果
2つを直しました。
- ダミー画像の指定を打ち消す(CSSを1行追加)
- 絵文字の画像置き換えを無効化(軽量なプラグインを1つ導入)
結果がこちらです。
| 項目 | 直す前 | 直した後 |
|---|---|---|
| 読み込み完了 | 22,770 ミリ秒 | 1,265 ミリ秒 |
| 最初の表示準備 | 1,887 ミリ秒 | 951 ミリ秒 |
| 最初に読み込むデータ | 約9MB | 106KB |
| 読み込むファイル数 | 81個 | 47個 |
18倍速くなりました。
そして今度は、体感もはっきり変わりました。開いた瞬間に表示されます。
自分のブログを実際に測る方法
ここが一番お伝えしたいところです。ソースを見るだけでは足りません。
パソコンがあれば、誰でもできます。難しい設定は要りません。
手順1 開発者ツールを開く
自分のブログを開いた状態で、キーボードの F12 を押します。画面の横か下に、文字がたくさん並んだ領域が出てきます。
見慣れない画面ですが、壊れることはありません。もう一度F12を押せば閉じます。
手順2 「ネットワーク」タブを選ぶ
上のほうに並んでいるタブから 「ネットワーク」(Network) をクリックします。
手順3 ページを再読み込みする
F5 を押してページを読み込み直します。すると、読み込まれたファイルが次々と一覧に出てきます。
手順4 時間の長い順に並べる
一覧の見出しに「時間」(Time)という列があります。そこをクリックすると、かかった時間の順に並び替えられます。
もう一度クリックすると、長い順になります。
手順5 一番上を見る
ここに、あなたのブログを遅くしている犯人がいます。
私の場合、1位が20.9秒、2位が0.9秒でした。1位だけが突出していたら、それが原因です。
ファイル名をクリックすると、どこから読み込まれているか分かります。
チェックしておきたいもの
一覧を眺めるとき、次のようなものが混ざっていないか見てください。
- picsum.photos / placeholder / dummy / example.com ← テスト用の名残
- 使っていないサービスの名前 ← 昔試して消し忘れたもの
- s.w.org ← 絵文字の画像(たくさん出ていたら要対処)
- 同じファイルが2回 ← 設定の重複
どれも、見た目には何の異常も出ません。
学んだこと
今回いちばん身にしみたのは、これです。
測る場所を間違えると、どれだけ改善しても速くならない。
私は画像を297枚も変換して、プラグインを整理して、設定の重複を消しました。その作業自体は、どれも正しいものでした。実際に転送量は4分の1になりました。
でも、本当の原因はまったく別の場所にありました。1枚のダミー画像です。
もし最初から実際のブラウザで測っていたら、10分で終わっていたかもしれません。
それでも、無駄ではなかったと思っています
とはいえ、先にやった作業が無意味だったとは思っていません。
ダミー画像を直したあと、最初に読み込むデータは106KBになりました。もし画像がPNGのまま9MBだったら、20秒の壁が消えても、まだ重いままだったはずです。
土台を整えたうえで、詰まりを取り除いた。そういう順番だったのだと思います。
まとめ
- データ量を9MB→2.2MBにしても、体感は変わらなかった
- 原因は、テスト用のダミー画像1枚(20.9秒)と絵文字27個(11.4秒)
- どちらもページのソースを見ても分からない
- 実際にブラウザで測ったら、一発で見つかった
- 結果、読み込み完了が22.7秒 → 1.27秒(18倍)
- 測り方は F12 →「ネットワーク」→ F5 →「時間」で並び替え
ブログが遅いと感じたら、まずF12を押してみてください。3分あれば、犯人の顔が見られます。
もしかしたら私と同じように、何年も前に置いたまま忘れていた何かが、静かに読者を待たせているかもしれません。
あわせて、今回の高速化で実際にやった作業はこちらにまとめています。










