Sessions is temporarily moving to YouTube, check out all our new videos here.

An Introduction to HTML5 Responsive Images

Roland Schütz speaking at viennaJS in May, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

This opinionated 5min talk will motivate you to use responsive images everywhere.


- Okay, welcome. I want to give a short talk today about responsive images. Many of you have heard of it, I'm sure many of you use it. Many of you, maybe not. The basic idea of responsive images is, a long time ago, the concept of a website was this, was basically a similar browser size, and you put the image in in the right size and everything was done. And now, since a few years, we have various way different screen layouts. Some people use an iMac 25-SOL display, many use a smartphone, and there's a big range between. So, just one image doesn't fit anymore. So, there are two reasons why we want to do responsive images. The one is called Art Direction. The basic idea is I want to show a different screen, picture, depending on the screen size. And the second one is straight up performance. I don't need to load the image quality for an iMac on my smart phone. Makes no sense. So, about art direction, that's a very simple example of what art direction could mean. So you see there are different images and they are chosen, depending on the screen size and the screen layout. So in a smaller one, I want to focus more in on the key part of the image, and on bigger screens I want to give more of the surrounding. If you would use that image on a smart phone, we'll probably not understand what it's about. There is a very simple HTML solution for that. It's called the picture element. There's a polyfill JavaScript solution for that, that's why I can use it as a JavaScript talk, but basically, it's implemented in all important browsers. The reason why it's done in that structure is so it still works with old browsers. The picture element, into that you have an image element, this is the fallback element, in a normal screen size and in different pixel densities. So you have smart phones, for example, or Mac Books, which have more density. You can provide high density solution for that, and then this is the part which is new. So depending on a media query like code, you can say for different screen sizes, I want to show different pictures. And it goes from top to bottom. And the first thing that matches is applied. So if I have a 1000 pixel screen, it would apply here, if I have 500 it falls through and applies here, and if they all are not matching or if the browser sucks, it takes this one here. Yeah, that's everything you need to know about art direction. In most cases you'll not work art direction because it's way more work to produce the content, meaning the images in a lot of different solutions, basically, different pictures, depending on what you want to show. There are some libraries and tools to try to automatically guess that and make smart decisions, and it kind of works, but most cases is way over-engineered for what you want to do. The even more interesting part is performance. And it's even more interesting because Google really pushes that. So right now, if you do the page speed test for your website, Google will give you a really bad rating if you just use one image size for everything. And the basic idea here is, I want to give different qualities of the same picture and so that each device gets exactly the quality they need, not more, not less. Or, might be a bit more, but not too much. So here, I have a image with a default source for 200 pixels wide, and then I have two new properties. One is called sizes, and sizes basically says how big will the image be compared to the browser size. So right now, this will be always 50% of the screen width, will be the image. So if my screen is 200 pixels, it will be 100 pixel, if my screen size is 400 pixel, it would choose the 200 pixels. And there's another cool thing which it does automatically. If you have a screen which is only, or, let's use a better example, actually, it's on the next page here. So it also thinks about the pixel density of your devise, and it really automatically chooses the right picture. So if you have a 400-pixel browser width, with a normal density of one, it chooses the 200, because it's 50%. But if you have a pixel density of two, something like an iPhone, it would chose the 400. And so on. So one time per layout, you have to think about this big thing here at the top, and then everything else goes automatically, which is really cool. See these as a SPIDER code solution. The part at the top is you define the sizes, which is basically how your layout behaves, or how the picture size behaves according to your layout. So you see on my mobile, I would simply show the picture full-width and then I have different break points where the image sizes changes. Basically, it's a multi-column layout so the bigger you grow, they have different sizes. No, actually, in this case, it's not that. In this case, it's always full-screen, but with a fixed maximum. And then here, the idea of the source set is that you want to compress down different sizes for the image, and the browser figures out the rest. And see really more you have here, the browser can choose, but the more server load your browser has, your web server has to first grade them, like thinking you have a CMS system and editor uploads a picture, now the CMS has to resize it in four different sizes. All right, and that's actually it about responsive images. I wanted to mention two other things. The first one, if it's not about real images, but if it back to graphics, always choose SVG. It basically works in old browsers, it's more performance and still better quality so choose SVG. And the second part is I would only think about responsive images for every picture which is more than 400 or 500 pixels and I would still even have an upper limit, depending on how much performance would be assigned is important. Something between 2000 and 2500. Don't deliver pictures more than 2500 pixels even if you have a big iMac, or whatever, because it really slows down your website. Any questions?