先月、あるECサイト（楽天市場の出店者）のパフォーマンスを調査していた時に気づきました。ストアオーナーは数週間かけてテーマコードの最適化、不要なアプリの削除、CSSの縮小化など、標準的なパフォーマンス改善をすべて行っていました。しかしLighthouseスコアは依然として40点台。原因は？コレクションページで読み込まれる24枚の商品画像 — それぞれ800KB以上、カメラから直接アップロードされたものでした。
ECサイトのパフォーマンスに関する不快な真実：どんなにクリーンなテーマコードでも、商品画像が肥大化していればCore Web Vitalsスコアは改善しません。そして2026年、GoogleがINP（Interaction to Next Paint）を正式なランキング要因として重視する中、遅い商品ページはオーガニックトラフィックとコンバージョンの両方を直接的に損なっています。
ECサイトが特に画像の多い理由
一般的なコンテンツサイトは1ページあたり5〜15枚の画像を使用します。典型的なECサイト（楽天市場やYahoo!ショッピングの出店ページ、あるいはBASEのストア）のコレクションページは？20〜50枚の商品サムネイル。商品詳細ページは？通常5〜8枚の高解像度バリエーション画像に加え、ズームビュー。ホームページのスライダー、プロモーションバナー、ライフスタイルショットを加えると、1セッションで60枚以上の画像を扱うことになります。
画像CDNはこれらを効率的に配信しますが、CDNが魔法のように2MBのファイルを小さくするわけではありません。高速に配信するだけです。ブラウザは依然としてすべてのバイトをダウンロード、デコード、レンダリングする必要があり、コレクションページではそれが30回連続で発生します。
計算は残酷です。平均的な商品画像が1.5MBで、コレクションページに30枚読み込む場合、合計45MBの画像です。高速接続（50Mbps）でも、レンダリングが始まる前に画像のダウンロードだけで7秒以上かかります。モバイルでは？問題外です。
Core Web Vitalsが実際に測定するもの（そして画像がなぜそれを悪化させるか）
Googleの3つのCore Web Vitals指標は、画像がボトルネックになると次のように悪化します：
- LCP（Largest Contentful Paint / 最大視覚コンテンツの描画）： これは通常、ヒーロー画像または最初の商品写真です。1MB以上の場合、LCPは壊滅的です。GoogleはLCPを2.5秒未満に抑えることを求めています。最適化されていないヒーロー画像1枚だけで、これを5秒以上に押し上げることがあります。
- CLS（Cumulative Layout Shift / 累積レイアウトシフト）： 明示的なwidth/height属性のない画像は、読み込みに伴ってコンテンツがずれます。最近のECテーマは改善されていますが、遅延読み込みされる商品グリッドは、寸法が設定されていないと依然としてレイアウトシフトを起こす可能性があります。
- INP（Interaction to Next Paint / 次の描画までのインタラクション）： 2026年の新しい指標です。ユーザーがコレクションフィルターをタップしたりバリエーション画像をスワイプしたりした時、ページが応答するまでの時間です。メモリ内の大きな画像は、ブラウザがデコードと合成で忙しくなるため、すべてのインタラクションを遅くします。
監査したあるECサイトでは、LCPが6.8秒でした。商品画像を圧縮した後（同じ寸法、適切に最適化しただけ）、LCPは1.9秒に短縮されました。同じテーマ。同じコード。画像が小さくなっただけです。
実践的なEC商品画像圧縮ワークフロー
ECプラットフォーム（楽天市場、Yahoo!ショッピング、BASEなど）は、アップロードされた画像から異なるコンテキスト（サムネイル、コレクショングリッド、ズームビュー）用にリサイズ版を自動生成します。しかし多くのストアオーナーが見落としている点：プラットフォームはアップロードした元画像を圧縮しません。リサイズするだけで、あなたが渡したファイルをそのまま配信します。最適化されていない3MBのJPEGをアップロードすると、生成されるすべてのバリエーションがその肥大化を引き継ぎます。
つまり修正はアップロード前に行う必要があります。ワークフローは次のとおりです：
1. まず元画像を圧縮する
商品写真がプラットフォームのサーバーに触れる前に、圧縮を実行します。私は2パスアプローチを使用しています：
- パス1： 品質75〜80で圧縮。ほとんどの商品写真では、目に見える品質低下なしに60〜70%のファイルサイズ削減が得られます。3.2MBの商品写真は約900KBになります。
- パス2： 実際のECサイト表示サイズ（通常600〜800px幅）で圧縮結果を確認します。依然としてシャープであればそのまま使用。目に見えるアーティファクトがある場合は品質を85に上げて再圧縮します。
2. 適切なフォーマットを使用する
ECプラットフォームはJPEG、PNG、WebPに対応しています。商品写真の場合：
- JPEG品質75〜80： ほとんどの商品写真に最適。優れた圧縮率で、普遍的にサポートされています。
- WebP： 同じ品質でJPEGより約25%小さくなります。Chrome/Firefoxユーザーには自動変換されるプラットフォームもありますが、WebPの元ファイルをアップロードすることでサーバー側の変換オーバーヘッドを削減できます。
- PNG： 透過が必要な商品画像のみに使用。標準的な写真ではJPEGの方が5〜10倍小さくなります。
3. カタログ全体を一括処理
200枚の商品画像を1枚ずつ圧縮する時間は誰にもありません。CompactJPGは一括圧縮に対応しています — 商品写真フォルダ全体をドロップし、品質を75に設定して、すべてを一度に圧縮します。ZIPをダウンロードすれば完了です。
ECサイト改善の実際の指標
あるストアの画像最適化を支援した際の実際の結果です：
| 指標 | 改善前 | 改善後 |
|---|---|---|
| LCP（コレクションページ） | 6.8秒 | 1.9秒 |
| 総ページ容量 | 28.4MB | 6.2MB |
| 平均商品画像サイズ | 1.42MB | 310KB |
| INP（カテゴリフィルター操作） | 380ms | 95ms |
| オーガニックトラフィック（30日後） | ベースライン | +18% |
トラフィックの増加は魔法ではありません — CWVスコアの改善が既存キーワードの順位を押し上げたのです。同じコンテンツ、同じ商品、より高速なページ。
避けるべきECサイトの画像に関するよくあるミス
- 一眼レフから直接アップロード： カメラは印刷用の巨大なファイルを出力します。Web用ではありません。ECサイトにアップロードする前に必ず圧縮してください。
- 写真にPNGを使用： これは常に見かけます。300KBのJPEGで済むはずの4MBのPNG商品写真。本当に透過が必要でない限り、ページ速度のペナルティを払う価値はありません。
- 倍解像度の「Retina」画像： 400pxの商品カードに2000px幅の画像。確かにRetina画面ではシャープに見えますが、ほとんどのユーザーは2xと1.5xの密度の違いに気づきません。品質が許す場合は1.5xを検討してください。
- モバイルを無視： アクセス解析を見るとおそらく60%以上がモバイルトラフィックです。800px幅のデスクトップ向け画像が375px幅のスマホ画面に配信されています。レスポンシブ画像タグを使用し、適切なサイズのバリエーションを配信してください。
結論
ECプラットフォーム（楽天市場、Yahoo!ショッピング、BASEなど）は優れた基盤を提供します。しかし、投入するデータの質までは改善できません。最適化されていない画像をアップロードすれば、ストアは遅くなります — それだけです。良いニュースは、画像圧縮が最も簡単に得られるパフォーマンス改善だということです。コーディング不要。テーマ編集不要。アップロード前に商品写真を優れたコンプレッサーに通すだけで、Core Web Vitalsスコアが向上するのを確認できます。
お客様は圧縮に気づきません。ストアが読み込みを待たずに表示されることに気づくだけです。