実例に学ぶサイトスピード改善(2) 画像は次世代フォーマットに移行する

Lighthouseのレポートを開くと、ほぼ必ずといっていいほど「次世代フォーマットの画像を使用してください」という指摘が並ぶ。そして世の中には「画像を軽くすればLCPが改善する」という解説も多い。

だが弊社の立場は少し違う。画像を次世代フォーマットにしても、LCPがそこまで改善するわけではない、というのが実情だ。LCPの時間はその前段のFCP（最初のコンテンツが表示されるまでの時間）でほぼ決まってしまう。しかも画像はダウンロードにかかる時間よりも「ダウンロードがいつ始まるか」のほうが効く。だから画像を軽くしてLCPが目に見えて良くなるのは、実はかなりのレアケースだ。

とはいえゼロではない。画像が極端に重いサイトでは、軽量化で読み込みプロセスが改善し、結果としてLCPまで縮む例も実際に存在する。この記事では、その数少ない実例を紹介しつつ、次世代フォーマット化が本来効くところ、つまり転送量の削減を、実在サイトのデータとともに整理する。

画像の最適化はLCPより転送量削減のため ​

Webページを構成するリソースには、HTML・CSS・JavaScript・画像・フォントなどがある。その中で、転送量という観点から最も大きな割合を占めやすいのが画像だ。

テキスト系のリソース（HTML/CSS/JS）はGZIPやBrotliで圧縮すれば元サイズの10〜30%程度まで転送量を抑えられることも多い。一方で画像はすでにバイナリ形式の圧縮済みデータであり、テキスト圧縮の恩恵が受けにくい。ページ上の画像の枚数や解像度が増えれば、それがほぼそのまま転送量に反映される。

出典: HTTP Archive Web Almanac 2022（Page Weight）

では LCP はどうか。「画像を軽くすればLCPが改善する」とよく言われるが、そう単純な話ではない。LCP（Largest Contentful Paint）は最も大きなコンテンツが表示されるまでの時間で、その大半が前段の FCP（最初のコンテンツが表示される時間）で決まってしまう。さらに画像は、転送そのものにかかる時間よりも「ダウンロードがいつ始まるか」のほうが効く。結局、画像のファイルサイズを小さくしてLCPが目に見えて縮むのは、もともと画像が極端に重く、転送時間がボトルネックになっているような限られた状況だけだ。多くのサイトで次世代フォーマット化が効くのはLCPではなく転送量のほうである。

転送量を減らす意味は体感速度だけにとどまらない。近年はAWSをはじめ、データ転送量に応じて課金するクラウドサービスの利用が増えている。配信する画像が重いほど、その転送量はそのままクラウドの料金に跳ね返る。つまり画像の最適化は、いまやクラウド費用を抑える手段としてこそ現実的な意味を持つ。

次世代フォーマットAVIFとWebP ​

JPEG/PNGに代わる「次世代フォーマット」の代表が、AVIFとWebPだ。どちらも同じ画質をJPEG/PNGより小さいファイルで表現でき、非可逆・可逆の両方の圧縮に対応する。AVIFのほうが圧縮率は高いが、そのぶんエンコードに時間とマシン負荷がかかる。WebPは主要ブラウザにほぼ対応済みで、エンコードが速く扱いやすい。弊社が画像最適化で主にWebPを使っているのも、この扱いやすさによる。本記事の実例もWebPへの変換で計測している。

圧縮効率について、GoogleはWebPで「同等画質のJPEGより25〜34%程度小さくなる」としている。ただし弊社の経験では、実際にはもっと縮む。画像データが半分以下になるケースも珍しくない。削減率は画像の内容や元のJPEGの圧縮設定によって変わる。とはいえJPEG/PNGを次世代フォーマットに変えるだけで、半分前後かそれ以上は軽くなると見ておくとよい。

ブラウザ対応と注意点 ​

WebPは現在、主要ブラウザのほぼすべてに対応している。Chrome・Firefox・Edge・Safari（バージョン14以降）で表示でき、実務上の問題はほとんどない。万全を期すなら <picture> 要素でフォールバックを記述する方法もある。

<picture>
  <source srcset="/image.webp" type="image/webp">
  <img src="/image.jpg" alt="商品画像">
</picture>

注意すべきは過圧縮による画質劣化だ。非可逆モードで圧縮率を高めすぎると、写真系の画像でディテールが失われる。特に商品画像は元のJPEGと見比べながら品質パラメータを設定し、目視で確認してから本番に適用したい。

実在サイトで観測された次世代フォーマット化の効果 ​

弊社の表示速度ボトルネックの実例研究（vigilante）では、実際のサイトを観測し、各ボトルネックを一つずつ解消するシミュレーションを行っている。以下では、WebP変換の効果が観測された3例を紹介する。最初の1例は、画像が極端に重く LCP まで大きく改善した数少ないケース。残りの2例は、LCP はほとんど動かないが転送量に効いたケースだ。各数値はサードパーティータグなど他のボトルネックの影響を切り離した状態で計測したシミュレーション結果だ。

ルタオ：LCPが10.6秒から2.8秒に短縮 ​

北海道小樽発の洋菓子ブランド ルタオ（LeTAO） のトップページでは、80枚のJPEG/PNG画像が検出され、合計転送量は19.47MBに達していた。特に LCP 要素であるトップスライダーの画像（456KB）がダウンロードに時間を要し、LCP が10.6秒という観測値を示していた。

