画質を損なわずにウェブ向けに画像を圧縮する方法

実務的な答え

ウェブ画像を画質を落とさずに圧縮したいとき、まずやってはいけないのは、品質スライダーを「なんとか耐えられる」最低値まで下げてしまうことです。出発点は、その画像がページの中で担っている実際の役割です。ヒーロー画像、拡大される商品写真、ブログの挿絵、アバター、スクリーンショット、背景テクスチャは、それぞれ求められる寸法・形式・品質が違います。

役に立つルールはこうです。まず実際に表示される最大サイズにリサイズし、そのうえでレイアウト内で見た目が変わらない範囲に収まるまでだけ圧縮する。 ブログ画像が CSS 幅で 760 px 表示されるなら、高密度ディスプレイ向けにはソースが 1500〜1600 px あればたいてい十分です。カメラ原本の 5000 px はデータの無駄。逆に 760 px で書き出すと Retina では甘く見えることがあります。適切なファイルはその両極端の間にあります。

「画質を落とさない」も定義をきちんとしておく必要があります。ウェブの文脈では通常、訪問者が実際に見るサイズでの見た目の劣化がないという意味で、ピクセル単位の完全一致ではありません。圧縮した WebP は原本と同一ではありませんが、ページ上ではまず見分けがつかないところまで持っていけます。

それがどんな役割の画像か、先に決める

WebP・AVIF・JPEG・PNG や品質値を選ぶ前に、まず画像を分類します。

この表はあえて意見を込めています。ウェブ画像の圧縮がうまくいかない原因の多くは、あらゆる用途を同じ扱いにすることです。トップページのヒーローは Largest Contentful Paint に効きます。商品詳細画像は信頼感やコンバージョンに効きます。装飾的な背景は誰もじっくり見ないぶん、もっと軽くて構いません。

まずリサイズ：寸法が仕事の大半をやってくれる

圧縮は「決まったピクセル格子」を保存するのに使うバイト数を減らします。リサイズはピクセル格子そのものを変えます。ソースがページで表示できる量よりずっと多くのピクセルを持っているなら、まずはリサイズが一番きれいな勝ち筋です。

サイズ決めのシンプルな式：

目標のソース幅 = 最大の CSS 表示幅 × デバイスピクセル比

例：

• 320 CSS px で表示されるカード画像は、2x 画面向けに 640 px のソースを用意する。
• 760 CSS px で表示されるブログ画像は、1500〜1600 px のソースを用意する。
• 幅いっぱいの 1200 CSS px 前後のヒーローは、トリミングや対象ユーザーの端末次第で 2000〜2400 px 必要になることがある。

全部に機械的に 3x を使うのは避けましょう。web.dev は DPR とレイアウトが両方効くこと、そして多くの場合ユーザーは非常に高い DPR のソースの恩恵を知覚できないことを指摘しています。ヒーローが 2400 px なのは妥当かもしれません。「ピクセルが多いほうが安心だから」と 5000 px にしてしまうのは、ほとんどの場合、帯域を燃やしているだけです。

PhotoTools ではこの二つの仕事が分かれています。厳密なピクセル数や長辺の縮小が必要なら Resize を使い、そのあと Compress で JPEG・WebP・AVIF を選び、品質を詰めます。

品質より先に形式を決める

形式は「どういう種類の細部ならきれいに間引けるか」を決めます。

• 多くのウェブ写真には WebP を使う。 モダンブラウザで広くサポートされ、同じような見た目の品質で JPEG より小さくなることが多い形式です。Google の WebP ドキュメントでは同等品質の JPEG に対して 25〜34 % の削減が報告されています。
• バイトが本当に効く場面では AVIF を使う。 大きな写真素材で WebP を上回ることがありますが、エンコードが遅く、パイプラインの複雑さも増えます。単独ではなくフォールバックとセットで運用します。
• 互換性のフォールバックには JPEG を使う。 メール、古い CMS のワークフロー、ダウンロード配布、<img> のフォールバックソースなど、今も出番があります。
• スクリーンショットや文字物は PNG または可逆 WebP を使う。 ロッシーな JPEG/WebP は小さな UI 文字をにじませたり、鋭いエッジのまわりに色ノイズを出したりします。
• ロゴやアイコンには SVG を使う。 ラスタロゴを WebP 化すれば PNG より軽くなることはありますが、きれいな SVG のほうが基本的に鮮明で軽量です。

