独立サイトの画像最適化：自動圧縮、WebP/AVIF、遅延読み込みとCDN
1. 画像が独立サイトのパフォーマンスを最も殺す理由
HTTP Archiveの統計によると、1ページの総転送量のうち画像が50%以上を占めます。B2Bの独立サイトは製品画像、事例画像、工場画像が密集しているため、この比率は60%から70%に達することも珍しくありません。テキストとCSSを合わせても100KB程度なのに、圧縮されていない製品バナー1枚が2〜3MBになることもあります。
独立サイトのチームが最もよく踏む落とし穴は、デザイナーがPSDから書き出した元画像をそのままWordPressにアップロードし、アップロード時にサイズを縮小せず、テーマもWebPを生成しない結果、製品詳細ページに2MBの大きな画像が8枚も載ってしまうことです。モバイルの3G回線では画像の読み込みだけで30秒かかり、訪問者は画像が表示される前にページを閉じてしまいます。メディア資産の管理方法については、メディア資産の管理をご覧ください。Core Web Vitalsの合格ラインの決め方は、Core Web Vitalsの最適化。
| よくある画像の問題 | パフォーマンスへの影響 | 修正の優先度 |
|---|---|---|
| 元画像を縮小せずアップロード | 1枚が2〜3MBでLCPが基準超過 | 最優先、今週対応 |
| JPEGのみでWebPを提供しない | 同じ画質で容量が30〜50%増 | 高、2週間以内 |
| ファーストビューのバナーを遅延読み込みに設定 | LCPが1〜2秒遅延 | 最優先、すぐ修正 |
| width/height属性が欠落 | CLS（累積レイアウトシフト） | 中、テーマ更新時に対応 |
| 画像がCDNを経由していない | 海外へのオリジン回帰が1〜3秒遅い | 高、CDN設定と合わせて対応 |
2. 自動圧縮：アップロード時に処理する4つのライン
画像圧縮は運用担当者が手作業で1枚ずつ行うのではなく、アップロードの段階で自動的に完了させましょう。WordPressにはSmush、ShortPixel、Imagifyという3つの既存の選択肢があり、いずれもアップロード時に自動圧縮してWebPを生成します。年間費用は50〜100ドル程度です。独立サイトの年間画像枚数が500枚以内なら、最も安いプランで十分です。
圧縮品質には経験則があります。JPEG品質75〜82が目視と容量のバランス点で、70を下回るとブロックノイズやジャギーが出て、85を超えると容量の削減効果が頭打ちになります。PNGで透過チャンネルがある場合は、量子化で16〜32色のパレットに圧縮すると容量を60%以上削減できます。具体例として、工場の作業場の写真をJPEG品質78・幅1920で書き出すと通常150〜220KBになります。300KBを超える場合は、トリミングか品質設定にまだ問題があります。CDNの選び方は、次を参照してください。CDN選定比較。
| 画像の種類 | 推奨フォーマット | 目標サイズ | 幅の上限 |
|---|---|---|---|
| ファーストビューのbanner／hero画像 | WebP + JPEGフォールバック | 150至200KB | 1920px |
| 商品メイン画像 | WebP + JPEGフォールバック | 80至120KB | 1200px |
| 商品サムネイル | WebP | 15至30KB | 300px |
| 事例／記事の挿入画像 | WebP | 80至150KB | 1200px |
| アイコン／logo | SVGまたは小さなPNG | 5KB以内 | 表示サイズの2倍 |
| スクリーンショット／文字入り画像 | PNGは品質を落とさない | 200KBまで可 | 表示幅の2倍 |
三、WebP／AVIFの設定方法：pictureタグとCDNの自動ネゴシエーション
WebPはChrome／Edge／Firefox／Safari 14以上でサポートされ、カバー率はすでに95%を超えています。AVIFは圧縮率がWebPよりさらに20〜30%高くなりますが、Safariのサポートが16.4以降で、エンコードも遅いため、静的画像の一括事前生成に向いています。独立系サイトではAVIFをネイティブに書く必要はなく、CDNがオリジンから取得する際にAcceptヘッダーに応じて自動変換するほうが手間がかかりません。
実装方法は2つあります。1つ目はCDN層での自動ネゴシエーションです。Cloudflare、Cloudinary、FastlyはいずれもAcceptリクエストヘッダーに応じてWebPまたはAVIFを自動で返せます。オリジンにはJPEG／PNGを置くだけで、運用側の変更は不要です。2つ目はフロントエンドでpictureタグを明示的に記述する方法で、CDNを導入していない小規模サイトに向いています。直感に反する判断ですが、AVIFを追いかけてすべての画像を再エンコードしないでください。AVIFのエンコード時間はWebPの5〜10倍で、画像が500枚未満でない限りコストに見合いません。全体最適化の設定方法は、次を参照してください。CDNグローバル高速化。
| プラン | 実装方法 | ブラウザカバー率 | 年間コスト | 適用シーン |
|---|---|---|---|---|
| CDN自動変換 | Cloudflare／CloudinaryがAcceptヘッダーでフォーマットを返す | 95%以上で自動フォールバック | CDN費用に含まれる | ほとんどの独立系サイトに最適 |
| Pictureタグで2フォーマット | <picture> + WebP／JPEGを手書き | 手動制御 | 0ドル | CDN未導入の小規模サイト |
| WordPressプラグインで自動生成 | ShortPixel／SmushがWebPコピーを生成 | 95%以上 | 50〜100ドル／年 | WordPressの独立系サイト |
| サイト全体でAVIFを事前生成 | ビルド時にAVIFへ一括変換 | 約85% | エンコードコストが高い | 画像500枚未満のブランドサイト |
| JPEGのみを保持 | モダンフォーマットを使わない | 100% | 0ドル | 依然として非推奨、容量で不利 |
四、srcsetとレスポンシブ画像：スマホにデスクトップ画像をダウンロードさせない
圧縮だけでは不十分で、ブラウザに画面サイズに応じて画像を選ばせる必要があります。幅1920pxのbannerはスマホでは375pxしか表示されないのに、200KBをダウンロードしてしまい、70%の通信を無駄にしています。正しい方法はsrcset+sizesで複数のサイズを宣言し、ブラウザがデバイスピクセル比とビューポート幅に応じて最適なものを自動選択するようにすることです。
WordPressでアップロードするとthumbnail、medium、largeなどの複数サイズが自動生成されますが、テーマ側がテンプレートでsrcsetを出力しているとは限りません。確認方法は具体的で、Chrome DevToolsのNetworkタブでトップページbannerが実際にダウンロードしている画像URLを見ます。いつも1920pxの画像ならsrcsetが効いていません。最も低コストな修正は、テーマのfunctions.phpでadd_image_sizeを有効にし、the_post_thumbnailにsrcsetを出力させることです。タグを自分で書く必要はありません。
| ブレークポイント | 推奨出力幅 | 用途 |
|---|---|---|
| スマホ縦画面 | 640px | モバイルの一覧と記事 |
| タブレット縦画面 | 1024px | タブレットと小型デスクトップ |
| デスクトップ | 1920px | bannerと横長の挿入画像 |
| Retina 2x | 表示幅×2 | 高解像度でもぼやけない |
五、遅延読み込み：ファーストビュー以外はすべてlazy、ファーストビューの画像は必ずeager
ネイティブの遅延読み込みはすでに成熟しており、Chrome、Firefox、Safari 15.4以降が対応しています。ルールはシンプルです。ファーストビュー内の画像（通常はヒーローbannerや最初の商品画像）はloading=”eager”にし、それ以外はすべてloading=”lazy”にします。WordPressは5.5から本文内の画像にデフォルトでlazyを付けますが、テーマにハードコードされたファーストビューのbannerは手動でeagerに変える必要があります。
最もよくある自滅パターンは、「性能最適化のため」にファーストビューのbannerまでlazyにすることです。するとブラウザはHTMLが画像タグまで解析されるのを待ってからリクエストを始めるため、LCP要素が1〜2秒遅れます。正しい方法は、ファーストビューのbannerを<link rel=”preload” as=”image”>で先に読み込み、同時にwidth/height属性を残してCLSを防ぐことです。具体的な設定例として、トップページのヒーロー画像をhead内で<link rel=”preload” as=”image” href=”hero.webp” fetchpriority=”high”>とすれば、LCPをさらに0.5秒短縮できます。サイトのキャッシュ戦略はサイトのキャッシュ戦略。
| 画像の位置 | loading属性 | fetchpriority | preload |
|---|---|---|---|
| ファーストビューのヒーロー/banner | eager（lazyを書かない） | high | rel=preloadを必ず付ける |
| ファーストビュー内の商品メイン画像 | eager | highまたはauto | 状況に応じてpreloadを付ける |
| ファーストビューより下の記事挿入画像 | lazy | lowまたは書かない | 付けない |
| 一覧ページのサムネイル | lazy | 記載しない | 付けない |
| フッター/ロゴ/装飾画像 | lazy | low | 付けない |
六、検収：LighthouseとRUMの両面から見る
画像最適化はLighthouseのスコアだけを見て終わりにできません。ラボデータと実ユーザーデータには差があるからです。Lighthouseでは主に3つ、未最適化画像、適切なサイズの画像、モダンフォーマット画像のauditがすべて緑かどうかを見ます。実ユーザーデータはCrUX（Chrome User Experience Report）やCloudflare RUMでLCPの75パーセンタイルを見ます。平均値は見てはいけません。平均値は少数の速いユーザーに引き下げられ、75パーセンタイルこそ大多数の訪問者の実感を表します。
実行できる検収チェックリスト：トップページのLCP画像は200KB以下、サイト全体でファーストビュー外の画像は100% lazy、すべての画像にwidth/heightがある、WebP/AVIFのカバー率が90%以上、1ページの画像合計バイト数が1MB以下。達成できなければ該当する章に戻って調整します。PHPとデータベースの最適化は別の話で、PHPバージョンアップとデータベースのスロークエリ最適化。
| 達成指標 | 合格ライン | 計測ツール | 未達時の対応 |
|---|---|---|---|
| LCP画像サイズ | 200KB以下 | Lighthouse/DevTools | 圧縮またはトリミング |
| WebP/AVIFカバー率 | 90%以上 | DevTools Networkでレスポンスヘッダーを確認 | CDNの自動変換を有効化 |
| 遅延読み込みカバー率 | ファーストビュー外は100% | ソースでloading属性を確認 | テンプレートを一括置換 |
| 画像サイズの明示 | 100%にwidth/heightを指定 | LighthouseのCLS監査 | テーマに属性を一括追加 |
| 1ページの画像合計バイト数 | 1MB以下 | DevTools Network | 不要な画像を削除するかスプライトに統合 |
| LCP 75パーセンタイル | 2.5秒以下 | CrUX/Cloudflare RUM | 画像かフォントか切り分ける |
FAQ よくある質問
WebPとAVIFはどちらを使うべき？
ファーストビューのバナーに遅延読み込みを設定してもいい？
画像品質はどこまで圧縮すれば肉眼で違いが分からない？
WordPressの自動圧縮プラグインはどれを選ぶ？
画像をCDNに通すのと通さないのでどれだけ違う？
画像最適化はどう検収すれば合格になる？
最後に
画像最適化は一度きりの作業ではなく、アップロードすれば自動で処理されるパイプラインだ。本当に手間を減らすなら、ルールをアップロードの工程に組み込むこと。最大幅1920、JPEG品質80、WebPを自動生成、ファーストビュー外は自動lazy、CDNが自動でフォーマットを交渉する。運用担当者は今後、画像をドラッグしてアップロードするだけでよく、ルールを覚える必要はない。このパイプラインが一度動き出せば、以降に追加する画像は自動で基準を満たし、毎回手作業で確認する必要はなくなる。
実行は3ステップ。まず今週、Lighthouseでトップページを実行し、未最適化画像と最新フォーマットの2つのauditを確認する。次にShortPixelかSmushの自動圧縮プラグインを入れ、WebP生成をオンにする。最後にファーストビューのbannerにpreloadを付け、残りの画像にはlazyとwidth/heightを一括で付ける。2週間後にLCP 75パーセンタイルを再測定する。
覚えておきたい一言：画像最適化の目的は「小さくすること」ではなく、LCPのキー画像を2.5秒以内に表示させること。他の画像はいくら重くても待てばいい。