Today we’re reviewing Imgix. This blog post is part of our review series where we uncover best-of-class SaaS solutions for developers. Reviewing other API services helps us come up with ideas for improving Stream, our API for building scalable and personalized feeds. You can try an interactive tutorial of Stream here.

Approximately 60%+ of the average webpage’s weight is image content, so serving the best image in the smallest payload is an increasingly critical concern for both businesses and developers. More often than not, developers skip the crucial steps necessary to optimize and deliver images to their end users causing a degraded user experience, resulting in an additional loss of potential revenue from a website due to suboptimal image assets. According to KISSMetrics, every additional second of load time for a page will increase its bounce rate by 7%.

Image Optimization

Why is building an image oriented application so difficult to do? Let’s look into a few of the optimizations that come into play:

Properly sizing the image for the HTML tag containing the image e.g., A user uploads an avatar image that is 1200x800 and it needs to be resized to a thumbnail that is focused on their face. Allowing the browser to down-size the large image will cause significant bandwidth costs to transfer the image and incur more memory usage in the browser. Additionally, who knows if the image is centered on their face.

e.g., A user uploads an avatar image that is 1200x800 and it needs to be resized to a thumbnail that is focused on their face. Allowing the browser to down-size the large image will cause significant bandwidth costs to transfer the image and incur more memory usage in the browser. Additionally, who knows if the image is centered on their face. Providing images that are closest in geographic proximity to the user e.g., using a Content Delivery Network (CDN). Developers will usually serve an image directly from their server, which is seldomly geographically closest to the user. Occasionally, developers making an effort to meet this criterion will upload image assets to Cloud Storage served such as an Amazon S3 bucket, however, even S3 is not a proper CDN without Amazon CloudFront.

e.g., using a Content Delivery Network (CDN). Developers will usually serve an image directly from their server, which is seldomly geographically closest to the user. Occasionally, developers making an effort to meet this criterion will upload image assets to Cloud Storage served such as an Amazon S3 bucket, however, even S3 is not a proper CDN without Amazon CloudFront. Compressing and stripping images of extraneous data e.g., EXIF data is generally important when editing photos or holding data about the location where the photo was taken, which orientation the camera was in, and so on. This data, however, can bloat the image size, causing unnecessary bandwidth. Removing the EXIF data can decrease the image size by up to 64kb.

e.g., EXIF data is generally important when editing photos or holding data about the location where the photo was taken, which orientation the camera was in, and so on. This data, however, can bloat the image size, causing unnecessary bandwidth. Removing the EXIF data can decrease the image size by up to 64kb. Serve an optimal image format to the browser e.g. Modern browsers are capable of rendering many image types, some of which manage better compression algorithms with “lossless” quality such as the WebP format. It can be time-consuming to manually convert images to alternate formats, and some developers and designers worry about quality of image compression.

Building a scalable infrastructure in-house to handle these and other such optimizations (and traffic) can be a lengthy and cumbersome process. This is exactly why Imgix is our go-to for image processing.

A Real World Scenario

Let’s use a theoretical project where our application has the following criteria:

All images must load quickly on a mobile device.

All images must be downsized from their original size, which will be stored in an S3 bucket.

All images must be provided in two sizes so that high-resolution displays don’t render blurry images.

With just a few clicks of a button, we can have a new account setup with Imgix with an environment specific to the application we are building.

Rather than manipulating images on our own server and manually uploading them to an S3 bucket, we simply point Imgix to our S3 bucket using the provisioned key and secret from Amazon. All images will then be proxied from our server through the Imgix service, allowing us to use a simple URL to add filters and change formats on the fly!

For example, the following URL would provide us with an image the meets the criteria set above:

https://your-app.imgix.net/cat.jpg?w=200&h=200&fit=facearea&faceindex=1&dpr=2&fm=webp

If we examine the components of the URL, it’s easily understood that:

https://your-app.imgix.net is the Imgix source URL that we set up on our dashboard /cat.jpg is the file that we are fetching from S3 (or the Imgix proxy in our case). ?w=200 specifies that the width should be 200 pixels. &h=200 specifies that the height should be 200 pixels. &fit=facearea controls how the output image is fit to its target dimensions. &faceindex=1 selects a face to center an image on, but only when the fit parameter is set to facearea. &dpr=2 makes it possible to display images at the correct pixel density on a variety of devices such as Apple Retina displays and Android devices. You must specify a width, a height, or both for device pixel ratio to work. The default is 1. The maximum value that can be set for dpr is 8. &fm=webp specifies the output format to convert the image to. Valid options are gif, jp2, jpg, json, jxr, pjpg, mp4, png, png8, png32, and webp.

