ContentfulのアセットCDNで画像配信を最適化 - 読み込み速度がどれくらい変わるか検証してみた

ContentfulのアセットCDNで画像配信を最適化 - 読み込み速度がどれくらい変わるか検証してみた

2026.04.28

ヘッドレスCMSのContentfulには、URLパラメータを付けるだけで画像のフォーマット変換・リサイズ・品質調整ができる Image Transform API があります。

以前、この機能の基本的な使い方について記事を書きました。

Contentfulだけで画像変換が割と優秀。フォーマット変換・リサイズ・顔切り抜きなど試してみたよ

便利なのはわかったけど、「実際にパラメータで変換した画像ってブラウザキャッシュ効くの?」「変換処理のオーバーヘッドで逆に遅くならない?」というあたり、ちゃんと確認したことがなかったので検証してみました。

Contentful の画像最適化機能について

簡単なおさらい: Contentful の Images API では、画像URLにクエリパラメータを追加するだけで変換が可能です。

https://images.ctfassets.net/{space_id}/{asset_id}/{unique_id}/{name}?q=50&w=1200&fm=webp

主なパラメータ:

パラメータ 内容
fm フォーマット変換(jpg, png, webp, avif等) fm=webp
w / h リサイズ(幅 / 高さ) w=1200
q 品質(1〜100) q=50
fit リサイズ時のフィット方法 fit=fill

詳しくは前回の記事を参照してください。今回はこの変換を使ったときの キャッシュ挙動パフォーマンス に焦点を当てます。

パラメータ付き画像のキャッシュ挙動

まず気になるのは、パラメータで変換した画像がちゃんとキャッシュされるのかどうか。

結論から言うと、パラメータが同じであればCDN側で変換結果をキャッシュします。パラメータの組み合わせが異なれば、それぞれ別の画像として扱われ、個別にキャッシュされます。

実際のレスポンスヘッダを見てみましょう。

1回目のリクエスト

cache-control: max-age=31536000
content-type: image/jpeg
etag: "18fcb290c5d449c4505cdbdfed083fa7"
last-modified: Mon, 12 Jan 2026 16:06:55 GMT
server: Contentful Images API
x-cache: Miss from cloudfront

2回目のリクエスト

age: 61
cache-control: max-age=31536000
etag: "18fcb290c5d449c4505cdbdfed083fa7"
server: Contentful Images API
x-cache: Hit from cloudfront

max-age=31536000 でブラウザキャッシュが効いていることと、etag が同一であることから、同じ画像として扱われているのがわかります。

また、2回目で x-cache: Hit from cloudfront になっている通り、CDNキャッシュ(CloudFront)も有効です。つまり同一リージョン内であれば、異なるユーザーからのアクセスでも同じリクエストに対してCDNキャッシュが返されるため、サーバー側の変換処理が毎回走るわけではありません。

変換しても本当に速くなるのか検証してみた

「変換処理のオーバーヘッドで、結局遅くならない?」という疑問を検証します。

検証条件

  • 帯域制限: --limit-rate 1250k(10Mbps相当)
  • CDNキャッシュ: 無し(x-cache: Miss from cloudfront
  • 計測方法: curlの time_pretransfer / time_starttransfer / time_total を使用

結果

デフォルト(パラメータなし)

サーバー変換タイム: 0.202s
ダウンロードタイム:  3.053s
トータルタイム:     3.294s
ダウンロードサイズ:  3,121 KB

変換版(q=50&w=1200&fm=webp

サーバー変換タイム: 0.147s
ダウンロードタイム:  0.027s
トータルタイム:     0.217s
ダウンロードサイズ:  100 KB

3,121KB → 100KB、3.29秒 → 0.22秒。大きく変わりました。

サーバー変換タイムについては、何度か試したところ 0.1〜0.7秒程度の範囲でブレがあり、パラメータの有無による有意な差は見られませんでした。つまり、変換処理のオーバーヘッドはほぼ誤差レベルで、ファイルサイズの削減によるダウンロード時間の短縮効果が圧倒的に大きいと言えます。

これはContentfulの公式見解とも一致しています。特にモバイル回線など帯域幅が制限された環境では、効果は顕著になるはずです。

さらに、先述のCDNキャッシュが効いている場合は変換処理自体がスキップされるため、2回目以降はさらに高速になります。

実運用で押さえておきたいポイント

検証の結果、変換したほうが速いのは明らかですが、実運用ではいくつか気をつけたい点があります。

パラメータのバリエーションに注意

パラメータの組み合わせごとに別々のキャッシュが生成されるため、バリエーションを増やしすぎるとCDNキャッシュのヒット率が下がります。デバイスやビューポートごとに細かくサイズを変えたくなりますが、ある程度パターンを絞ったほうがキャッシュ効率は良くなります。

おすすめのパラメータ構成

個人的によく使う組み合わせはこのあたりです:

  • ブログ記事の本文画像: ?w=1200&fm=webp&q=70 — 十分な画質を保ちつつサイズを大幅に削減
  • サムネイル・一覧画像: ?w=400&fm=webp&q=60 — 一覧ページの読み込み速度に効く
  • OGP画像: ?w=1200&h=630&fit=fill&fm=jpg — SNSシェア用。webpだと一部プラットフォームで非対応の場合があるのでjpgが無難

ポイントは、fm=webp でフォーマット変換するだけでもかなりサイズが変わるので、まずはそこから試してみるのが良いかなと思います。

モバイル回線での効果

今回の検証は10Mbps制限下で行いましたが、実際のモバイル回線ではさらに帯域が絞られるケースも多いです。3MBの画像と100KBの画像では、体感速度が全然違ってきます。画像が多いページほど効果は大きいので、一覧ページやギャラリー系のコンテンツでは積極的に活用したいところです。

最後に

Contentfulで画像配信しているなら積極的に使っていくべき機能だと思います。特にこれまでオリジナルサイズのまま配信していた方は、パラメータひとつで体感速度が変わるはずなので、ぜひ試してみてください。

参考ドキュメント

この記事をシェアする

関連記事