【高速化】 画像サーバーを変更すると、表示が 0.6 秒 早くなる!
Web ページ の表示速度を上げたい場合、画像を圧縮したり解像度を下げたりするのが一般的です。しかし、遅い原因が別にある場合は、この方法では改善できません。今回、Google Blogger の画像表示の ボトルネック を検証しました。そして対策を取ることで、ページの表示を 0.6 秒 短縮することができました。具体的な原因と対策を紹介します。

ポイント
- Blogger の 新画像サーバーは遅い
- 旧画像サーバー を利用する
- 外部サーバーを利用する
はじめに
ページを早く表示するには、どうすれば良いだろうか?
今回は Google Blogger の画像表示のボトルネックを検討した。それを踏まえて書き手が採った対策を紹介する。
実際のところは 、Blogger の新画像サーバーがボトルネックになっている。高速化するには他のサーバーを利用するしかない。
検証の方法
今回の検証では、Chrome の開発者ツール(パソコン の F12)を利用した。対象のページは、このサイトを再現したテストブログで行った。
開発者ツールの詳細については、Google の公式ページを参照して頂きたい。
画像表示のプロセス
画像のは次の順序で表示される。
① ページの読み込み
② 画像の読み込み
③ 画像の描画
それぞれ図の ①②③ に対応している。

画像を表示するまでにかかった時間が LCP(Largest Contentful Paint )で、この値が小さいほど ページ が快適に表示される。
① と ② は、さらに 接続時間・サーバー待機時間・ダウンロード時間 に分かれる。上の図の色の薄い部分が待機時間、濃い部分が実際のダウンロード時間に相当する。
見た感じ、色の薄いサーバー待機時間がかなり長い。
それぞれについて 11回 測定して中央値を求めてみた、
実際の測定値
グラフの青色の部分が ページの読み込み、緑色の部分が画像の読み込み に相当する。LCP をみると、描画の終了まで 2秒弱 かかっている。
ページの読み込み
まず、ページの接続にかかる時間を見ると、モバイル が PC より 0.5 秒 長い。これは Blogger の仕様で、モバイル は モバイル用ページ に リダイレクト されてしまうからである。
サーバー待機時間でいくらか取り戻すが、ページの読み込みは 0.2秒 遅れていて、そのまま LCP も遅れている。
画像の読み込み
画像の読み込みは、ブラウザが画像のリンクを見つけた時に開始される。実際のタイミングは、ページ読み込み終了の少し前になる。

画像の読み込み時間をみると、そのほとんど 0.6秒 近くをサーバー待機の時間が占めている。実際のダウンロード時間は 0.1秒 もない。
今より 画像を圧縮したり解像度を下げたりしても、実際の転送時間はほとんど変わらない ことになる。
また、今回の計測からすると、解像度を 2倍 に上げても転送は 0.3 秒 以内に終了する。
画像サーバーの変更
読み込みの大部分を占めるサーバーの待機時間は、こちらではどうすることもできない。解決するには、サーバーを変更するしか無い。
今回、乗り換え先として2つのサーバーを試してみた。
Blogger の旧画像サーバー
Blogger では 2021年 まで旧画像サーバーが使われていた。こちらはかなり高速に画像を表示できたようである。
今でも、下の mizusame さんの記事の方法で、旧サーバーの 画像URL を取得することができる。
参考:mizusame さんの サイト

【Blogger】旧仕様の画像 URL を取得する
Blogger の画像 URL が 1.bp.blogspot.com から blogger.googleusercontent.com に変更されました。 新仕様の URL にはいろいろと問題があるようで、こちらの記事に書かれている方法で旧仕様の URL を取得していま...
現在、記事のページで書き込んだ URL は自動で新サーバーに変更されてしまうが、固定ページとテンプレート に書き込んだ URL は変更されずに残っている。
そこで、テストブログ の トップページ で新旧画像サーバーを比較してみた。
新旧画像サーバーの比較
驚いたことに、旧画像サーバーの待機時間はほぼ ゼロ になっている。0.6 秒分、そのまま LCP が短縮している。
なお、最初の画像の読み込み開始も早くなっているが、11回の測定で全体的に同じ傾向だったので、測定した時間帯の回線の混み具合の影響かと考えている。
旧画像サーバーの性能は申し分ないが、残念ながら使える対象が限られる。実際に使用できるのは、固定ページとトップページの画像、さらにファビコン・ロゴ・ウィジェット ぐらいになる。
それでも、これらの画像の表示はサイト全体の印象に大きく関わるので、使える範囲で旧画像サーバーを利用するのは有効な方法になる。
外部サーバー
続いて投稿ページの速度の向上を狙って、外部のサーバーを試してみた。
書き手を含めて、Blogger ユーザー のほとんどは自前のフアイルのアップロード場所を持っていない。
いろいろ探して、無料で利用できるサーバーを見つけることができた。

h3zjp Media Uploader
画像やファイルを直リンクにできるアップローダーです。ルールを守ってご自由にお使い下さい。
こちらのサーバーは個人サーバーで、管理人さんが自分で使用するための機能を拡張して提供している。誰でも無料で利用できて、アカウントの登録も必要ない。
ただし個人提供のサービスのため、管理人の都合でサービス終了があり得ることが明記されている。
また、公開のアップロード場所なので、アップロードしたファイルは著作権を放棄したものとみなされる。
アップロードしたファイルは原則的に削除を受け付けていないため、プライベートな画像での利用は避けたほうが良い思われる。
実際の転送速度
こちらの サーバー は Cloudflare を導入されており、速度も申し分ない。LCP も 1秒 程度 まで短縮している。
このサイトでは、記事のページの最初の画像にこちらを利用させてもらうことにした。
3つのサーバーの比較
単位(ミリ秒) | 新画像サーバー | 旧画像サーバー | ul.h3zip |
---|---|---|---|
画像読み込み開始 | 1,040 | 853 | 812 |
接続 | 96 | 114 | 18 |
サーバー待機 | 615 | 1 | 57 |
ダウンロード | 40 | 16 | 23 |
画像の読み込み完了 | 1,790 | 984 | 910 |
LCP | 1,871 | 1,020 | 966 |
各サーバーの測定結果を、表にまとめるとこのようになる。
サーバーを変更すると、待機時間の減少がそのまま LCP の減少 につながっている。
ダウンロード時間も短くなっているので、容量の大きい画像を使用した時にさらに差が出るかもしれない。
サーバーを変更する問題点
サーバーの変更には、いくつか問題点がある。
1つ目は、今回紹介したサーバーはいずれも、将来的にサービスの停止があり得ることである。ある日突然、サイトの画像が表示されなってしまう可能性がある。
2つ目は書き手が利用している JetTheme 特有の問題で、外部サーバーの画像はサムネイル画像として認識しない問題点がある。
これらについて、書き手は画像の差し替えと noscript 画像の挿入で対応することにした。
その方法について、次回紹介したいと思う。