画像ストレージの設定
ファイルとサーバーの構成
- 画像は1か所に保存します（Web Proxyを使用する場合を除く）。非プロキシのimgixソースは1つの場所にのみマッピングできますが、必要に応じて複数のソースを持つことができます（例えば、テストと本番環境用）。
- ルートロケーション内（例えば、Amazon S3バケットやweb folder）のフォルダーに画像を整理することは問題ありません。また、そのレベルのフォルダーを特定のソースで指定するためにプレフィックスとして追加することができます。しかし、ルートロケーションの複数のフォルダーから画像を配信したい場合は、その場所にソースを設定し、画像URLを構築する際にフォルダー名を追加する必要があります。これにより、最高のパフォーマンスと柔軟性を得ることができます。
- 配信には最高解像度の画像のみを保存してください。 imgixは、単一の高解像度マスター画像を基にして、必要なだけ多くの派生バージョン（異なるサイズやクロップなど）を生成することを想定して設計されています。
- フォルダー名やファイル名に特殊文字の使用を避けてください。 特殊文字は解決にエンコーディングを必要とし、注意深く扱わない場合、画像に対して404エラーが発生する原因となります。避けるべき文字のリスト
- 画像にフィンガープリントを付けて、更新と削除を自動的に管理します。 imgixのパージ機能は迅速かつ徹底的ですが、マスター画像の更新をファイル名の変更によって管理する方が効果的です。当社の画像フィンガープリントガイドでは、フィンガープリントをどのようにして、なぜ行うかが詳しく説明されています。
Cache-Controlヘッダー
imgixは、Cache-Control: max-ageヘッダーとのやり取りを柔軟に設定できます。Google Cloud Storageを除くすべてのソースタイプについて、ヘッダーが存在する場合はそのヘッダーを尊重する（オリジンを尊重）デフォルトのキャッシュTTL動作設定と、ヘッダーが存在しない場合は1年のデフォルトキャッシュTTL値が適用されます。これは、設定されたヘッダーを尊重しつつ、imgixのキャッシングアーキテクチャを効果的に利用する合理的な設定です。他の使用例の一般的な設定は、ソース設定ドキュメントでimgixのキャッシュ設定の完全な説明が提供されています。
- imgixは、新しいGoogle Cloud StorageソースのデフォルトのキャッシュTTL動作モードをアドバンスドソース設定で最小限を強制と設定しており、ヘッダーの有無にかかわらずすべてのファイルに
max-age=1yr, publicを適用します。これにより、すべてのファイルのキャッシングが保証されます。詳細はGoogle Cloud Storage設定ガイドをご覧ください。 - 異なるデフォルトの有効期限を必要とする場合は、キャッシュTTL動作をオリジンを尊重として保持し、必要に応じてデフォルトキャッシュTTL値を変更してください。
- すべての画像に同じ
max-age値を手動で設定せずに保証したい場合は、キャッシュTTL動作をオリジンを上書きに設定し、必要に応じて上書きキャッシュTTL値を変更してください。
imgixへの接続時
- imgixサブドメイン名を慎重に選んでください。 名前がソースに付けられると、元のソースが削除されたとしても、他のソースに移行することはできません（カスタムサブドメインも標準サブドメインも同様）。サービスを試す場合は、後で本番サイトに必要となる名前を使用しないことをお勧めします—ドメイン名はその初期ソースと不可分に結びついています。
- 複数の画像リクエストを有効にするために複数のソースを作成しないでください。 HTTP/2サポートにより、かつてはパフォーマンス向上のためのベストプラクティスであったシャーディング技術は現在逆効果です。
- Amazon S3に画像を保存する場合、バケットに対して読み取り専用権限を持つIAMユーザーを作成してください。 この認証情報を使用してソースを設定する際には、追加の画像セキュリティが強化されます（手順はAmazon S3設定ガイドにあります）。