ヘッドレスにしたら画像の問題が出てきた
ヘッドレスコマースを導入すると、デザインの自由度や表示速度が向上する一方で、画像配信に関する新たな課題が発生することがあります。
特にNext.jsなどのフレームワークをVercelやAWS、自社サーバーでホスティングしている場合、商品画像の配信方法によっては予想外のコストや負荷に悩まされることがあります。
なぜ問題が起きるのか?
従来のShopifyテーマの場合
従来のShopifyテーマでは、商品画像はShopifyのCDNから直接配信されます。
Shopify CDNは世界中にサーバーがあり、画像の変換(リサイズ、WebP変換など)も自動で行ってくれます。この負荷はすべてShopify側が担っています。
ヘッドレス構成の場合
ヘッドレス構成では、フロントエンドのホスティング方法によって状況が変わります。
パターンA: 画像もホスティングサーバー経由
この構成だと、あなたのサーバーが画像の取得・変換・配信をすべて担うことになります。
パターンB: Next.js Imageを使う場合
Next.js Imageは便利ですが、画像変換のたびにサーバーリソースを消費します。
具体的にどんな問題が起きる?
1. サーバー負荷の増大
商品画像は1ページに何枚も表示されます。商品一覧ページなら20〜50枚、場合によってはそれ以上。
各画像に対して:
- 元画像の取得
- リサイズ処理
- フォーマット変換(WebP、AVIFなど)
- 圧縮処理
これらすべてがサーバーのCPUとメモリを消費します。アクセスが増えるセール時期には、画像処理だけでサーバーがパンクすることも。
2. ホスティングコストの増加
Vercelの場合
Vercelは画像最適化機能を提供していますが、変換回数に応じて課金されます。
- Proプラン: 月5,000回の画像最適化が含まれる
- 超過分: 1,000回あたり$5
商品数が多いECサイトでは、この上限をあっという間に超えてしまいます。月間10万PVのサイトで、1ページ平均20枚の画像があれば、単純計算で200万回の画像リクエスト。キャッシュが効いても、かなりのコストになります。
AWSの場合
Lambda@EdgeやCloudFront Functionsで画像変換を行う場合、実行時間とリクエスト数に応じた課金が発生します。
3. 表示速度の低下
画像変換がサーバー側で行われると、その処理時間分だけレスポンスが遅くなります。
- 初回リクエスト: 変換処理が入るため遅い(数百ms〜数秒)
- 2回目以降: キャッシュがあれば速い
問題は、商品数が多いとキャッシュのヒット率が下がること。新商品の追加や、画像の更新があるたびに、キャッシュが無効化されます。
4. キャッシュの管理が複雑に
画像のキャッシュは、以下のような要素で変わります:
- 画像サイズ(1x、2x、3xなど)
- フォーマット(WebP、AVIF、JPEGなど)
- 品質設定
- クロップ設定
同じ商品画像でも、これらの組み合わせ分だけキャッシュが必要になります。管理が複雑になり、ストレージコストも増加します。
実際の数字で見てみよう
ケーススタディ: 商品500点のECサイト
前提条件:
- 商品数: 500点
- 1商品あたりの画像: 5枚(メイン1 + サブ4)
- 合計画像数: 2,500枚
- 1画像あたりのバリエーション: 6種類(サイズ×フォーマット)
- キャッシュすべき画像数: 15,000枚
月間アクセス:
- PV: 100,000
- 画像リクエスト: 約2,000,000回
Vercelでの想定コスト増:
- 画像最適化の超過分: 約$10,000/月(!)
もちろんキャッシュが効けばここまでにはなりませんが、それでも無視できないコストです。
どんなサイトで問題になりやすい?
以下のような特徴があるサイトは、画像配信の問題が顕著になりやすいです:
- 商品数が多い(数百〜数千点)
- 商品の入れ替わりが激しい(アパレル、雑貨など)
- 高解像度の画像を使っている(ファッション、インテリアなど)
- アクセス数が多い(セール時期にスパイクがある)
- グローバル展開している(各地域でキャッシュが必要)
解決策はある?
はい、あります。外部の画像配信サービス(CDN)を使うことで、これらの問題を解決できます。
代表的なサービスとして「Cloudinary」があります。Shopifyの画像をCloudinaryに流し、そこから変換・配信することで、自社サーバーの負荷とコストを大幅に削減できます。
次のステップ
次は、Cloudinaryを使った解決策について詳しく見ていきましょう。なぜCloudinaryが選ばれるのか、どのようなメリットがあるのかを解説します。