Optimizing Image Delivery with Contentful's Asset CDN - Testing How Much Load Speed Actually Changes
This page has been translated by machine translation. View original
Contentful's headless CMS has an Image Transform API that allows you to convert image formats, resize, and adjust quality simply by adding URL parameters.
I wrote an article about the basic usage of this feature previously.
Contentfulだけで画像変換が割と優秀。フォーマット変換・リサイズ・顔切り抜きなど試してみたよ
While I understood it was useful, I hadn't properly checked "Do browser caches work for images transformed with parameters?" or "Does the transformation overhead actually make things slower?" So I decided to investigate.
About Contentful's Image Optimization Features
Quick review: Contentful's Images API allows transformation by simply adding query parameters to image URLs.
https://images.ctfassets.net/{space_id}/{asset_id}/{unique_id}/{name}?q=50&w=1200&fm=webp
Main parameters:
| Parameter | Purpose | Example |
|---|---|---|
fm |
Format conversion (jpg, png, webp, avif, etc.) | fm=webp |
w / h |
Resize (width / height) | w=1200 |
q |
Quality (1-100) | q=50 |
fit |
Resize fitting method | fit=fill |
Please refer to my previous article for details. This time, I'll focus on caching behavior and performance when using these transformations.
Caching Behavior for Images with Parameters
The first concern is whether images transformed with parameters are properly cached.
To summarize: If the parameters are the same, the conversion results are cached on the CDN side. If parameter combinations differ, they're treated as separate images and cached individually.
Let's look at the actual response headers.
First Request
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
Second Request
age: 61
cache-control: max-age=31536000
etag: "18fcb290c5d449c4505cdbdfed083fa7"
server: Contentful Images API
x-cache: Hit from cloudfront
We can see that browser caching is effective with max-age=31536000, and the identical etag shows it's treated as the same image.
Additionally, the second request shows x-cache: Hit from cloudfront, confirming that CDN caching (CloudFront) is also effective. This means that within the same region, CDN cache will be returned for identical requests from different users, so the server-side conversion process doesn't run every time.
Testing Whether Transformation Really Improves Speed
Let's verify the question: "Doesn't the conversion overhead actually make things slower?"
Test Conditions
- Bandwidth limit:
--limit-rate 1250k(equivalent to 10Mbps) - CDN cache: None (
x-cache: Miss from cloudfront) - Measurement method: Using curl's
time_pretransfer/time_starttransfer/time_total
Results
Default (no parameters)
Server conversion time: 0.202s
Download time: 3.053s
Total time: 3.294s
Download size: 3,121 KB
Transformed version (q=50&w=1200&fm=webp)
Server conversion time: 0.147s
Download time: 0.027s
Total time: 0.217s
Download size: 100 KB
3,121KB → 100KB, 3.29 seconds → 0.22 seconds. That's a significant difference.
Regarding server conversion time, after several attempts, it ranged from 0.1 to 0.7 seconds with no significant difference based on parameter presence. This means the conversion overhead is negligible, and the effect of download time reduction due to file size reduction is overwhelmingly large.
This aligns with Contentful's official position. The effect should be particularly noticeable in bandwidth-limited environments like mobile networks.
Furthermore, when CDN caching is effective, the conversion process itself is skipped, making subsequent accesses even faster.
Key Points for Practical Implementation
While it's clear that transformation improves speed, there are several points to consider for practical implementation.
Be Mindful of Parameter Variations
Since a separate cache is generated for each parameter combination, having too many variations can reduce CDN cache hit rates. While you may want to adjust sizes finely for different devices and viewports, limiting patterns will improve cache efficiency.
Recommended Parameter Configurations
Here are combinations I commonly use:
- Blog post content images:
?w=1200&fm=webp&q=70— Maintains sufficient quality while significantly reducing size - Thumbnails/listing images:
?w=400&fm=webp&q=60— Improves loading speed for listing pages - OGP images:
?w=1200&h=630&fit=fill&fm=jpg— For social sharing. JPG is safer as some platforms don't support webp
The key point is that just using fm=webp for format conversion makes a significant size difference, so I recommend starting there.
Effect on Mobile Networks
This testing was conducted with a 10Mbps limit, but actual mobile networks often have even more bandwidth constraints. The experiential difference between a 3MB image and a 100KB image can be substantial. The more images a page has, the greater the effect, making this particularly valuable for listing pages and gallery content.
Conclusion
If you're delivering images through Contentful, this is a feature you should actively use. Especially if you've been delivering original-sized images, a simple parameter can change the perceived speed, so please give it a try.