Webサイトの画像を最適化する実践ガイド
画像はページ転送の大きな部分を占めることが多く、発見、デコード、レイアウト、Largest Contentful Paintにも影響します。最適化は有効ですが、固定の節約率や順位効果が全ページに当てはまるわけではありません。段階ごとに測定できる流れを示します。
なぜ今、画像最適化が重要なのか
HTTP Archiveのページ重量レポートでは、中央値が変化しても多くのページで画像が重要だと分かります。Largest Contentful Paint (LCP)は表示領域内の最大の対象要素が描画される時点を測り、それは画像であることが多いものの常にそうとは限りません。
Googleの公開LCP基準は、訪問の75パーセンタイルで2.5秒以下を良好、4秒超を不良とします。LCP資源がボトルネックなら画像作業で基準間を移動できますが、それだけでCore Web Vitals合格や検索順位は保証されません。
ステップ1：フォーマットを正しく選ぶ
形式選択は容量と機能に大きく影響します。以下は定性的な比較です。ベンチマークは元画像、エンコーダ、設定、品質目標によって変わります。
| フォーマット | 最適な用途 | 容量の傾向 | ブラウザ対応率 |
|---|---|---|---|
| JPEG | 写真、旧ブラウザ対応 | 基準 | 非常に広い |
| WebP | 写真・グラフィック全般 | 効率的なことが多い。使用エンコーダを測定 | 現在の主要ブラウザ。利用者を確認 |
| AVIF | 検証した現代的な配信工程 | 非常に効率的な場合があるがエンコード負荷は高くなり得る | 現在の主要ブラウザ。フォールバックが必要な場合あり |
| PNG | ロゴ、アイコン、テキストグラフィック | 一部の平面図形に効率的、多くの写真では大きい | 非常に広い |
| SVG | アイコン、イラスト | 内容に依存するベクターマークアップ | ブラウザで広く対応。信頼できないSVGは無害化 |
WebPは多くのサイトの有用な既定候補ですが、万能ではありません。工程と利用者がAVIFに対応するなら、WebPかJPEGをフォールバックにして先の<source>で試します。VizuaではJPGをWebPに、またはAVIFに変換でき、ファイルはブラウザで処理されサーバーへ送信されません。
詳しくはWebPとAVIFの比較と非可逆・可逆圧縮の解説をご覧ください。
ステップ2：表示サイズにリサイズする
4000 × 3000画素の写真を800 × 600で表示すると、描画枠の必要量を大幅に超える元画素を含みます。高密度のレスポンシブ画面では大きい候補が必要な場合もありますが、カメラ原本の配信は通常、不要な転送とデコードを増やします。
原則は描画サイズと密度に近い候補を提示することです。srcsetとsizesでブラウザに選ばせ、固定の「Retina」倍率ではなくレイアウト幅、画素密度、品質、ズーム、アートディレクションを考慮します。
レイアウトに合わせて調整する開始寸法の例：
- 全幅ヒーロー：最大の描画枠から始め、必要な密度とブレークポイントの候補を生成
- 記事内画像：本文列とより広いレスポンシブ状態に合わせる
- サムネイル：ヒーローを流用せず各カードの描画サイズに近い候補を生成
- アバター：表示する円・正方形、端末密度、詳細プロフィール画面を考慮
圧縮前にVizuaの画像リサイズで適切な候補を作ります。節約量は元と出力の画素数によるため、生成ファイルを測定します。
ステップ3：適切な品質設定で圧縮する
形式選択とリサイズ後にエンコーダを調整します。品質尺度は非線形で、エンコーダや形式間で標準化されていません。非可逆では低い値ほど情報を減らしてバイトを削ることが多いものの、容量と見た目の変化は実出力で測ります。
推奨品質設定：
- JPEG：75–85は写真の慎重な開始範囲です。尺度は異なるため出力を確認します。
- WebP：75–80は開始範囲で、JPEG値との同等性は保証されません。
- AVIF：一部ツールでは60–75を開始範囲にできますが、尺度と挙動は異なります。
- PNG：まず強い可逆圧縮を試します。パレットを最大256項目に量子化するとさらに減る場合がありますが、色を失うため確認が必要です。
VizuaのJPEG圧縮は品質を調整して出力を確認できます。詳しい方法は画質を保つ圧縮をご覧ください。
ステップ4：効率的に配信する
圧縮は最適化の半分に過ぎません。ブラウザへの配信方法もパフォーマンスに同じくらい影響します。
寸法を明示的に指定する
各<img>に正確な固有のwidthとheightを与えるか、意図したレイアウト規則で枠を予約します。ブラウザが早く縦横比を決め、画像による移動を減らします。ただしフォント、挿入内容、アニメーション、誤ったレスポンシブCSSもCumulative Layout Shift (CLS)に影響します。
ファーストビュー以下の画像にlazy-loadを適用する
最初の表示領域から十分離れた画像にはloading="lazy"を検討します。LCP候補やすぐ必要な内容へ機械的に使わないでください。ブラウザ判断、カルーセル、印刷、高速スクロール、隠れたレイアウトのためテストが必要です。
ヒーロー画像を優先する
LCP候補は遅延しません。初期帯域を本当に優先すべきならfetchpriority="high"を検討し、初期HTMLで発見可能にします。広く高優先度にせず、トレースと実地データで効果を確認します。
レスポンシブ画像を使う
srcsetとsizesは候補と想定枠を伝えます。ブラウザは表示領域、密度、キャッシュ、実装を考慮します。sizesを実レイアウトに合わせ、過大・過小な候補選択を防ぎます。
手順5：定期的に監査して測定する
最適化は一度やれば終わりではありません。新しい画像を追加するたびに、パフォーマンスが低下するリスクがあります。
- PageSpeed Insights：代表ページでPageSpeed Insightsを実行し、実地とラボのLCPを分けて、変わり得るラベルではなく現在の画像診断を確認します。
- DevToolsのNetwork：要求を容量順にし、大きな画像を文脈で確認します。一律のKB上限ではなく、寸法、形式、圧縮、キャッシュ、優先度が役割に合うかを見ます。
- 自動化：ビルド工程へ画像最適化を加え、公開前に大きすぎる画像を検出
クイックチェックリスト
- 適切なJPEG、WebP、AVIF、PNG、SVG候補を生成して比較
- 実表示寸法へリサイズし、必要以上に広くしない
- 慎重な設定から始め、バイトと見た目を比較し、形式間で品質値を同一視しない
-
各
<img>に通常は固有のwidthとheightで正確な枠を予約 -
LCP候補に
fetchpriority="high"を検討して測定 - 適切な画面外画像を遅延し、スクロールとレイアウトを検証
- レスポンシブ配信のために
srcset/sizesを使用する - ページ、利用者、実地データから性能予算を設定
- 不要な私的メタデータを削除し、必要な色プロファイルなどは保持 — EXIFとプライバシーを参照
- PageSpeed Insightsで定期的に監査する
よくある質問
Webサイトに最適な画像形式は何ですか？
唯一の最適形式はありません。JPEGは写真との互換性が広く、WebPは非可逆・可逆、透過、アニメーションに対応し、AVIFは配信工程と利用者が対応すれば効率的です。PNGは輪郭の明瞭な可逆グラフィック、SVGは信頼できるベクター素材に向きます。代表的な派生画像を作り、実測容量、品質、互換性、必要機能で選びます。
未最適化画像はサイトをどれほど遅くしますか？
影響はページ、表示領域、回線、キャッシュ、画像の役割によります。大きすぎるLCP画像は転送とデコードを大幅に増やせますが、特定の容量が一つのLCP値に対応するわけではありません。実地Core Web Vitalsとラボのトレースで、転送、発見、優先度、デコード、描画のどれが実際のボトルネックか調べます。
すべての画像を遅延読み込みすべきですか？
いいえ。最初の表示領域外にあり遅延が有効な画像に使いますが、LCP候補には使いません。高い取得優先度は本当に重要な初期画像だけにし、乱用しないでください。レイアウト、preloadの発見、レスポンシブ候補の選択も時間に影響するため検証します。
すべての画像に幅と高さが必要ですか？
HTMLのimgでは、可能なら正しい固有の幅と高さを指定し、ダウンロード前にブラウザが縦横比を求められるようにします。寸法を定めたCSSコンテナやaspect-ratioでも領域を予約できます。重要なのは安定して正確な枠であり、誤った寸法や遅い変更はCumulative Layout Shiftを起こします。
画像最適化はSEOにどう影響しますか？
画像がボトルネックなら、利用体験とCore Web Vitalsを改善できます。Googleは広い順位システムの中でページ体験を使いますが、小さい画像だけで順位上昇は保証されません。利用者向けに最適化し、実地データを確認し、内容の品質、関連性、クロール可能性なども考慮します。