<picture> を使う場合は、効率のよい形式を先に置き、入れ子の img に互換性のあるフォールバックを残します。

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-1200.avif 1200w, /images/hero-2000.avif 2000w"
    sizes="100vw"
  />
  <source
    type="image/webp"
    srcset="/images/hero-1200.webp 1200w, /images/hero-2000.webp 2000w"
    sizes="100vw"
  />
  <img
    src="/images/hero-1200.jpg"
    width="1200"
    height="800"
    alt="ウォールナットのキャビネットと自然光が入る完成後のキッチン"
  />
</picture>

img 要素は依然として重要です。フォールバックのソース、alt、width、height を担うのはここです。アクセシビリティやレイアウト情報を source 要素の中に隠さないでください。

実務で使える品質設定

品質値には共通の基準がありません。あるエンコーダーの JPEG 品質 80 が、別のエンコーダーの 80 と同じとは限りません。WebP 80・JPEG 80・AVIF 50 も等価ではありません。品質は出発点として扱い、書き出したファイルを必ず自分の目で確認します。

よくある落とし穴は、「安全だから」と全部を品質 95 や 100 で書き出すことです。多くのウェブ写真では、その余分なバイトはページ上ではなくネットワーク waterfall にしか現れません。もう一つの落とし穴は、恣意的な目標を満たすために品質を 50 未満まで押し下げることです。そこまで下げないと届かないなら、これ以上劣化させる前に、まずリサイズか形式変更を検討します。

ページ内の役割別のファイルサイズ目安

これは Google のルールでもランキングの魔法の閾値でもありません。「明らかに重すぎる画像」を検知するための、実務的なレビュー用の目安です。

760 px のブログ画像が 900 KB あるなら、たいてい要調整です。全幅のポートフォリオ画像が 410 KB で見た目も素晴らしいなら、90 KB まで押し下げるのは目的違いかもしれません。

LCP／ヒーロー画像の圧縮

もっとも最適化する価値がある画像は、多くの場合、ファーストビューにある最大の画像です。Core Web Vitals の言葉でいえば、たいていは Largest Contentful Paint の画像。圧縮は効きますが、それは早期に検出され、早期に読み込まれることが前提です。

ヒーロー画像では：

1. ページで実際に使うアスペクト比にトリミングする。
2. 1200 px や 2000 px などのレスポンシブ幅を書き出す。
3. スタックが対応するなら AVIF を先、WebP/JPEG をフォールバックにする。
4. ヒーローやファーストビューの LCP 候補には lazy-load を付けない。
5. ブラウザが領域を確保できるよう width と height を付ける。
6. fetchpriority="high" は、LCP になりそうな 1 枚にだけ使う。

フォールバックの img の例：

<img
  src="/images/hero-1200.jpg"
  srcset="/images/hero-1200.jpg 1200w, /images/hero-2000.jpg 2000w"
  sizes="100vw"
  width="1200"
  height="800"
  fetchpriority="high"
  alt="ウォールナットのキャビネットと自然光が入る完成後のキッチン"
/>

fetchpriority="high" をギャラリー全体に付けないでください。優先度ヒントは切れ味の鋭い道具です。「本当に一番先に届いてほしい 1 枚」にだけ使います。

圧縮結果の比べ方

正しい比較は「原本 vs 圧縮版を 100 % ズームで並べる」ではありません。それは「大きすぎる画像を出してしまう」自分を納得させる比較の仕方です。訪問者が実際に見るサイズと文脈で比べます。

このレビューを 1 周してください：

1. 圧縮した画像を実ページ、または同じ幅のテストレイアウトに置く。
2. デスクトップ幅とモバイル幅で見る。
3. 危険ゾーンをチェック：顔、肌、空、グラデーション、布、商品ラベル、小さい文字、コントラストの強いエッジ。
4. レンダリングされたサイズで原本と圧縮版を切り替える。
5. 100 % ズームは、明らかなアーティファクトの拾い上げのために短時間だけ。誰も見ない完璧を求めるためではありません。

圧縮アーティファクトには個性があります。JPEG はブロック状のエッジ、リンギング、色ノイズが出やすい。過圧縮の WebP はテクスチャがのっぺりする。AVIF は攻めすぎるとバンディングやプラスチックのような質感が出ます。PNG のスクリーンショットはむしろ逆で、見た目は完璧なのに必要以上に重い、という失敗のしかたをしがちです。

