In our last post, we talked about why images are getting increasingly complicated on the web. It’s a challenge we’ve put a ton of time into solving here at Bethel so that our system is easy to use for authors, designers, and developers.
To create the right solution, we needed to resolve 3 big issues:
- Creating different sizes of the original image automatically
- Uploading original images into the CMS
Selecting the Correct Image – Imager.js
Another thing we liked about Imager was that it loads images by the exact width, rather than using generic identifiers like “small”, “medium”, “large” to specify size. This helps us follow our third rule from the last post, “don’t serve a bigger image than you need.” Imager will select the exact size to fit the screen area. I won’t go into the coding specifics, but it’s documented well and easy to use.
Once we had Imager working correctly, the next problem was figuring out what to do with tons of different sizes of the same image. Dumping them into our CMS would make the system very cluttered and unfriendly. So it was time to look into solutions for automatically creating different sized images of an original image outside the CMS.
Creating Image Sizes – Thumbor
After some searching, we found a Python application called Thumbor.
Thumbor is pretty easy to install, and very easy to use. You simply call the Thumbor service using a URL and send a few parameters. Most notably, you send a width and height. Then it will download the original image, resize, crop if necessary, and return the new image. This means we can put Thumbor URL’s directly in our <img> HTML tags and it will work just like a normal image.
Remember how Imager used exact pixel width instead of a size? This was perfect for Thumbor. It was extremely simple to configure Imager.js to work with a Thumbor URL using an exact width.
Thumbor also has a few other neat tricks. First, it can set the height of the updated image automatically based on the width. It also stores versions locally. So if you request a 300px-wide image, it will resize, crop, and return that image. But it will also save a local copy, either on the filesystem or in a database. This means that next time you request the same 300px-wide version of the image, it won’t have to resize, crop, and return. It will simply return the smaller version it saved. This means that Thumbor overhead is extremely small. It only has to crop an image once. This made meeting our second rule, “have your resized images ready to go before they’re needed” pretty easy. Thumbor stores the versions for us.
To make it even faster, we have a simple script to request popular sizes of Imager from Thumbor when each image is uploaded. This means all our images will be available when we need them.
So once we had Imager and Thumbor working seamlessly together, the last step was pretty simple.
Now there’s only one rule left to worry about, “always upload the largest copy possible.” Unfortunately, there isn’t some fancy Python script to make sure our web contributors upload the largest image size possible. This step requires some training. However, there might be a few helpful things you can do depending on your CMS. Maybe you can set a minimum width and height for new image uploads? Or a minimum file size? Who knows…just brainstorming.
But once the image upload process is actually started in the system, we can start having some fun. The first thing we do when an image is uploaded is automatically upload it to the server. Nobody thinks to publish an image after upload anyway. The CMS automatically pushes this image to the CDN, which triggers the script to request the different widths from Thumbor. This means that there are now 5, 10, 15, or even more versions of the image ready to go.
The best part? The web contributor can work with the image within the CMS just like normal. They have no idea that the image they are working with is never actually used. And that’s not a problem at all. They embed their image onto a page, and the template configures Imager to create the Thumbor-friendly URL inside the <image> tag. And then, when the page itself is published and viewed, the resized images are ready to go, just like any other images.
Aside from a few installs and a little template work, it’s completely seamless for authors, designers, and developers. And, to top it all off, no overhead for end-users. Just like that, we’ve created a 2007-style way to interact with images that works seamlessly with 2014-compatible complexity.