ほとんどのウェブサイトで、ページ内の最も重い要素は画像です。HTML、CSS、JavaScriptを合わせたよりも大きいことも珍しくありません。ページが遅く感じたら、まず見るべきは画像であり、対処はたいてい手早く済みます。
ほぼすべての効果は3つの手法で得られます。実際に表示されるサイズにリサイズする、圧縮する、そして最新フォーマットで配信する。組み合わせて使えば、画像の容量を70%以上削減するのは日常茶飯事です。
実際に表示するサイズにリサイズする

これは最もよくある、そして最も無駄の多い間違いです。カメラから出したばかりの写真は横6000ピクセルあるかもしれませんが、記事では幅800ピクセルの段組みに表示されます。ブラウザは6000ピクセル分すべてをダウンロードし、収まるように縮小する際にその大半を捨てるのです。
6000ピクセルの画像を800ピクセルの枠で配信すると、必要なデータの5倍から10倍を余計にダウンロードすることになります。対処は簡単です。ファイルを表示される幅くらいにリサイズし、高精細ディスプレイ向けに少し余裕を持たせるだけです。
実用的な目安:
- 全幅のヒーロー画像:横1600〜2000pxで十分。
- 記事内の画像:1000〜1400px。
- サムネイル:300〜500px。
画像リサイズを使えば、ページに届く前に各画像を縮小できます。縦横比を固定したまま処理するので、変に引き伸ばされることはありません。
圧縮して無駄をそぎ落とす

寸法が整ったら、圧縮で目に見えないディテールを取り除きます。写真なら品質75〜85%あたりがちょうどいいところで、見た目は変わらないままファイルは大幅に小さくなります。PNGで保存されたフラットなグラフィックやスクリーンショットなら、色数の削減(256色への減色)でファイルを元の何分の一かにまで縮められます。
画像圧縮はどちらも扱えます。JPEGとWebPは品質で再エンコードし、PNGは減色し、元より大きなファイルを絶対に作らないことを保証します。ギャラリーまるごとなら、バッチ処理してZIPでダウンロードできます。
最新フォーマットに切り替える
フォーマットの選択だけでファイルを半分にできることもあります。写真について、一般的な選択肢を比べてみましょう。
| フォーマット | JPEG比の典型的な容量 | 得意なもの |
|---|---|---|
| JPEG | 基準 | 万能なフォールバック。写真向き |
| WebP | 約25〜35%小さい | 写真・グラフィック。幅広いブラウザ対応 |
| AVIF | 約50%小さい | 最小サイズが重要な写真 |
| PNG | 写真ではかなり大きい | ロゴ、アイコン、フラットなグラフィック、透過 |
2026年ではWebPが安全な既定値です。現行のすべてのブラウザが読め、JPEGを余裕で上回ります。AVIFはさらに小さくなりますが、エンコードに時間がかかり、対応がやや狭くなります。画像変換はAVIFを狙いつつ、AVIFが適さない場合はさりげなくWebPにフォールバックするので、悩まずに得られる最良の結果が手に入ります。
一つ注意を。写真にPNGは使わないでください。PNGはロゴ、アイコン、透過が必要なものには最適ですが、写真では同じ品質のWebPの何倍も大きくなることがあります。
組み合わせて使う
ウェブ向けのどんな画像にも通用する、確実なパイプライン:
- 表示幅(+Retina向けの余裕)にリサイズする。
- WebP、あるいは可能な限り小さくしたければAVIFに変換する。
- 品質75〜85%で圧縮し、最後の無駄をそぎ落とす。
これで、5MBのカメラ写真が、記事の段組みでは見分けのつかない120KBのWebPになります。ページ全体で掛け算すれば、読み込み時間の差は劇的です。
すべてがCanvasとWebAssemblyを使ってブラウザ内で動くので、何もアップロードされず、初回訪問後はツールがオフラインでも動き続けます。つまり、サイト用の画像フォルダを、どのサーバーにも渡さずに下準備できるということです。
ファイルの先へ
さらに役立つ習慣が2つあり、どちらもコストはゼロです。
- ファーストビュー外の画像は遅延読み込みを
loading="lazy"で。読者がスクロールで近づいたときだけブラウザが取得します。 - 幅と高さの属性を設定して、画像の読み込み中にレイアウトがガタつかないようにします。これはCore Web Vitalsのスコアにも効きます。
どの画像がページの足を引っ張っているのか正確に知りたいですか。画像SEOガイドで監査の方法を解説していますし、ページ速度チェックは最も重いアセットを一覧にしてくれるので、どこから手をつければいいかがわかります。
