Optimizing Credit Usage
Imgix credits measure your usage across different aspects of the service: managing your assets, delivering them to end users, and transforming them. By understanding how credits are consumed and following optimization strategies, you can reduce costs while improving performance for your end users.
Understanding Imgix Credit Types
Imgix credits are divided into three main categories, each corresponding to a different aspect of the image delivery pipeline.
| Category | Subcategory | Description |
|---|---|---|
| Management Credits 2 credits/GB | Cache Storage Credits | Consumed based on how long rendered images remain in Imgix’s cache. The cache TTL (Time To Live) setting controls how long a rendered image remains in our Origin Cache. |
| Metadata Storage Credits | Consumed for storing information about your images—such as dimensions, format, and other properties—that Imgix uses to process requests efficiently. | |
| Delivery Credits 1 credit/GB | Bandwidth Credits | Consumed based on the data transferred between the edge POPs to the client. Larger images consume more bandwidth credits, so optimization helps reduce costs. |
| Cache Reads | Consumed based on the data transferred between shield POPs to the edge POPs. Larger images consume more bandwidth credits, so optimization helps reduce costs. | |
| Transformation Credits Varies by feature | — | Consumed when Imgix processes an image to create a new rendered version. This occurs when:
|
Optimizing Your Credit Usage
Optimizing your credit usage involves strategies across all three credit categories. Besides the obvious benefit of reducing costs, these strategies also improve performance for your end users by delivering smaller, faster-loading images.
See the strategies below for optimizing your usage in each credit category.
Optimizing Management Credits
Management credits are primarily influenced by your cache TTL settings. The goal is to balance storage costs with cache efficiency.
Use an Appropriate Cache TTL
Your cache TTL should match the lifecycle of your content. A longer TTL reduces transformation credits but increases storage costs, while a shorter TTL does the opposite.
A cache setting of Enforce Minimum with 90 days is a good default for most use cases, balancing storage costs and cache efficiency.
Consider your content’s lifecycle when choosing a TTL:
- Blog posts or news articles: If content is only relevant for one month, use a 60-day TTL
- Product images: For seasonal products, align the TTL with the product’s active selling period
- Evergreen content: For content that remains relevant long-term, longer TTLs (90+ days) are appropriate
You can adjust the cache TTL in your Source settings or via the Cache-Control header on your Origin server.
Optimizing Delivery Credits
Delivery credits are the most common significant cost for most Imgix users since they scale with your site or application’s traffic. The key to optimizing bandwidth delivery is to reduce the size of images delivered to end users without sacrificing visual quality.
Enable Auto Parameters
The simplest optimization you can implement is adding auto=compress,format to all images to automatically:
- Selects the optimal format for each user’s browser (WebP, AVIF, JPEG, etc.)
- Applies appropriate compression settings
- Reduces file sizes without manual intervention
You can deploy the above suggestions as a global no-code change in your Imgix Source settings under Default Parameters.
In addition, we recommend adding w=1200&fit=min as default parameters to ensure images without any parameters are never served larger than 1200 pixels wide by default. The fit=min setting also ensures that images never upscale and only downsize. You can override defaults by applying specific parameters in your frontend code when larger sizes are needed.
Adding a default takes less than 5 minutes and can reduce bandwidth usage by 20-40% or more.
Implement Responsive Images with srcset
The srcset attribute allows browsers to request appropriately sized images based on the device’s screen size and pixel density, ensuring mobile users don’t download desktop-sized images unnecessarily.
<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"
/>For a comprehensive guide on implementing responsive images with Imgix, see our responsive images with srcset tutorial.
When using srcset, limit the size variations to 24 width values. More variations create unnecessary cache fragmentation and increase transformation costs without meaningful benefits.
Trust the Default Quality Setting
Imgix uses a default quality parameter that provides an excellent balance between file size and visual quality. If you’re using srcset with auto=format, it’s often unnecessary to adjust the q parameter manually, as Imgix automatically optimizes quality based on the format and viewing context.
Optimize Video Delivery
If you’re serving video content, use Imgix’s video optimization features to reduce bandwidth costs. Video files are significantly larger than images, making optimization even more impactful.
Optimizing Transformation Credits
Transformation credits can spiral out of control if not managed properly. The key is maximizing cache hits while minimizing unnecessary renders.
Understanding Transformations and Renders
A transformation occurs each time Imgix creates a new rendered derivative of an image as we receive a new render request. It’s essential to clarify the distinction between Renders and Render Requests:
- Render: A version of an image that has been transformed using Imgix parameters (e.g., resized, cropped, reformatted).
image.jpg?w=800andimage.jpg?w=801are two different renders. Also known as a “derivative” or “transformation”. - Render request: A request to render an image that is not in the cache. Also known as a “transformation request”.
- When a total cache MISS occurs in the Imgix CDN for a render, a new render request is made
- A single Render can result in multiple Render Requests over time, depending on cache expiration and access patterns.
- Frequently accessed renders stay in the cache longer, thus incurring fewer render requests than their total requests.
Optimal transformation usage typically ranges from 1% to 15% of total requests. If your transformation ratio is higher:
- Your cache TTL may be too short
- You may be creating too many unique URL variations
- Your content may not be accessed frequently enough to stay in cache
For more details on our caching infrastructure, see the caching section under the CDN guidelines documentation.
Balancing Cache TTL
A longer cache TTL reduces Transformation credits by keeping renders in cache longer at the cost of increasing Media Management credit usage. The key is matching your TTL to your content’s active usage period.
Here is an example guideline for setting cache TTL based on content type:
| Content Type | Recommended TTL | Reasoning |
|---|---|---|
| Blog posts or news | 30-60 days | Most traffic occurs in first month |
| Product images | 60-90 days | Seasonal products have limited active periods |
| Evergreen content | 90+ days | Content remains relevant long-term |
Avoid Unnecessary Transformations
Each unique combination of parameters creates a separate cached render. Minimize variations to maximize cache efficiency:
Limit srcset variations: Use a maximum of 24 width values in srcset implementations Standardize parameter values: Use consistent quality, DPR, and format values across your site Avoid dynamic parameter values: Don’t use parameters that change per user or per request (like timestamps)
Note that the expires parameter does not adversely affect transformation credits, as they do not create additional render requests.
See below for an example of inefficient vs. efficient quality parameter usage:
Inefficient (creates too many unique renders):
<!-- Using arbitrary quality values -->
<img src="image.jpg?w=800" />
<img src="image.jpg?w=801" />
<img src="image.jpg?w=802" />Efficient (reuses cached renders):
<!-- Using standardized quality value -->
<img src="image.jpg?w=800" />
<img src="image.jpg?w=800" />
<img src="image.jpg?w=800" />Avoid Unnecessary Purges
Purging removes cached renders, forcing new render requests on subsequent accesses. Strategically purge assets only when updated or removed at your Origin.
Conclusion
Optimizing your Imgix credit usage creates a win-win scenario: you reduce costs while improving your end users’ performance. Smaller, optimally formatted images load faster, improving user experience and potentially boosting engagement and conversion rates.
If you have questions about optimizing your specific usage patterns, don’t hesitate to reach out to support.