imgIX is similar to a proxy CDN that sits between where we store the full-size images and the devices and browsers that download them. Images are not stored in imgIX directly but instead on an HTTP server such as S3. You configure "sources" in imgIX that then proxy to the source server.
In our case, we would upload images directly to S3, then the clients would request them using the imgIX URL instead of the direct S3 URL. You can then include URL parameters in addition to the original URL that specify the size you will display the images at, the pixel density (ie retina), as well as other transformations such as auto compression. This leads to drastically smaller file sizes, which download faster, use less bandwidth and use less memory on the user's device. There are other features we can take advantage of like smart cropping that centers detail like faces in square cropped photos.
I uploaded 4 photos from an iPhone 6s to S3 using the app and then tested their download times and file-sizes. We resize the images to be a max of 10MB, but in these images case they were already below that limit, although just barely. These are not SLR images, just normal photos that we would want to keep the full-size versions of so that user's can zoom in on them.
For the resizing options, I used a width of 300@2x, which is a typical size we use in the iOS app. I turned on auto compress, which maintains good quality for thumbnails.
I performed these tests with a conditioned network connection maxed at 10mbps. On a typical 3G connection, bandwidth is under 1mbps, while an LTE, Cable or DSL connection could be anywhere from 1.5mbps to 100mbps.
Direct Download Time | Original File-size | First imgIX Request | Second imgIX Request | imgIX File-size | |
---|---|---|---|---|---|
A | 16s | 9.56MB | 6s | 2s | 0.06MB |
B | 11s | 3.89MB | 4s | 2s | 0.05MB |
C | 17s | 9.53MB | 7s | 1s | 0.06MB |
D | 9s | 4.21MB | 4s | 1s | 0.06MB |
Average | 13s | 6.8MB | 5s | 1s | 0.06MB |
What's most interesting here is that on the first request of an image, it is actually quit a bit faster than downloading the full-size image. While not listed here, I also tried a 2.5MB image and the uncached imgIX request took about the same time to download as the original. In all cases subsequent requests are always much faster.
It's difficult to compare the cost of downloading from S3 directly to imgIX, but I think we can assume it would be cheaper to use imgIX. S3 charges $0.09 per GB of bandwidth. imgIX only charges $0.08 per GB, but also includes a $3 charge for every 1,000 original images. However, because imgIX uses so much less bandwidth, the cost should be quit a bit less.
imgIX is really simple to implement. In the iOS app, when a hidden feature is turned on, I just swap out the domain for the imgIX one and add on the query parameters I want. If in the future we want to revert to S3, we can just remove the code that swaps out the URLs.
The main alternative is to resize our images into a handful of thumbnail sizes ahead of time. We do this on The City and it's a fairly common practice. Here's just a few ways that imgIX (or something similar) can be superior:
- As we add an iOS and Android app, as well as a responsive web app, the number of thumbnail sizes grows pretty quickly. Previously, we could rely on there being 2-3 sizes an image would be displayed at. Now however, between @1x, @2x and @3x devices, of varying size, there can be dozens. Even if we settle for not having exact thumbnail sizes, we are still left with more thumbnails than we've ever needed before.
- Having to pre-render thumbnails, especially as the number grows, forces us to add delays or complications to our upload process. Because our webservers aren't running on GPU optimized hardware (imgIX actually runs on Mac Pros) it takes even longer to process the thumbnails. If we process images in a background working, we run the risk of showing a user a thumbnail that isn't created yet.
- imgIX has some really cool features that are non trivial to implement, like smart cropping based on faces.
- imgIX can deliver WebP images instead of JPEG when the browser supports it.
I REALLY like their service, thanks for the writeup.