先に要点
画像最適化というと、JPEG を軽くする WebP に変える くらいの話として見られがちです。
もちろんそれも大事ですが、実務ではそれだけでは足りません。
本当に効くのは、同じ見た目を、より少ないデータで届けることです。 そしてこの考え方は、表示速度だけでなく、サーバーや CDN から何バイト配るかにも直結します。
今回は、画像最適化を「フロントエンドの速さ対策」だけで終わらせず、転送量を減らす設計として整理します。具体的な転送量(KB)や月間配信量(GB)、画像CDN導入で請求がどう変わるかの実数まで踏み込みます。 前提としての帯域の考え方は 帯域コストとは？画像・動画・CDNで請求が膨らみやすい理由 や CDNを入れているのに帯域コストが下がらないのはなぜか とつながりますが、今回は画像を主役にします。
画像最適化とは何か
画像最適化とは、ざっくり言えば「必要な見た目を保ちつつ、配る画像を軽くすること」です。 ここでいう軽さは、ファイルサイズだけではありません。
実際には次の4つをまとめて考える方が自然です。
- 画像形式を適切に選ぶ
- 不要に大きい画像を置かない
- 端末に合ったサイズだけ配る
- すぐ見えない画像は後から読む
この4つが揃うと、ページ表示も軽くなりますし、配信に使う転送量も下がりやすくなります。
表示速度に効く
ダウンロードするバイト数が減るので、初回表示が速くなり LCP も改善しやすくなります。体感の速さに直結します。
転送量に効く
画像はアクセスのたびに繰り返し配られます。1枚を軽くすれば、その差が配信回数だけ積み上がって帯域請求に出ます。
両方を分けて見る
「見た目がきれい」と「転送量が小さい」は別の指標です。きれいに見えても裏で数MB配っていることはよくあります。
なぜ画像最適化が転送量にも効くのか
画像は、Web サイトの中でも1回の表示で大きなバイト数を持ちやすい要素です。 テキストや小さいCSSより、1枚のヒーロー画像や一覧のサムネイル群の方が、ページの重さを支配しやすいことは珍しくありません。
しかも画像は、アクセスのたびに繰り返し配られます。 つまり、画像1枚を 500KB から 150KB にできれば、表示速度だけでなく、毎回の配信量もそのぶん減ります。
小さいサイトでも、
- 記事サムネイルが多い
- 商品画像が多い
- ヒーロー画像が大きい
- 一覧ページで何十枚も出している
といった構成では、画像最適化がそのままコスト対策になります。
「4000px を 1200px 表示で配る」が、どれだけムダか
ここがこの記事でいちばん伝えたいところです。よくある失敗は、デザインデータや一眼の元データをそのままアップロードして、表示は横1200pxなのに4000px級の画像を配っている状態です。一見きれいに見えるので気づきにくいですが、転送量で見ると差は劇的です。
同じ1枚の写真を、品質をほぼ揃えたまま条件だけ変えたときの典型的なファイルサイズはおおむね次のようになります(写真の内容で前後しますが、桁感はこの通りです)。
| 配信している画像 | 形式 / 品質 | 1枚あたりの転送量(目安) | 元データ比 |
|---|---|---|---|
| 4000px をそのまま | JPEG 品質90 | 約 2,800 KB | 100%(基準) |
| 1200px へ縮小 | JPEG 品質80 | 約 320 KB | 約 11% |
| 1200px + WebP | WebP 品質75 | 約 210 KB | 約 7.5% |
| 1200px + AVIF | AVIF 品質50相当 | 約 130 KB | 約 4.6% |
注目すべきは、まだ形式すら変えていない「4000px→1200px に縮小しただけ」の段で、すでに 2,800KB が 320KB へ、つまり約9分の1になっている点です。WebP/AVIF への形式変換はその上に乗る追加の効果で、寄与としては「表示サイズに合わせる」方がはるかに大きいことが分かります。AVIF が JPEG 比でおおむね50%前後軽くなるのは web 上のベンチマークでも繰り返し示されていますが、まず効くのは形式ではなくサイズです。
月間の配信量に直すとどうなるか
これを月間で積み上げると、差はGB単位になります。 仮に、トップと一覧で平均6枚の画像を出すページがあり、月間 20万ページビューあるとします。1ページあたり配る画像の合計を、最適化前後で比べます。
最適化前(4000px JPEG)
1枚 2,800KB × 6枚 = 約 16.8MB/ページ。20万PVで 約 3,360GB(約3.3TB)/月 を画像だけで配ることになります。
最適化後(1200px AVIF)
1枚 130KB × 6枚 = 約 0.78MB/ページ。20万PVで 約 156GB/月。同じアクセスでも配信量は 約21分の1 です。
実際にはブラウザキャッシュや CDN キャッシュで再ダウンロードは減りますが、新規アクセスや初回表示が中心のサイトでは、この桁の差がそのまま egress 量として効いてきます。3.3TB と 156GB では、CDN の従量請求や転送上限への当たり方がまるで違います。
まず効くのは画像形式の選び方
表示サイズの次に効きやすいのが形式選びです。
MDN や web.dev でも、古い PNG / JPEG / GIF より、WebP や AVIF のような新しい形式の方が、より小さいサイズで同等の見た目を出しやすい場面があると整理されています。AVIF は JPEG 比でおおむね50%前後、WebP 比でも20〜30%ほど小さくできることが多いとされます。
ざっくり使い分けるとこうです。
| 形式 | 向いている場面 | メモ |
|---|---|---|
| JPEG | 写真 | 広く使えるが、最近はより効率のよい形式もある |
| PNG | 透過が必要、劣化させたくないUI画像 | 重くなりやすい |
| WebP | 写真、バナー、一般的なWeb画像 | JPEG / PNG より小さくしやすい場面が多い |
| AVIF | より高い圧縮効率を狙いたい画像 | WebP よりさらに小さくできる場面がある |
| SVG | ロゴ、アイコン、図形 | ベクターで表せるならかなり有利 |
ここで大事なのは、全部 AVIF にすれば終わりではないことです。 実務では、画像の性質に合う形式を選ぶ方が大事です。
たとえばロゴやアイコンをラスター画像で持つより、SVG にした方が自然なことがあります。 逆に写真を無理に PNG で持つと、サイズだけ大きくなりがちです。
圧縮は「見えないところを削る」作業
形式を選んだあとに効くのが圧縮です。 圧縮というと画質を落とすイメージを持たれがちですが、実際には「どこまでなら見た目を崩さず軽くできるか」の調整に近いです。
ここでありがちな失敗は次の3つです。
- 元画像が必要以上に高解像度
- 書き出し品質を常に最大にしている
- デザインデータそのままを書き出している
特に、ページ上では横1200pxでしか表示しないのに、4000pxの画像をそのまま置いているような状態はかなりもったいないです。 前述のとおり、その画像は画質以前に「大きすぎる元データ」が問題で、縮小するだけで転送量が一桁変わります。
手元で確認するなら、画像処理ツールの sharp や CLI の cwebp / avifenc を使うと、変換前後のサイズをすぐ比較できます。
圧縮は単独で見るより、表示サイズに合わせるのとセットで見る方が効きます。
一番見落とされやすいのは、表示サイズに合った画像を配っていないこと
ここはかなり重要です。
画像を最適化したつもりでも、スマホに desktop 用の大きい画像を送っていたら、配信量は思うように減りません。 だから「軽い画像を1枚作る」だけでは足りず、端末に合うサイズを出し分ける必要があります。
web.dev の responsive images の解説でも、レイアウトだけでなく画像もデバイス条件に合わせるべきだと整理されています。
この文脈で出てくるのが srcset や sizes です。
要するに、
- スマホには小さめ(例: 640px 版、約 60KB)
- タブレットには中くらい(例: 1024px 版、約 150KB)
- 大きい画面には大きめ(例: 1600px 版、約 280KB)
を配る仕組みです。スマホに 1600px 版(280KB)を送り続けると、640px 版(60KB)で済むところを4倍以上配ることになります。モバイル中心のサイトほど、この出し分けの効果は大きくなります。
lazy loading は「今いらない画像を後ろに回す」考え方
画像最適化では loading="lazy" もよく使われます。
これは、すぐに見えない画像の読み込みを後ろに回す仕組みです。
長い一覧ページ、記事一覧、ギャラリー、商品一覧のように、初回表示時に全部見えないページではかなり効きます。 必要になる前に全部の画像をダウンロードしないので、初回表示も軽くなりますし、結果として無駄な転送も減ります。たとえば一覧に画像が40枚あって、初回に見えるのが上の8枚だとすれば、残り32枚は「スクロールされなければそもそも配らない」状態にできます。直帰したユーザーには配信が発生しないので、転送量の節約にも効きます。
ただし、ここで大事なのは全部を lazy にしないことです。 web.dev でも、遅延読み込みは有効だけれど、最初に見える重要画像の扱いは別で考える必要があります。
LCP画像やヒーロー画像まで lazy にしない
よくある失敗が、ファーストビューの大きい画像まで一律で lazy load することです。
最初に見えるメイン画像、ヒーロー画像、LCP になりやすい画像は、むしろ早く取りに行ってほしい画像です。 ここまで遅延すると、読み込みの開始自体が遅れて、体感速度も Core Web Vitals も悪化しやすくなります。
なので実務では、
- 画面の外にある一覧画像は
loading="lazy" - 最初に見えるメイン画像は
loading="eager"(指定しないデフォルトも eager 相当)
という切り分けの方が自然です。
画像最適化は「全部後ろに回す」ことではなく、必要な画像から順に取らせることでもあります。
画像CDNを入れると帯域請求はどう変わるか
ここまでの最適化(縮小・形式変換・出し分け)を、画像ごとに手作業でやるのは現実的ではありません。そこで実務では画像CDN(画像配信サービス)を使い、URLパラメータで「サイズ・形式・品質」を動的に出し分けることが多いです。Cloudflare Images、Cloudinary、Imgix、Vercel Image Optimization などが定番です。
請求の考え方は大きく2系統あります。1つは「変換回数・配信枚数」で課金するタイプ、もう1つは「転送量(GB)」で課金するタイプです。最新の代表的な料金は次のとおりです(2026年6月時点。最新値は必ず公式で確認してください)。
| サービス | 課金の中心 | 代表的な単価(2026年時点) |
|---|---|---|
| Cloudflare Images | 変換 / 配信枚数 | 変換 $0.50 / 1,000、配信 $1 / 100,000枚、保存 $5 / 100,000枚 |
| Vercel Image Optimization | 変換 + 転送 | 変換 $0.05 / 1,000、別途データ転送・キャッシュ読み書き課金。Hobby は変換5,000回/月まで無料 |
請求がどう変わるかを、前述の月間20万PV・1ページ6枚のサイトで考えます。最適化前は画像だけで約3.3TB/月の egress が発生していました。これをそのまま帯域従量の CDN で配ると、egress 単価が仮に $0.08/GB なら 3,360GB × $0.08 ≒ 約 269ドル/月。一方、画像CDNで 1200px AVIF を配って 156GB/月に落とせば、同じ単価なら 156GB × $0.08 ≒ 約 12.5ドル/月 です。
Cloudflare Images のように「配信枚数」で課金するタイプでは、また見方が変わります。月間の配信画像数は 20万PV × 6枚 = 120万枚。配信 $1 / 100,000枚なら 12回分で 約 12ドル/月、加えて変換ぶんが乗ります。ここでのポイントは、枚数課金のサービスでは「画像を軽くしても枚数が同じなら配信料は変わらない」ことです。つまり、
- 転送量(GB)課金の CDN では、画像を軽くするほど請求が直接下がる
- 枚数課金の画像CDN では、軽くしても枚数が同じなら配信料は変わらず、効くのは「無駄な変換を増やさない」「lazy で配る枚数自体を減らす」こと
という違いがあります。自分の構成がどちらの課金軸に乗っているかを先に確認するのが、コスト削減の出発点です。CDN を入れても帯域が下がらない理由は CDNを入れているのに帯域コストが下がらないのはなぜか で掘り下げています。
何から手を付けると効きやすいか
最初に見る順番としては、次の流れが分かりやすいです。
- 本当にその大きさが必要か(まず縮小。ここが一番効く)
- 形式は適切か(WebP / AVIF / SVG)
- 圧縮しすぎず軽くできないか
srcsetやサイズ出し分けができているか- すぐ見えない画像を lazy にできるか
- 自分の課金軸(転送量か枚数か)に合った打ち手を選べているか
この順で見ると、何を直せばどれだけ軽くなるかがかなり整理しやすくなります。前述の表のとおり、1番の「縮小」だけで一桁減ることが多いので、ここを飛ばして形式変換から入らないことが大事です。
画像最適化に関するよくある質問
Q. WebP と AVIF はどちらが優秀？
A. 圧縮率は AVIF が上で、WebP より20〜30%ほど軽くできる場面が多いです。ただし AVIF はエンコードが重く、変換に時間がかかります。2026年時点では主要ブラウザが対応済みなので、AVIF を第一候補にしつつ、念のため WebP/JPEG にフォールバックする picture 構成が安全です。
Q. JPEG XL はどう？
A. JPEG XL(JXL)は AVIF よりさらに圧縮率が高い場面もある新しい形式ですが、ブラウザ対応が割れています。Safari は対応が進む一方、Chrome は長く実験扱いで Firefox も標準では未対応の状態が続いています。将来の有力候補ですが、本番の主配信形式に据えるのはまだ早く、現時点では AVIF / WebP が無難です。
Q. 4000px の写真をそのまま置くと何が悪い？
A. 表示は1200pxでも、ブラウザは4000px版を丸ごとダウンロードします。本文の表のとおり1枚あたり約2,800KBが約320KB(縮小のみ)まで落ちるので、画質を保ったまま転送量を約9分の1にできます。まず縮小、が鉄則です。
Q. lazy loading の実装方法は？
A. img 要素に loading="lazy" を付けるのが最も簡単で、主要ブラウザが対応しています。古い環境も厳密にカバーしたい場合は lozad.js や lazysizes などの JS ライブラリを併用します。ヒーロー画像や LCP 画像には付けないでください。初期表示が遅れます。
Q. レスポンシブ画像はどう書く？
A. 複数解像度の出し分けは srcset と sizes、形式の出し分けは picture と source で行います。Next.js や Nuxt、Astro などは画像コンポーネントが複数サイズ・複数形式をビルド時または配信時に自動生成してくれるので、手書きより楽です。
Q. 画像CDNは入れるべき？
A. 画像枚数が多い、または変換パターンが多いサイトでは有効です。URLパラメータでサイズ・形式・品質を動的指定でき、レスポンシブ実装が一気に楽になります。ただし課金軸(転送量か配信枚数か)で削減の効き方が変わるため、本文の表を見て自分の構成に合うか確認してから入れるのがおすすめです。
Q. ブログサイトで効果のある画像最適化は？
A. 効く順におおむね、1) アイキャッチ・本文画像を表示サイズへ縮小、2) WebP/AVIF 化、3) srcset でレスポンシブ、4) lazy loading、5) OG画像専用バージョンの生成、です。Core Web Vitals の改善は SEO にも効くため、特に LCP に効くファーストビュー画像から手を付けると体感が大きく変わります。
まとめ
画像最適化とは、画像ファイルを雑に圧縮することではありません。 必要な見た目を、必要なサイズで、必要なタイミングにだけ届けることです。
その中でもっとも効くのは「表示サイズに合わせる」ことで、4000px を 1200px に縮小するだけで1枚あたり約2,800KBが約320KBへ、月間では3.3TBが156GB級へと一桁以上落ちます。形式変換や lazy loading はその上に積む追加の効果です。
その結果として、
という流れにつながります。
関連で読むなら、帯域の全体像は 帯域コストとは？画像・動画・CDNで請求が膨らみやすい理由、CloudFront 側の見方は CloudFrontの料金は何で決まる？リクエスト課金と転送課金の見方、CDN を入れても下がらない場面は CDNを入れているのに帯域コストが下がらないのはなぜか がつながります。