Image optimization will always be a balancing act between quality and file size. The higher the quality of an image, the bigger the file size. However, there are some best practices that, when integrated into your development workflow, make optimizing images for the web simple and painless.
The 3 most common image types found on the web are GIFs, JPGs and PNGs. None the wiser, you may think to use whatever file type is delivered to you or most readily accessible. This is the first bad habit to break.
Best Practice #1
Use JPGs for photos and images with gradients; use GIFs for animated images; use PNG for images with fine details or large color palettes, images with text and images requiring transparency.
Here’s a decision tree that will help you quickly figure out which file format is best given your situation:
(Image stolen from Ilya Grigorik’s 2014 developers.google.com post on image optimization.)
There’s a couple side notes worth mentioning regarding this best practice. For one, avoid using images where text has been flattened onto the art. This is poor for SEO, poor for web accessibility and also adds to file sizes. It’s better to program the text onto a web page than to encode it into an image. True, this can become a balancing act between extra HTTP requests for web fonts that may or may not render as nicely as text exported with an image straight out of photo editing software, but it’s worth consideration. Two, if you’re exporting an image from photo editing software, like Photoshop, don’t just do a “Save As”. Doing this makes web assets unnecessarily big. Saving an asset in this manner often includes meta data that’s not needed, like thumbnail previews. Export images using the “Save For Web & Devices” option, and don’t be afraid to play around with the settings. Often times you can lower the quality level of exports significantly without any noticeable distortion or pixelation. Three, consider using the SVG file format for vector images, and when scalability is a concern. Compression of SVG images is great and browser support is mostly all there, too.
If you’re like me, you’ll often find yourself receiving assets from a client. These assets are likely just whatever the client had on hand from a past project or what a designer created, unsure of the context in which their designs would be used. You ask for a high-resolution version of the client’s logo and you get a 300dpi image sized 1920px by 1080px. This is not an image asset you want to load on any web page.
Best Practice #2
Re-size your images to the smallest size necessary. Delivering scaled assets is one of the simplest and most effective optimizations.
This gets tricky when we start considering serving images responsively, or when we think about all the different devices to which an image may be served. But the thing you definitely don’t want to do is stick a 300dpi image that’s 1920px wide into a spot on your web page that you know will, at most, only allow for display of an image sized 480px in width. Re-size the asset to a width of 480px to save a bunch of bytes. Likewise, the only difference between a 300dpi image and a 72dpi image, when used on the web, is the time and bandwidth it’ll take to load the asset. Always save down at 72dpi. The fact of the matter is that DPI, or Dots Per Inch is only a concern of printed material. For retina displays or other high density electronic displays, consider saving and serving multiple versions of the original images sized to different dimensions, as needed, rather than one version of the original images saved at a higher DPI. A square 200px image displays as that on the web regardless of DPI setting.
Another thing I like to do when re-sizing images is use Photoshop’s Trim feature (Image > Trim…). A lot of times clients will give me an asset, like a logo, with a usage guide that says the asset can’t butt up against other elements or the logo must always be surrounded by N amount of padding. No problem there. The problem is that often times these assets have the padding included as part of the original image in an attempt to enforce the usage guidelines. That’s unnecessary and makes the image size unnecessarily large. I like to trim down padding on assets like this, preferring to set spacing with code, keeping the image files as lean as possible.
Sometimes, though, there just isn’t enough time to edit and re-save all of your image assets. What can easily be done to one image would take way too long to do for dozens or hundreds of images. I get that. But if you have time for nothing else in terms of image optimization, there is one thing you should always—no matter what—make time for.
Best Practice #3
Always be automating. Find an image optimization and/or compression tool that fits in your workflow and use it on every project.
For me, that tool is Voormedia’s image compression suite: TinyPNG and TinyJPG. If I have time for no other optimizations, which is often the case, I’ll at the very least run all my images through either TinyPNG or TinyJPG. You can batch compress up to 20 images at a time and those images can be up to 5MB each. That typically covers my needs. (If I’m ever hitting either of those limits, I know I need to re-think what I’m doing.) There’s no messing around with values, and the default compression algorithms are highly reliable in my experience, meaning you don’t get unexpected outputs with pixelation/distortion. I typically see a 50-60% file size reduction running images through this tool, a step in my process that takes only a couple seconds to execute.
Conclusion
I read once, somewhere, as a general rule you should try to keep your image files under 50K for GIF and PNG and under 70K for JPG. Sure, sounds reasonable. The more important thing is that your workflow incorporates an image optimization step. Doesn’t matter if you’re a back-end developer who tries to stay as far away as possible from art, assets and design, or you’re a designer who knows only the basics of HTML and CSS. Image optimization is a must for anyone concerned with creating a great user experience on the web.
Leave a Reply