Understanding Image Compression: Tooling and Context
Post from May 22, 2019, filed under Web Development.
Image compression is an important part of performance optimization. Image compression seems straight-forward but is, as many developers know, a little deceptive, because it consists not of one but two parts—and it’s usually lack of understanding of one of these two parts that causes image compression not to be performed effectively, or at all.
What are the two parts?
There’s a tooling part dealing with the infrastructure to both * manually and automatically compress images. This is the prominent part, the part that improves or ensures performance.
Then there’s a context part dealing with a) what image can be compressed how aggressively as well as b) the necessary information flow for team and tools, so that each image is being optimized as much as possible without losing its ability to serve its purpose. This part is about quality.
What happens in practice is that compression is sometimes confused and oversimplified with tooling—one part of compression. The other one, then, is easily neglected, if not missed: What kind of image is being optimized (like, photograph or icon?), and where is it used (like, foreground or background?)—context. Our tools cannot, so far, determine this context on their own. And with tooling that is just that, contextless algorithms, we find some teams struggle, not dealing with image compression effectively, or at all.
Figure: Publishing scenarios from FAZ, Demeter, and kicker, and to compress respective images effectively, one needs to understand how they’re used—for optimal results, there’s no “one size fits all.”
Differentiation, as so often, can inform the approach. We know that the problem has never really been complexity with respect to tooling—but said context: Teams may not have enough information to compress images, neither manually nor automatically; developers may not (be able to) instruct their tools what images can be compressed how aggressively or, one step away, designers may not instruct developers on what images are used where, and can therefore be compressed to what extent. Neither, then, has our information architecture ever been prepared to reliably reflect context (as with, for example, something like a semi-standardized “icons” folder with images to be compressed most aggressively).
When we differentiate between tooling and context, we can do two things: First, we still set and hook up the necessary infrastructure for image compression (editor plugins like Image Optimizer for VS Code, standalone apps like ImageOptim, packages like imagemin, &c. pp.). Second, we can look into the information flow to make sure context is given and known to decide on the degree of compression and whether automation is an option.
As most of the more technically-minded readers can tell, image compression tooling is really rather easy to set up. But as context, with its entirely different challenges, decides on the degree rather than the fact of compression, proper distinction is the key now to overcome even a technical veil of ignorance: We can set up tooling, automated tooling, that simply compresses everything losslessly (while guarding against regressions when processing already optimized images), to tackle more aggressive optimization once we’re sure about all relevant context.
Tooling and context. Both needs to be available for image compression to be most effective. As there’s still more to cover, I’ll pour out some more thoughts shortly 🖐
* Automated compression would suffice if there wasn’t a real need to also allow for manual compression, and to also make that compression easy. This is for two reasons: One, for the situation when image compression is set up in a running project, where compression over all assets may need to be triggered manually, for a start. Two, for the observation that projects, especially when more complex, will always mean some uncertainty to be accounted for, requiring failsafes. Compression shall therefore also be something to be triggered manually as well.
About the Author
Jens Oliver Meiert is a technical lead and author (sum.cumo, W3C, O’Reilly). He loves trying things, including in the realms of philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.
If you have any thoughts or questions (or recommendations) about what he writes, leave a comment or a message.