ウェブ画像のための PhotoTools ワークフロー

PhotoTools は、画像が CMS・CDN・リポジトリに入る前の段階で便利です。本格的なビルドパイプラインの代わりにはなりませんが、小規模サイト、ブログ記事、クライアントプレビュー、単発の素材向けにはきれいな手作業の流れを提供します。

1. 元のソースファイルには手を付けない。
2. 画像の役割を決める：ヒーロー、本文画像、商品写真、スクリーンショット、サムネイル、背景。
3. 原本が表示サイズよりずっと大きいなら、先に Resize を使う。
4. Compress を開き、JPEG・WebP・AVIF から選び、WebP/JPEG なら品質 80 前後から始める。
5. 「Compress all」を押し、各カードの原本サイズ・出力サイズ・削減率を確認する。
6. 結果をダウンロードし、ページの文脈で確認する。
7. 見た目に難があれば、原本かリサイズ済みコピーに戻り、より高い品質で書き出し直す。
8. まだ重すぎるなら、品質をアーティファクト領域まで下げる前に、寸法を減らす。

すでに圧縮したダウンロードを何度も再圧縮しないでください。ロッシーなアーティファクトが積み重なります。マスター、あるいはきれいなリサイズ済み中間ファイルに戻ります。

メタデータとプライバシー

カメラファイルにはたいてい EXIF メタデータが入っています：GPS 座標、撮影日時、カメラ機種、レンズ、編集ソフトなど。訪問者が画像を見るうえで役立つ情報ではありませんし、私的な情報を漏らす可能性もあります。

PhotoTools は画像を復号し、ピクセルをブラウザのキャンバスに描いてから新しいファイルとして書き出します。MDN のドキュメントには、OffscreenCanvas.convertToBlob() がロッシー圧縮に対応する形式について画像タイプと品質を指定できると記載されています。出力はキャンバス上のピクセルから生成されるため、カメラ由来のメタデータは通常、新しいファイルにはコピーされません。

センシティブな写真では、公開前に完成品のダウンロードをメタデータチェッカーで確認してください。プライバシーはファイルサイズだけの問題ではありません。

画像を悪く見せてしまう、ありがちなミス

• リサイズ前に圧縮する： レイアウトで表示すらされないピクセルからバイトを削ろうとしている状態。
• 写真に PNG を使う： カメラ画像に対して PNG は通常、巨大になる。
• 文字入りスクリーンショットに JPEG を使う： ファイルは小さくなっても、文字がにじむ。
• サイズを誤って判断する： フル解像度でのズームは、無害なアーティファクトを大げさに見せてしまう。
• すべての端末に同じ巨大なヒーローを配信する： モバイル利用者が、使いもしないデスクトップ用ピクセルをダウンロードすることになる。
• ヒーローを lazy-load する： ファーストビュー外の画像は lazy-load でよいが、LCP 画像は違う。
• width と height を書かない： 画像読み込み中にレイアウトがずれる可能性がある。
• 公開済みファイルを再圧縮する： できるだけソースからやり直す。

コンパクトな公開前チェックリスト

ウェブ画像をアップロードする前に、これを 1 周してください：

1. コンテンツタイプに対して形式は妥当か？
2. ソース幅は実際の表示幅と現実的な DPR に基づいているか？
3. モバイルでヒーローの構図が変わる場合、より小さいモバイル用候補があるか？
4. 品質は顔・ラベル・グラデーション・商品詳細に耐える水準か？
5. その役割に対してファイルサイズは妥当か？
6. width、height、意味のある alt、必要なら srcset/sizes が入っているか？
7. LCP 画像は eager で優先されており、ファーストビュー外は lazy-load になっているか？
8. 書き出した画像を実際のレイアウトで確認したか？
9. 元のソースファイルは残してあるか？

いちばん良い圧縮ワークフローは、良い意味で退屈です。正しいピクセルを選び、正しい形式を選び、妥当な品質で書き出し、実際のページで確認し、画像が「加工されて見える」より一歩手前で止める。それだけです。

参照した技術ソース

本記事は、PhotoTools の圧縮とリサイズの現行実装、web.dev の画像パフォーマンスガイド、Chrome の「Improve image delivery」インサイト、Chrome の「Properly size images」ガイダンス、MDN の OffscreenCanvas.convertToBlob() ドキュメント、MDN の画像ファイル形式ガイド、そして Google の WebP ドキュメント と照らして確認しました。