Thoughts For The Future Of Responsive Images

Posted: 06 Jan 2014 05:30 AM PST

What’s the best way to approach responsive images? Is there a best size image to use? A best resolution? How about a best format? We have so many things to think about when it comes to images and responsive design. I’d like to offer a few other things to think about that ideally make answering many of the questions we now ask easier.

Before the holidays I started a series of posts on responsive images. First I talked about the general issues we face and then I pointed you to what I hope are enough resources to help you find solutions for your specific needs.

Today I want to continue the talk, but from a higher level. Instead of talking details, I want to think long term about how we should think about and use images on sites.

How Should We Think About Responsive Images?

As long as I’ve been developing websites images have caused performance issues. They require an http request and are generally among the heavier elements we add to any web page. They’re significantly heavier than text.

Perhaps one day bandwidth won’t be an issue, but until that day comes, there are a handful of things we should be doing and thinking about.

Use less images
Replace images with code where possible
Prefer vectors where possible
Balance the performance and quality of bitmapped images
New image formats

Let’s talk about each in a little more detail.

Use Less Images

We should only use images that enhance the communication in a design

Images add a lot of interest to websites. Each is worth 1,000 words, right? However, those 1,000 words are in regards to what’s communicated and not digital weight. 1,000 words will weigh far less and cause far fewer issues when it comes to how we display and how we transmit them over limited bandwidth.

Until we reach the day where bandwidth is no longer an issue, images are going to be a performance concern. I don’t see that day arriving in the immediate or near future. For now I think we should consider using less images. I’m not saying we shouldn’t use images at all, but I’m suggesting we think about the purpose of an image before adding it.

What does the image communicate?
Is the image purely eye candy?
Does the image serve some purpose
Can you justify the use of the image?
Does that image really need to be there?

I used to add more images to posts here, usually one above each section header. I realized that most of those images weren’t necessary. They served more as eye candy than anything else. I now use only a single image at the top unless other images aid in communication.

Ideally the image at the top is communicating what the post is about and it’s meant to help draw a reader’s eye further into the writing. You might argue the one image isn’t needed either, but it’s certainly less than what was here before.

With less images, posts load faster and there’s less of them to deal with across devices and conditions. Since the extra images weren’t adding anything essential it was an easy decision to no longer use them.

The first step then in dealing with images is to decide whether or not you really need to use them and to stop using those that don’t add anything to your design.

Replace Images with Code Where Possible

Years ago websites were developed by slicing a Photoshop file into blocks and then placing all those blocks inside an html table. Images were much of what you saw on a web page. Ideally the text was text, but most everything else was a background image behind a table or table cell.

Even after things moved away from tables and toward a combination of divs and css, the practice of slicing and dicing .psd files continued. Too often images were used for things that could have and should have been created in code.

I used to cringe whenever I’d come across a solid block of color that was created with an image. I could’t understand why the designed didn’t code it with a background-color. Borders around elements were another common part of an image that could easily have been replaced using css border properties.

Today we can do even more with css and what we can do is only going to increase in the years ahead. We’ve moved beyond solid blocks of color and borders. Code can be used to create:

All of these things can be created without images. In some cases browser support isn’t great, but it won’t be long before it is great and before we can do more with css. Where possible look to replace images with code.

Prefer Vectors Where Possible

Of course, not every image can be realistically recreated with code. Sometimes only an image will do. When that’s the case try to use vectors over bitmaps wherever you can.

Vectors generally weigh less than their bitmapped counterparts, as they’re mathematically based. That math makes them flexible by default without any degradation in quality or performance. You don’t have to swap out a high quality image for a lower quality one in the name of performance. The math is the same and one image fits all.

Choose icon fonts or scalable vector graphics (SVG) where you can. They’re flexible, weigh less, and maintain quality at different sizes. They won’t solve the issue of art direction, but they do solve most issues around performance. Digital dimension make no difference to the weight of vector images.

Balance the Performance and Quality of Bitmapped Images

Not every image can be represented by a vector. Photographs still require bitmaps. Anytime we need to add photographic realism we’re going to use a bitmapped image. These are the images that really lead to most of the issues we face.

When using .jpgs, .pngs, and .gifs we should strive toward a balance between performance and quality. Ideally if we’ve used less images, replaced some with code, and used vectors where possible, we’ll be using less bitmaps overall.

Less bitmaps means less performance woes. It might even be ok to deliver your bitmaps in the highest quality because you’re using only one or two. The net reduction in performance may not be that significant with so few images.

When it is, optimize every image at a minimum. I’m still amazed when I find images needlessly weighing hundreds of megabytes. We can also learn which image format is best for a given image. Does it weigh less as a .png, .jpg, or .gif?

Another thing we can do is observe and learn what in an image causes it to weigh more. Do color images weigh more than black and white images? Do gradients weigh more than images with more distinct color transitions? Sometimes the right image will be the one that weighs more. Sometimes a heavy image can be replaced with a lighter one without any loss in communication.

After that you can then pick and choose from the different solutions I pointed you to in the previous post in this series if you want to do more.

You might also choose to ignore those solutions, given you’re dealing with fewer images. Balance is the key. What are the pros and cons of the different solutions and are they worth the cost and effort for your project?

New Image Formats

One of the possibilities that intrigues me is the potential for a new image format that handles most of the work for us. Instead of swapping images through code, the image container can serve the most appropriate image within.

Yoav Weiss has some interesting ideas for how this might work and since he can do a better job explaining them than I could, I’ll refer you to a couple of articles he’s written.

By no means would a new image format be an all in one solution to every responsive issue, but it would become another tool that could help solve quite a few of them.

Summary

Images have always caused performance issues and they continue to be a bottleneck. When you really think about it though, it’s a certain type of image under certain conditions that tend to cause most of the problems.

Ideal solutions to these problems don’t yet exist. Until they do and even after they do I think we should put more effort into thinking about the images we use.

We should only use images that enhance the communication in a design and we should avoid using images that contribute little. Where possible we should use code and when we need an image we should prefer vectors. This will lead to less bitmapped images, which are the ones that really cause the issues we face.

Using less bitmaps should mean we have fewer instances of issues to deal with. It won’t solve the issues we have with specific images, but it should lead to less specific issues we have to solve.

If you liked this post, consider buying my book Design Fundamentals

The post Thoughts For The Future Of Responsive Images appeared first on Vanseo Design.