先に要点
画像最適化というと、JPEG を軽くする WebP に変える くらいの話として見られがちです。
もちろんそれも大事ですが、実務ではそれだけでは足りません。
本当に効くのは、同じ見た目を、より少ないデータで届ける ことです。
そしてこの考え方は、表示速度だけでなく、サーバーや CDN から何バイト配るかにも直結します。
今回は、画像最適化を フロントエンドの速さ対策 だけで終わらせず、転送量を減らす設計 として整理します。
前提としての帯域の考え方は 帯域コストとは？画像・動画・CDNで請求が膨らみやすい理由 や CDNを入れているのに帯域コストが下がらないのはなぜか とつながりますが、今回は 画像 を主役にします。
画像最適化とは何か
画像最適化とは、ざっくり言えば 必要な見た目を保ちつつ、配る画像を軽くすること です。
ここでいう軽さは、ファイルサイズだけではありません。
実際には次の4つをまとめて考える方が自然です。
- 画像形式を適切に選ぶ
- 不要に大きい画像を置かない
- 端末に合ったサイズだけ配る
- すぐ見えない画像は後から読む
この4つが揃うと、ページ表示も軽くなりますし、配信に使う転送量も下がりやすくなります。
なぜ画像最適化が転送量にも効くのか
画像は、Web サイトの中でも 1回の表示で大きなバイト数を持ちやすい 要素です。
テキストや小さいCSSより、1枚のヒーロー画像や一覧のサムネイル群の方が、ページの重さを支配しやすいことは珍しくありません。
しかも画像は、アクセスのたびに繰り返し配られます。
つまり、画像1枚を 500KB から 150KB にできれば、表示速度だけでなく、毎回の配信量もそのぶん減ります。
小さいサイトでも、
- 記事サムネイルが多い
- 商品画像が多い
- ヒーロー画像が大きい
- 一覧ページで何十枚も出している
といった構成では、画像最適化がそのままコスト対策になります。
まず効くのは画像形式の選び方
画像最適化で最初に効きやすいのは、形式選びです。
MDN や web.dev でも、古い PNG / JPEG / GIF より、WebP や AVIF のような新しい形式の方が、より小さいサイズで同等の見た目を出しやすい場面があると整理されています。
ざっくり使い分けるとこうです。
| 形式 | 向いている場面 | メモ |
|---|---|---|
| JPEG | 写真 | 広く使えるが、最近はより効率のよい形式もある |
| PNG | 透過が必要、劣化させたくないUI画像 | 重くなりやすい |
| WebP | 写真、バナー、一般的なWeb画像 | JPEG / PNG より小さくしやすい場面が多い |
| AVIF | より高い圧縮効率を狙いたい画像 | WebP よりさらに小さくできる場面がある |
| SVG | ロゴ、アイコン、図形 | ベクターで表せるならかなり有利 |
ここで大事なのは、全部 AVIF にすれば終わり ではないことです。
実務では、画像の性質に合う形式を選ぶ方が大事です。
たとえばロゴやアイコンをラスター画像で持つより、SVG にした方が自然なことがあります。
逆に写真を無理に PNG で持つと、サイズだけ大きくなりがちです。
圧縮は「見えないところを削る」作業
形式を選んだあとに効くのが圧縮です。
圧縮というと画質を落とすイメージを持たれがちですが、実際には どこまでなら見た目を崩さず軽くできるか の調整に近いです。
ここでありがちな失敗は次の3つです。
- 元画像が必要以上に高解像度
- 書き出し品質を常に最大にしている
- デザインデータそのままを書き出している
特に、ページ上では横1200pxでしか表示しないのに、4000pxの画像をそのまま置いているような状態はかなりもったいないです。
その画像は、画質以前に 大きすぎる元データ が問題です。
圧縮は単独で見るより、表示サイズに合わせる のとセットで見る方が効きます。
一番見落とされやすいのは、表示サイズに合った画像を配っていないこと
ここはかなり重要です。
画像を最適化したつもりでも、スマホに desktop 用の大きい画像を送っていたら、配信量は思うように減りません。
だから 軽い画像を1枚作る だけでは足りず、端末に合うサイズを出し分ける 必要があります。
web.dev の responsive images の解説でも、レイアウトだけでなく画像もデバイス条件に合わせるべきだと整理されています。
この文脈で出てくるのが srcset や sizes です。
要するに、
- スマホには小さめ
- タブレットには中くらい
- 大きい画面には大きめ
を配る仕組みです。
これができるだけで、モバイル端末に不要に重い画像を送ることをかなり減らせます。
lazy loadingは「今いらない画像を後ろに回す」考え方
画像最適化では loading="lazy" もよく使われます。
これは、すぐに見えない画像の読み込みを後ろに回す仕組みです。
長い一覧ページ、記事一覧、ギャラリー、商品一覧のように、初回表示時に全部見えないページではかなり効きます。
必要になる前に全部の画像をダウンロードしないので、初回表示も軽くなりますし、結果として無駄な転送も減ります。
ただし、ここで大事なのは 全部 lazy にしない ことです。
web.dev でも、遅延読み込みは有効だけれど、最初に見える重要画像の扱いは別で考える必要があります。
LCP画像やヒーロー画像までlazyにしない
よくある失敗が、ファーストビューの大きい画像まで一律で lazy load することです。
最初に見えるメイン画像、ヒーロー画像、LCP になりやすい画像は、むしろ早く取りに行ってほしい画像です。
ここまで遅延すると、読み込みの開始自体が遅れて、体感速度も Core Web Vitals も悪化しやすくなります。
なので実務では、
- 画面の外にある一覧画像は lazy
- 最初に見えるメイン画像は eager
という切り分けの方が自然です。
画像最適化は 全部後ろに回す ことではなく、必要な画像から順に取らせる ことでもあります。
画像最適化でありがちな勘違い
1. WebPにしたら終わり
形式変換は効きますが、それだけでは不十分です。
大きすぎる画像を WebP にしただけでは、まだ重いことがあります。
2. 見た目がきれいなら問題ない
表示上きれいでも、実際には不要に大きいファイルを配っていることがあります。
見た目 と 転送量 は分けて見る必要があります。
3. CDNがあるから画像最適化は後回しでいい
CDN は配信の助けになりますが、重い画像を重いまま配ること自体は変わりません。
むしろ配信量が多いほど、画像最適化のコスト効果は大きくなります。
何から手を付けると効きやすいか
最初に見る順番としては、次の流れが分かりやすいです。
- 本当にその大きさが必要か
- 形式は適切か
- 圧縮しすぎず軽くできないか
srcsetやサイズ出し分けができているか- すぐ見えない画像を lazy にできるか
この順で見ると、何を直せばどれだけ軽くなるか がかなり整理しやすくなります。
まとめ
画像最適化とは、画像ファイルを雑に圧縮することではありません。
必要な見た目を、必要なサイズで、必要なタイミングにだけ届ける ことです。
その結果として、
という流れにつながります。
関連で読むなら、帯域の全体像は 帯域コストとは？画像・動画・CDNで請求が膨らみやすい理由、CloudFront 側の見方は CloudFrontの料金は何で決まる？リクエスト課金と転送課金の見方、CDN を入れても下がらない場面は CDNを入れているのに帯域コストが下がらないのはなぜか がつながります。
参考情報
- MDN: Image file type and format guide
- web.dev: Image performance
- web.dev: Responsive images
- web.dev: Browser-level image lazy loading for the web