データ量を4分の1にしても速くならなかった話【真犯人はダミー画像1枚でした】

ブログの表示が遅くて、直しました。

読み込むデータ量を9MB から 2.2MB まで減らしました。画像297枚を軽くして、余計なプラグインを止めて、重複していた設定を整理して。数字の上では、たしかに4分の1になりました。

それなのに——体感がまったく変わりませんでした。

開いても、やっぱり待たされる。何が足りないのか分からず、しばらく途方に暮れました。

結論から書きます。私は、測る場所を間違えていました。

本当の原因は、テスト用に設定して忘れていた1枚のダミー画像でした。それが読者を毎回20.9秒待たせていました。

数字は良くなっていたのに

作業を終えた時点で、私が確認していた数字はこうでした。

どれも大幅に改善しています。ここまで減らせば速くなるはずだ、と思っていました。

でも実際に開くと、遅い。数字と体感が、まったく一致していませんでした。

「ログインしているから遅いのかも」も外れ

管理画面にログインした状態だと、表示を速くする仕組みが効かないことがあります。それかもしれないと思い、シークレットウィンドウで開いてみました。

（Chromeなら Ctrl + Shift + N、読者と同じ条件で表示を確認できます）

結果は、同じく遅い。つまり読者にも遅く見えているということでした。

測り方を変えたら、一発で見つかりました

それまで私が見ていたのは、ページのソースと速度測定ツールの点数でした。

そこで、方法を変えました。実際にブラウザで開いて、読み込まれたもの全部を1つずつ時間つきで並べるという測り方です。

出てきた結果が、これでした。

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つ大きなものが見つかりました。

絵文字が、外部サーバーの画像に置き換えられていました。

WordPressの標準機能でした

私はトップページのデザインに絵文字を使っていました。🏠 や 💻 のような、カテゴリーの目印です。

WordPressには、絵文字を画像に置き換える機能が最初から入っています。どんな環境でも同じ見た目になるように、という配慮です。

ただしその画像は、外部のサーバーから1つずつ読み込まれます。絵文字を27個使えば、27回の通信が発生します。

ここでも、ソースを見ただけでは分からなかった

ページのソースを見ると、絵文字はただの文字として書かれています。画像には見えません。

画像に置き換わるのは、ブラウザで開いたあとです。JavaScriptが動いて、文字を画像に差し替えます。

つまり、ソースを見る限りは何の問題もないのに、実際に開くと27回の通信が発生するという状態でした。

直した結果

2つを直しました。

• ダミー画像の指定を打ち消す（CSSを1行追加）
• 絵文字の画像置き換えを無効化（軽量なプラグインを1つ導入）

結果がこちらです。

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分あれば、犯人の顔が見られます。

もしかしたら私と同じように、何年も前に置いたまま忘れていた何かが、静かに読者を待たせているかもしれません。

あわせて、今回の高速化で実際にやった作業はこちらにまとめています。