Skip to content

Instantly share code, notes, and snippets.

@davbeck
Created May 16, 2016 19:09
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save davbeck/a5bfea3bdb56495203d5818f7cbc8487 to your computer and use it in GitHub Desktop.
Save davbeck/a5bfea3bdb56495203d5818f7cbc8487 to your computer and use it in GitHub Desktop.
imgIX summary

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.

Tests

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.

Cost

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.

Implementation

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.

Alternative

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.
@robertleib
Copy link

I REALLY like their service, thanks for the writeup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment