At 10up we have a guidebook of engineering best practices that all our teams follow. Now that responsive images finally have good browser support, we’ve been trying think through best practices with responsive images.

Some questions:

• Is there a “best practice” for sizes to generate?
• Should all images be generated at multiple sizes and updated with srcset values?
• How will using srcset impact page weight (i.e. worth the effort)?

My initial assumption was “yes”, we should be using responsive images whenever we’re outputting a featured images. Using the “correct” size image can lead to huge performance gains.

But as I started to look at real world use cases, it got complicated. Let’s take a look at Twenty Fifteen as an example.

Featured Images in Twenty Fifteen

Twenty Fifteen uses featured images with a defined size of 825px by 510px.

set_post_thumbnail_size( 825, 510, true );

When using responsive images (srcset), the developer needs to let the browser know how large the image is in relation to the viewport. In Twenty Fifteen, there’s three important breakpoints where the size changes.

Small Size Screens

On small screens (less than 620px), the image is 100% of of the viewport, or 100vw. In pixels it can be anywhere between 0-620px.

Medium Size Screens

On medium size screens (620px – 954px: min-width: 59.6875em), the image takes up 84.6154% of the viewport due to the margins on each side. In pixels, this means the image can be anywhere between 525px – 807px wide.

Large Screens

On large screens (955px-1402px: min-width: 59.6875em), the image takes up 58.8235470588% of the viewport due to the sidebar and margins. In pixels, the image can be anywhere between 562px-825px.

X-Large Screens

Above 1403px (min-width: 87.6875em), the container becomes fixed and the image does not expand beyond 825px.

What Sizes Should We Generate?

If pixel density were the same on all devices, this would be a fairly easy question to answer. You could look at Google analytics data from your site and find the most popular screen sizes to support.

However, a lot of mobile devices have screens with higher pixel densities (retina), which means we can’t trust the resolution size in Google Analytics entirely.

As an example, here’s analytics data from an e-commerce site I’ve worked on in the past:

The top iPhone in this data set has a 320×568 resolution, which would likely be an iPhone 5, 5S or 6. Since these are retina devices, the browser would opt for a 640px wide image if one is available in the srcset sources.

The 768×1024 iPad is likely a Mini or 2nd Gen, which is not retina. So the image size it would ideally use is 768px * .846154 (viewport width), or 650px.

The 375×667 is likely an iPhone 6+, also retina, so we’re looking at 750px.

Conclusion?

Based on data for this site there would be a good case for generating an additional image at 650px. Image file sizes decreased by 25%-35% when I regenerated a few images to check.

Since there’s also a lot of iPhone 6+ users, it might also make sense to generate another size at 750px, even though the bandwith savings wouldn’t be as great.

But is there a case for always generating a 640px-650px size image for srcset if the default featured image size is larger?

Counter Example

Let’s take a look at analytics data from another site (wptheming.com):

This site caters to a more technical crowd (most likely developers trying to get work done) and as a result there’s not a lot of mobile traffic. You have to get pretty far down the list (#12) before we even hit a small screen device.

Would it be worth the time investment to update this site with responsive images? Probably not.

Best Practices?

Let’s go through the original questions again.

Is there a “best practice” for sizes to generate?

I don’t think it’s possible to generalize for all sites. You’ll have to look at analytics data and see what types of screens people are using. If there’s a lot of visitors using iPhones, 640-650px might be a good size, but this will continue to evolve as new devices become popular and pixel density increases.

If someone disagrees, I’d love to hear an alternative suggestion. It would be really nice to have a few standard sizes that generally work…

Should all images be generated at multiple sizes and updated with srcset values?

It doesn’t makes sense for all images. Since most new mobile devices have higher pixel densities, in most cases it won’t make sense to generate images smaller than 640px.

If your site has large headers or large full screen images (let’s 960px+) and a good amount of mobile traffic, I would recommend using responsive images as a best practice.

This could change in the future though. As responsive images become more mainstream, browsers for mobile devices may choose to start using smaller images (non-retina) when bandwidth is constrained. I don’t know if any browsers are planning this, but it would certainly make a lot of sense.

How will srcset effect weight?

If smaller image sizes are generated and used in the srcset attribute (and the browser serves those), it should improve overall page weight (i.e. decrease it).

There are cases where overall page weight could increase though. I’m generally most concerned with performance and speed, but serving higher quality images to retina screens may be a more important consideration for some sites (a graphic design portfolio for example). In those cases, you may want to serve larger images in the srcset and that could increase overall page weight.

Final Thoughts

It’s very exciting to have responsive images in the toolbox, but just like responsive web design there’s now added complexity in building sites.

WordPress gives us the ability to auto-generate images at multiple sizes, which is a really great feature. But we still have to determine ourselves what the best sizes are in terms of performance and design and give hints to the browser in order to serve them properly.

In the next post, I’ll explain how to use responsive images in a WordPress theme. I’ll be using a Twenty Eleven child theme I built and functions from the RICG Responsive Images plugin which may eventually get rolled into WordPress core.