Tips to load images faster, and how imgix serves 1 billion images/day
Most websites have images. Some have a lot of images.
But how many of those images are optimized? Well, what do I even mean by optimized?
By optimized I mean that images are:
- Sized for the container they are served in (ie: an image of 800x400 pixels in a container of 400x200 pixels is a waste)
- Compressed and stripped of useless metadata
- Served as close to the user as possible
- Properly cached
- Served at the right image format depending on the browser (like WebP for Chrome instead of JPEG)
Yeah…you’re probably not doing all of those things... I know I’m not. I’m not doing #1 or #5, which are both quite important.
I also know that this is costing me (and you) more $$$ per month, because we’re paying for more bandwidth usage. I also know that it’s adding load time, which could give users a sub-optimal experience.
I don’t like that at all, so I sat down with an expert, Kelly Sutton, to ask him what I should be doing. Kelly works at a company called imgix, which offers a solution to this problem and serves 1 billion images per day. I got pretty excited, because that meant I could talk to him about scale and I could get help on optimizing images at the same time. Nice, right?
Let’s start by getting to know Kelly and imgix a little bit more, and then we’ll jump into image optimization tips & tricks.
The following is an excerpt of the full interview.
Who is Kelly Sutton?
Kelly is the Chief Product Officer at imgix.
He manages the product and everything that it touches. For a service like imgix, data is very important to them. Keeping a close eye on this data, and staying informed on how current (and future) users use the product is important. It helps them make decisions on how to improve the product, and how to schedule new features.
What is imgix?
imgix is a real-time image processing solution.
A what?
Technically speaking, imgx is an image proxy. It can resize, process, add filters, and change formats of images just by changing URL parameters.
They like to call it “the graphics card for the internet.”
Their founder and CEO, Chris Zacharias set out to solve an issue that he discovered while working at YouTube. They were having a hard time managing so many thumbnail images, so he assumed that this was a problem a lot of other companies had as well.
What does their architecture look like?
There is a clean split between the web architecture layer (which serves the website and user dashboard) and the image proxy layer.
The image proxy layer is designed to sit between the origin (where images are stored) and CDN. It is in charge of processing images in real-time if they’re not already cached in a CDN. If they are cached, there’s no need to go any further than the CDN.
When an image isn’t available in a CDN, the request is sent to imgix’s proxy layer. That layer needs to have the image stored locally to process it, so it will fetch it from the origin. The origin can be a customer’s S3 bucket, or wherever they store images.
Once fetched, the processing begins. Mac Pros handle the graphics processing. That’s right, they run on their own hardware and had to create custom racks with the help of Racklive. The data center is down in Santa Clara.
They do use some open source tools on their machines, like:
And a handful of others.
There is also a decent amount of custom built code. All of the graphics processing is built in C, Objective-C, and Lua.
The reason for this is because of the number of images they have to process every day. It needs to be lightning fast, and as smart as possible. These low level languages give you access to what you need in order to meet these requirements.
If you don’t have access to image experts, here’s how you can optimize
How imgix works is really interesting, but I wanted to get tips on optimizing images even if someone didn’t want to use the service. Here’s what we came up with.
- Resize images
The best thing you could do if you’re trying to get the page weight down, is to resize your images.
Just the simple act of making sure that you are serving an image the size of your container (ie: container width = 600px, image width should = 600px) is a big optimization.
2. Optimize image quality and compression
Even if you don’t load an image sized to a container, you should still resize and change the quality of the original image before uploading it. This can easily be done with software if you don’t have a ton of images.
You could even do it in Photoshop, by using Save -> Save for Web -> Choosing a new quality. Though, that’s a bit manual.
For a faster method, you can use Gulp image optimization packages.
These packages compress and strip out unnecessary meta data, slimming down the image weight (sometimes by quite a lot). Other alternatives: TinyPNG and TinyJPEG.
3. Use a CDN
Just like we talked about in the Max Schnur (Wistia) interview, latency is a big problem. Even if you have access to a lot of bandwidth, latency limits how quickly you can receive data.
How fast can you get the first byte? Reducing that time is key to loading images and pages faster. CDNs are a solution.
4. Set Cache-Control headers
Cache-Control headers dictate how an asset is cached. By having a local copy of the asset, we eliminate network latency.
More on cache headers here.
5. Serving the right format
Wait, shouldn’t we just stick to JPEG and PNG?
While these formats are extremely popular, they are quite old and don’t have the best compression algorithms.
Chrome supports a format called WebP. They claim that WebP is 26% smaller than PNG and 25–34% smaller than JPEG, at the same image quality.
Then, why aren’t we all switching to it? Because it’s not currently supported by every browser. Bummer, I know.
If you still want such savings, you need to add logic that fetches the correct image format depending on the browser. ~30% can make a pretty big difference…
When images take a while to load, how can we make the page load feel fast?
It really depends on the scenario.
If you’re loading a very high resolution image in a lightbox (like a popup window), there’s probably going to be a navigation step immediately before that. So instead of showing the high resolution image in the thumbnail, show a much smaller and more optimized version. If you don’t, you’ll have that really slow load from top to bottom.
You could also perform this trick that I’ve seen on websites like Pinterest and even Medium. While the high resolution image is loading, the container holding the image is filled with a very pixelated version of that image. Or, it can also be filled with the dominant color.
Once the main image is ready, swap it out. This results in less “strain” on the eyes, and makes it perceived to be fast, because the pixelated picture/color has far less bytes to download than the real image, so it’s displayed very quickly.
Full interview
We covered quite a bit in this interview, but this is just a preview. If you’d like to learn more, head over here or check out the video:
There’s plenty more like this on my podcast. In fact, I’ve got an interview coming up in a short week with Ilya Grigorik on web performance and HTTP/2.
If you want to know as soon as it’s out:
Did this post help you understand image optimization better?
“Always be scaling” — Christophe
