ツール
ウェブサイト用に画像ファイルサイズを減らす方法
重い画像は、サイトが「遅い」と感じることの最大の原因です。よくある商品ペ ージやマーケティングページは 2 MB 以上の重量を吐き出していて、そのおよそ 半分は画像です——しかも最大解像度、最高品質、そして間違ったフォーマットで 配信されています。サイズが増えると Largest Contentful Paint は 2.5 秒の 目標を超え、直帰率は押し上げられ、コンバージョンは静かに流出していきます ——ヒーロー画像の 100 KB ごとに、モバイルでもデスクトップでも参加度が 目に見える分だけ削られます。今期パフォーマンス改善を 1 回しかやらないな ら、画像にやりましょう。
重い画像がページを殺す理由
Google の Core Web Vitals は、ページ上で最も大きい画像を Largest Contentful Paint 要素として扱います。今の「良好」しきい値は、実ユーザー第 75 パーセン タイルで 2.5 秒未満。HTTP Archive の報告によれば、デス クトップの中央値ページは約 2.5 MB、モバイル中央値は約2.2 MB で、画像がその重さのおよそ 50%を一貫して占めています。つまり 1 枚の 1.2 MB ヒーロー写真が、LCP スコア を緑・黄・赤のどこに置くかを決めてしまう——あなたの書いた JavaScript が 走り出す前の段階で。
ビジネス側の根拠も同じくらいクリアです。Google 自身の研究が、モバイル読 み込み時間の 1 秒改善を、小売・旅行・リードジェネレーション系サイト全体で コンバージョン率の上昇に紐づけています。フラフラな 4G 回線の上だと、 600 KB の画像と 60 KB の画像はまるで別の製品のように感じます——前者は カクカクとスクロールイン、後者は一瞬で描画。画像ファイルサイズの削減は、 現時点で一番安いパフォーマンス改善手段です——サーバー側のリライトも、 アーキテクチャ変更もいらず、送らずに済んだバイトを削るだけです。
4 ステップ削減パイプライン
画像最適化サービスもビルドパイプラインも要りません。今どきの画像 CDN が 内部でやっているのと同じ手順を、ブラウザ内で 1 枚ずつ、1 分以内で回せま す。前のステップに次が依存しているので、必ずこの順で。
| ステップ | 操作 | 典型的な削減幅 |
|---|---|---|
| 1. 表示寸法にリサイズ | ビットマップを、レイアウトが実際に描画する最大サイズまで縮小。 4000×3000 の写真を 1200×600 の枠に入れると、ピクセルの 90% 以上が無駄になる。 | 60〜80% |
| 2. 品質を 75〜80 付近に | エンコーダの品質スライダーを写真のときは 75〜80 に。通常の視聴 距離では見た目の差はほぼ分からず、バイト削減は劇的。 | 30〜50% |
| 3. WebP に変換 | リサイズ・再量子化したビットマップを WebP に再エンコード。同寸 法・同品質で、普通は元の JPG / PNG の 3 分の 1 のバイト数。 | 25〜35% |
| 4. メタデータを削除 | EXIF、IPTC、XMP、カラープロファイル、作者メモを削除。スマホ写真 はブラウザが描画しないメタデータを 50〜100 KB 抱えている。 | 2〜10% |
4 つを重ねると、1.2 MB のオリジナルを 150 KB 以下に圧縮するのが珍しく なくなります。一般的な Web 表示サイズでは画質の低下は目に見えません。
フォーマット別の指針
ビジュアルの用途が違えば、最適なフォーマットも違います。反射ではなく中 身で選びましょう。
- 写真。JPG は品質 75〜80、または同 等品質の WebP。AVIF はさらに容量を稼げますが、エンコード時間が長く、 一部の旧デバイスでは対応しません——互換性を優先するなら WebP に退避。
- ロゴ・アイコン・UI グラフィックス。透過を残したいなら PNG、またはアルファチャンネル付き WebP がベター。元が ベクターなら SVG がさらに小さく、ラスターのアーティファクトなしに無限に 拡縮できます。
- イラストとフラットアート。WebP か PNG。バイト数では WebP、対応範囲では PNG が勝ち。両方必要なら picture 要素で WebP を出し、PNG をフォールバックに。
旧アセットのフォルダを別のフォーマットに一括で切り替えたい?画像変換ツールなら JPG・PNG・WebP・AVIF への一括再エンコードが 1 度で済み、品質のト レードオフをプレビューで横に並べて確認してから確定できます。
予算を決める
予算のない最適化は、少しだけ小さい画像を生むだけのことです。ページ上の 各カテゴリにバイト数の上限を決め、CI で強制し、ページ平均重量が一気に縮 むのを観測しましょう。コンテンツ主導のサイト向けの現実的なスタート予算:
- ヒーロー画像:100 KB 以下。LCP 要素 です。これより重いと Core Web Vitals でコストを払います。
- ギャラリーサムネイル:各 50 KB 以下。ファーストビューにあるサムネイル数をかければ、防御できる予算になります。
- Open Graph 画像:200 KB 以下。クロ ーラーや SNS のプレビューはこれを何度も再取得します。厳しめの上限で カード展開がサクサクになります。
- ファーストビューの画像合計:300 KB 以下。ここを超えると、どんな code-splitting をしても LCP スコアは救えません。
4 ステップのパイプラインを一度回し、出力を上記の予算に貼り付けてから出 荷しましょう。ページは速くなり、Core Web Vitals は良くなり、訪問者は 機嫌が良くなります——削った 1 バイトは、送るために払わなくて済む 1 バイト です。