80枚をすべてWebPに変換したシミュレーションの結果が以下だ。

画像転送量が85%削減され、LCP が7.7秒短縮、スコアも21ポイント改善した。ただしこれは典型例というより、むしろ例外に近い。元の画像転送量が19.47MBと極端に重く、LCP要素の画像のダウンロード時間がそのままボトルネックになっていたためだ。ここまで重ければ画像の軽量化がLCPに直結するが、逆に言えば、これほど極端でなければLCPはここまで動かない。

詳細な手順と観測データは ルタオのボトルネック研究 にまとめている。

アイルミネ：101枚で8.11MBの転送量削減 ​

ルミネグループが運営するファッション通販サイト アイルミネ（i LUMINE） では、トップページの画像101枚がすべてJPEG形式で配信されており、画像総サイズは10.46MBを記録していた。

このサイトでは別のボトルネック解消（カルーセル画像の遅延読み込み）でLCPがすでに改善されていたため、WebP変換によるLCP改善は0.2秒にとどまった。しかし転送量の削減幅は8.11MBという規模だ。Lighthouse スコアの数値には現れにくいが、モバイル回線でのデータ通信量や、同一ユーザーが複数ページを連続閲覧した際のトータルコストに確実に影響する。

詳細は アイルミネのボトルネック研究 を参照してほしい。

JINS：35枚で60%の転送量削減（LCPは0.2秒） ​

アイウエアブランド JINS のオンラインショップでは、35枚のJPEG/PNG画像がWebP未変換のまま配信されていた。とりわけ LCP 対象のトップバナー画像が337KBのJPEGであり、これが描画時間を押し上げていた。

35枚のWebP変換シミュレーションの結果が以下だ。

LCP 対象のトップバナー画像は75.5%小さくなったが、LCP 自体の短縮は0.2秒にとどまった。画像を軽くしてもLCPが大きく動くわけではない、という先ほどの話のとおりだ。一方で画像全体は60.3%（1.09MB）削減されており、転送量という観点での効果ははっきりしている。

詳細は JINSのボトルネック研究 を参照してほしい。

自分のサイトで次世代フォーマットに移行するには ​

実例を踏まえて、実際の対処の方向性を整理する。

まずLighthouseで現状を確認する ​

Google Chrome DevToolsのLighthouseタブで診断すると、「次世代フォーマットの画像を使用してください（Serve images in next-gen formats）」という指摘がある場合、WebP変換の余地が存在する。指摘欄には対象の画像ファイルと推定削減量も表示されるため、優先順位を判断しやすい。

ビルドツールやプラグインで変換を自動化する ​

静的サイトならビルド時に一括変換するのが現実的だ。Vite・Webpack系のプラグインや画像変換CLIを組み込めば、JPEG/PNGをWebPに自動変換した上でビルドできる。変換後は <picture> 要素か <img> の src に直接WebPを指定して配信する。

WordPressなどのCMSを使っているなら、WebP変換に対応したプラグインが多数公開されている。アップロード時またはサーブ時に自動変換してくれるものを選ぶとよい。

手作業を省くなら変換ツールや配信最適化を検討する ​

コードを変更せずに対応したいなら、画像配信を最適化する仕組みを挟む方法もある。CloudinaryやImgixといった画像CDNは、ブラウザの Accept ヘッダーに応じて自動でWebPを返してくれる。

手元での変換作業が負担であれば、弊社が提供する LightFile（画像最適化ツール）でJPEG/PNG画像のWebP一括変換を行うことができる。また、サイトのHTMLを変更しないまま既存の画像URLに対して配信時の自動WebP変換・最適化を行う LightFile Proxy もある。コードの書き換えが不要なため、CMS管理のサイトや開発リソースが限られる場合にも向いている。

変換後は品質を必ず目視確認する ​

どの変換手段を使うにせよ、変換後の画像を元のJPEGと見比べる確認は欠かせない。圧縮パラメータが強すぎると商品画像や人物写真でディテールが失われる。品質と削減率のバランスを確認してから本番に反映したい。

まとめ ​

• 次世代フォーマット化の主な効果は「転送量の削減」。 「画像を軽くすればLCPが改善する」とよく言われるが、LCPは前段の FCP とダウンロードの開始タイミングでほぼ決まる。画像を軽くしてLCPが目に見えて縮むのは、もともと画像が極端に重いサイトに限られる。
• とはいえ例外はある。ルタオでは画像転送量が19.47MB→2.84MB（85.4%削減）と極端に重い状態が解消され、LCP が10.6秒→2.8秒に短縮した。こうしたケースは少数だが実在する。
• 多くのサイトでは、次世代フォーマット化の価値は転送量に表れる。アイルミネでは画像10.46MB→2.36MB（77.5%削減）、JINSでは35枚で60.3%削減を記録した。Lighthouse スコアに出にくくても、モバイル回線のデータ通信量や、AWSなど転送量課金のクラウド費用に確実に効く。
• まずLighthouseで対象画像を確認し、ビルドツール・プラグイン・画像CDNを使って変換を自動化する。変換後は品質を必ず目視で確認する。
• 変換作業の自動化には LightFile、コード変更なしの配信時最適化には LightFile Proxy も選択肢のひとつとして検討してほしい。