(in the example above, the “facearea” and “faceindex” parameters are preset terms used by Imgix to do facial position location within an image)

The first time the image is called with these parameters, Imgix will cache the resulting image on one of their geographically positioned CDN servers; subsequent calls with the same parameters will not need to reprocess the image. Imgix will then propagate the image to all other CDN servers around the world, as shown on the following map.

Initial Setup

Getting started with the Imgix API is extremely straightforward. Sign up for an account at https://webapp.imgix.com/sign-up (they’ll even credit $10 towards your account), and, follow the Getting Started documentation on the Imgix website.

Dashboard

Imgix put some serious effort into designing a user-friendly experience with their dashboard. You can easily add new origin sources (such as other S3 buckets, or your own self-hosting), monitor utilization and activity, bandwidth usage, and invoices all from a single interface — all without introducing complex queries or an unintuitive navigation.

Pricing

Imgix has simplified pricing with only two tiers from which to choose:

The Standard plan, $3 per 1,000 master images accessed each month, plus 8¢ per GB of bandwidth.

The High-Volume plan, for high bandwidth customers with complex integration needs, additional support, and discounted pricing starting at $500/month. This plan also offers an SLA and custom pricing.

Hardware Decisions

So what exactly makes Imgix great?

In our opinion, their hardware and sheer amount of compute power for image manipulation. No player in the game has come close to offering a scalable solution that is as fast and reliable as Imgix.

At scale, maximizing efficiency and performance in image processing is critical for success. Imgix chose to operate their own hardware and datacenters and manage their own network infrastructure. Best of all (you won’t believe this), they incorporated Mac Pros into the the Imgix rendering infrastructure.

By going with Mac Pros for rendering, Imgix is capable of providing excellent reliability, maintainability, and performance.

Software Choices

All of the graphics processing is built in C, Objective-C, and Lua, to handle the insane number of images Imgix has to process every day (over 1 Billion images per day). These low-level languages provide what Imgix needs to meet speed, agility, and autonomousness requirements.

To be lightning fast, and as smart as possible, Imgix leverages quite a bit of open source technology. Ansible handles configuration management while Consul manages service discovery. Prometheus is used for monitoring, which plugs into the company PagerDuty account.

Front-end services are completely separate from the core infrastructure. They are built using Angular, Ember, or Tornado depending on the task. These services provide web interfaces to configure and administer Imgix accounts.

Separate Docker containers are used for development, testing, and production for each front-end project, with CircleCI handling the testing cycle for internal services, in addition to Travis CI for our open-source projects and libraries.

Engineering at Imgix

The engineering team is highly skilled and proven effective at scale. Their combined backgrounds include operations and engineering teams from YouTube, Google, Dropbox, Foursquare, and Yahoo.

Downsides & Alternatives

For some, Imgix isn’t always the go-to API for image processing. There are a few obstacles that we have faced developing on their API:

There’s no free tier to try their service. They do allow for a trial period in which they provide a $10 credit towards your account (you can cancel anytime). This makes ImgIx less suited for hobbyists projects or small open-source projects.

If you’re not using one of their provided SDK libraries, the URL parameters are difficult to work with manually with over 80 combinations of filters and transformations. We’d like to see a simple REST endpoint that accepts a JSON payload for developers who don’t want to generate long URL’s.

For Imgix to process an image, you must either serve the image from your own CDN or sign a URL using a MD5 hash. This blocks developers from using image assets from third-party websites as you can’t dynamically sign URLs without leaking your API details from Imgix.

Larger customers processing thousands or millions of images hosted on other CDNs, S3 or GCS will incur secondary bandwidth costs as Imgix pulls those images the first time.

You have to contact support in order to use your own custom URL or domain name. Not a deal breaker, but the provisioning process takes some time and as a developer, you probably want to move quickly and this kind of self-service feature would be nice to see.

There are alternate services that you can look into if Imgix doesn’t suit your needs. Some competitors to Imgix include, but are not limited to:

Final Thoughts

We’ve taken you through a technical deep dive on image optimization, the Imgix architecture, and their software choices. Armed with that knowledge, we hope you understand why we highly recommend using Imgix for all of your image serving needs. At the very least, you should use it to significantly decrease load times for your end users. ;)

Imgix provides a no-hassle, quick and easy setup process to get you on your way by providing an agile, scalable image oriented product in your sector.