クレジット使用量の最適化
Imgix クレジットは、アセットの管理、エンドユーザーへの配信、および変換というサービスの異なる側面における使用量を測定します。クレジットの消費方法を理解し、最適化戦略を実践することで、コストを削減しながらユーザーのパフォーマンスを向上させることができます。
Imgix クレジットの種類を理解する
Imgix クレジットは、画像配信パイプラインの異なる側面に対応する 3 つの主要カテゴリに分類されます。
| カテゴリ | サブカテゴリ | 説明 |
|---|---|---|
| 管理クレジット 2 クレジット/GB | キャッシュストレージクレジット | Imgix のキャッシュにレンダリング画像がどれだけ長く保持されているかに基づいて消費されます。 Cache TTL Behavior 設定と Origin Cache Retention 設定の両方が、レンダリング画像がオリジンキャッシュに保持される期間を制御します。 |
| メタデータストレージクレジット | Imgix がリクエストを効率的に処理するために使用する、画像の寸法、フォーマット、その他の情報の保存に使用されます。 | |
| 配信クレジット 1 クレジット/GB | 帯域幅クレジット | エッジ POP からクライアントへのデータ転送に基づいて消費されます。画像サイズが大きいほどクレジット消費も増加するため、最適化がコスト削減に役立ちます。 |
| キャッシュリード | シールド POP からエッジ POP へのデータ転送に基づいて消費されます。画像サイズが大きいほどクレジット消費が増えるため、最適化がコスト削減に役立ちます。 | |
| 変換クレジット 機能によって異なる | — | Imgix が画像を処理して新しいレンダリングバージョンを作成する際に消費されます。以下のような場合に発生します：
|
クレジット使用量の最適化方法
クレジットの使用を最適化するには、3 つすべてのクレジットカテゴリに対して戦略を講じる必要があります。コスト削減という明確な利点に加えて、より軽量で読み込みの早い画像を配信することで、ユーザー体験の向上にもつながります。
以下に各クレジットカテゴリごとの最適化戦略を紹介します。
管理クレジットの最適化
管理クレジットは、レンダリング画像がオリジンキャッシュに保持される期間を共に制御する 2 つの設定、Cache TTL Behavior と Origin Cache Retention によって左右されます。目標は、ストレージコストとキャッシュ効率のバランスを取ることです。オリジンキャッシュが Imgix の全体的なキャッシュアーキテクチャの中でどのような役割を果たすかについては、CDN ガイドライン を参照してください。
適切な Cache TTL と Origin Cache Retention 期間を設定する
Cache TTL Behavior は、ブラウザやシールドキャッシュ・エッジキャッシュといった下流で派生画像が有効とされる期間を制御します。Origin Cache Retention はこれとは別の設定で、設定した日数の間アクセスがなかった場合にオリジンキャッシュからファイルを削除します。アクセスがあるたびにこのカウントダウンはリセットされます。
ストレージクレジットの使用量を調整する場合は、Cache TTL ではなく Origin Cache Retention を変更してください。Cache TTL は下流のキャッシュ動作を制御するための設定であり、ストレージコストの調整を目的としたものではありません。また、Cache TTL を長くすると、オリジンキャッシュにファイルが保持される期間も長くなってしまいます。デフォルトの 45 日 の Origin Cache Retention 期間は、多くのユースケースで有効です。設定可能な最小値は 2 日 です。
Origin Cache Retention が効果を持つには、Cache TTL より低い値に設定することを推奨します。そうしないと、Cache TTL の間隔で派生画像が更新されるたびにカウントダウンがリセットされてしまいます。この設定は、長い Cache TTL を使用している場合に、ストレージコストを個別に管理できる点で特に有用です。この設定を変更した効果がクレジット使用量に反映されるまで、数日かかる場合があります。
削除の判定は最終アクセスからの経過時間に基づくため、しばらく再アクセスされないコンテンツには短い保持期間が適しています：
- ブログ記事・ニュース記事：公開直後にアクセスが集中し、その後急速に減少するため、短い保持期間にすることで、再度リクエストされる可能性が低い古いコンテンツを保存するコストを避けられます
- 季節商品の画像：販売シーズンが終わってから次のシーズンまでの間、キャッシュされた画像を保持しないほうが、シーズン再開時に一度だけ再取得するコストよりも多くのクレジットを節約できる場合が多いです
- 安定したトラフィックのある常設コンテンツ（エバーグリーン）：継続的なアクセスによってカウントダウンが自動的にリセットされるため、デフォルトの保持期間で問題ありません
両方の設定は、Source 設定 で調整可能です。
配信クレジットの最適化
配信クレジットは、ほとんどの Imgix ユーザーにとって最大のコスト要因です。最適化の鍵は、視覚品質を損なうことなく、ユーザーに配信する画像サイズを削減することです。
自動パラメータを有効化する
最も簡単な最適化は、すべての画像に auto=compress,format を追加することです。これにより：
- 各ブラウザに最適な画像フォーマットを自動で選択（WebP、AVIF、JPEG など）
- 適切な圧縮設定を適用
- 手動操作なしでファイルサイズを削減
これらの設定は、デフォルトパラメータ として Imgix Source にグローバルに適用できます。
さらに、w=1200&fit=max をデフォルトパラメータに追加することで、パラメータが指定されていない画像でも最大幅 1200 ピクセルに制限できます。fit=max を使用することでアップスケーリングを防ぎ、常に縮小のみが適用されます。必要に応じてフロントエンドで個別のパラメータを指定してデフォルトを上書きすることも可能です。
デフォルト設定の追加は 5 分未満で完了し、帯域幅使用量を 20〜40% 以上削減できます。
srcset を使ってレスポンシブ画像を実装する
srcset 属性を使用すると、ブラウザは画面サイズやピクセル密度に応じて適切な画像サイズをリクエストでき、モバイルユーザーが不必要に大きな画像を読み込むことを防ぎます。
<img
srcset="
https://assets.imgix.net/image.jpg?w=400 400w,
https://assets.imgix.net/image.jpg?w=800 800w,
https://assets.imgix.net/image.jpg?w=1200 1200w
"
sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
src="https://assets.imgix.net/image.jpg?w=800"
alt="Responsive image example"
/>レスポンシブ画像の実装方法については、srcset チュートリアル をご覧ください。
srcset を使用する際は、幅のバリエーションを最大 24 に制限してください。これを超えると、キャッシュが断片化し、変換コストが増加する恐れがあります。
デフォルトの画質設定を信頼する
Imgix はファイルサイズと視覚品質のバランスに優れたデフォルト画質パラメータを使用しています。auto=format と srcset を併用している場合は、q パラメータを手動で調整する必要はほとんどありません。
動画配信の最適化
動画コンテンツを配信する場合は、Imgix の動画最適化機能 を使用して帯域幅コストを削減しましょう。動画ファイルは画像よりも大きいため、最適化による効果がさらに大きくなります。
変換クレジットの最適化
変換クレジットは、適切に管理しないと使用量が急増してしまう可能性があります。鍵となるのは、不要なレンダリングを最小限に抑えつつ、キャッシュヒット率を最大化することです。
変換とレンダーについて理解する
変換（トランスフォーメーション）とは、新しいレンダーリクエストを受け取った際に、Imgix が画像の新しい派生バージョンを作成することを指します。レンダーとレンダーリクエストの違いを明確にしておくことが重要です。
- レンダー: Imgix のパラメータ（リサイズ、クロップ、フォーマット変換など）を使って変換された画像のバージョン。
image.jpg?w=800とimage.jpg?w=801は異なる 2 つのレンダーです。「派生画像（derivative）」または「変換（transformation）」とも呼ばれます。 - レンダーリクエスト: キャッシュに存在しない画像をレンダリングするリクエスト。「変換リクエスト（transformation request）」とも呼ばれます。
- Imgix CDN でレンダーが完全なキャッシュ MISS になった場合、新しいレンダーリクエストが発生します
- 1 つのレンダーは、キャッシュの期限切れやアクセスパターンによって、時間の経過とともに複数のレンダーリクエストにつながる可能性があります
- 頻繁にアクセスされるレンダーはキャッシュに長く残るため、総リクエスト数に対するレンダーリクエストの発生率は低くなります
最適な変換使用率は、総リクエストの 1%〜15% の範囲が目安です。この比率がそれより高い場合、以下が考えられます。
- キャッシュ TTL が短すぎる可能性があります
- ユニークな URL バリエーションを作りすぎている可能性があります
- コンテンツへのアクセス頻度がキャッシュに残るほど高くない可能性があります
キャッシュインフラストラクチャの詳細については、CDN ガイドライン のキャッシュに関するセクションを参照してください。
Balancing Cache TTL
キャッシュ TTL を長くすると、レンダーをより長くキャッシュに保持できるため変換クレジットは削減されますが、その分メディア管理クレジットの使用量は増加します。鍵となるのは、コンテンツのアクティブな利用期間に TTL を合わせることです。
コンテンツタイプ別のキャッシュ TTL 設定のガイドラインの例を以下に示します。
| コンテンツタイプ | 推奨 TTL | 理由 |
|---|---|---|
| ブログ記事やニュース | 30〜60 日 | トラフィックの大部分は公開直後の 1 ヶ月に発生する |
| 商品画像 | 60〜90 日 | 季節商品はアクティブな期間が限られている |
| 常設コンテンツ（エバーグリーン） | 90 日以上 | コンテンツが長期間関連性を持つ |
不要な変換を避ける
パラメータの組み合わせが異なると、それぞれ個別にキャッシュされたレンダーが作成されます。バリエーションを最小限に抑えることで、キャッシュ効率を最大化できます。
srcset のバリエーションを制限する: srcset の実装では、幅の値を最大 24 個までに制限する パラメータの値を標準化する: サイト全体で画質、DPR、フォーマットの値を統一する 動的なパラメータ値を避ける: タイムスタンプのような、ユーザーやリクエストごとに変化するパラメータは使用しない
なお、expires パラメータ は追加のレンダーリクエストを発生させないため、変換クレジットに悪影響を与えません。
以下に、非効率な画質パラメータの使い方と効率的な使い方の例を示します。
非効率な例（不要なレンダーが多数作成される）：
<!-- Using arbitrary quality values -->
<img src="image.jpg?w=800" />
<img src="image.jpg?w=801" />
<img src="image.jpg?w=802" />効率的な例（キャッシュされたレンダーを再利用する）：
<!-- Using standardized quality value -->
<img src="image.jpg?w=800" />
<img src="image.jpg?w=800" />
<img src="image.jpg?w=800" />不要なパージを避ける
パージを行うと、キャッシュされたレンダーが削除され、以降のアクセスで新たにレンダーリクエストが発生します。アセットのパージは、オリジンで更新または削除された場合にのみ、戦略的に行いましょう。
まとめ
Imgix のクレジット使用量を最適化することで、コストを削減しながらエンドユーザーのパフォーマンスを向上させる、双方にメリットのある結果を実現できます。より軽量で最適なフォーマットの画像は読み込みが速くなり、ユーザー体験を向上させ、エンゲージメントやコンバージョン率の向上にもつながる可能性があります。
特定の使用パターンの最適化についてご質問がある場合は、お気軽にサポートにお問い合わせください。