One key to testing and using imgix effectively is to configure your image storage to make the best use of our advanced caching architecture. Thinking through how your image catalog is stored and specifying in advance how images should be cached allows every link in the chain between your master image and the end user to serve it as quickly as possible.
imgix can connect directly with Amazon S3, Google Cloud Storage, your servers, or proxy any image on the internet. As long as your images are publicly addressable by a URL, we can serve them, so there’s no need to move them anywhere specific. That said, we recommend the following best practices to ensure a smooth integration.
File & Server Organization
- Store your images in a single location (unless using web proxy). A non-proxy imgix Source can only map to one location, but you can have multiple Sources if necessary (e.g. for testing and production).
- Organizing your images into folders within your root location (e.g. an Amazon S3 bucket or web folder) is fine for classifying further, and a folder at that level can be addressed specifically by a Source by adding it as the prefix. However, if you want to serve images from more than one folder in the root location, you’ll need to the set the Source to that location and add the folder name when building the image URL. This will give you the best performance and flexibility.
- Store only the highest-resolution version of each image you want to serve. imgix is designed around the concept of a single high-resolution master image that’s then used to generate as many derivatives (such as different sizes or crops) as you need.
- Avoid special characters in folder and file names. They require encoding to resolve and if not handled carefully, can result in 404 errors for your images. List of characters to avoid
- Fingerprint your images to automatically manage updates and removals. imgix’s purging feature is quick and thorough, but it’s better to manage master image updates by changing the filename everywhere it appears, along with updating the file itself. Our Fingerprinting Images guide details how and why to fingerprint.
imgix offers flexibility in the way the service interacts with
Cache-Control: max-age headers. The default Cache TTL behavior setting for all Source types except Google Cloud Storage is to respect a header if present (Respect origin), and apply a Default Cache TTL value of 1 year if not present. This is the easiest way to respect varying headers if you’ve set them, but have a reasonable setting otherwise that will use imgix’s caching architecture most effectively. Here are some common settings for other use cases—the Source setup docs have a complete explanation of imgix’s cache settings.
- imgix defaults the Cache TTL Behavior mode in Advanced Source Settings for all new Google Cloud Storage Sources to Enforce minimum, which applies
max-age=1yr, publicto all files whether they have a header or not. This is to ensure that caching works on all files. See the Google Cloud Storage setup guide for more information.
- If you need a different default expiration timeframe, keep Respect origin as the Cache TTL behavior, and change the Default Cache TTL value as desired.
- If you want to ensure that all images have the same
max-agevalue without having to set them manually, set the Cache TTL behavior to Override origin and and change the Override Cache TTL value as desired.
When Connecting to imgix
- Choose your imgix subdomain name carefully. Once the name is attached to a Source, it can’t be transferred to another Source, even if the original Source is deleted (this applies to custom subdomains as well as standard ones). If you’re testing the service out, we recommend using a name you won’t need later for your production site—domain names will remain inextricably linked to their initial Source.
- Don’t create multiple Sources to enable multiple image requests. HTTP/2 support means that sharding techniques that used to be a best practice for performance are now counterproductive.
- If you store your images in Amazon S3, create an IAM user with read-only permissions for your bucket. Use this set of credentials when setting up your Source for additional image security (instructions are in the Amazon S3 setup guide).