The devil has put a penalty on all things we enjoy in life.
Sixty-two percent of the weight of the web is images, and we’re serving more image bytes every day. That would be peachy if all of those bytes were being put to good use. But on small or low-resolution screens, most of that data is waste.
Why? Even though the web was designed to be accessed by everyone, via anything, it was only recently that the device landscape diversified enough to force an industry-wide movement toward responsive design. When we design responsively our content elegantly and efficiently flows into any device. All of our content, that is, except for bitmaps. Bitmap images are resolution-fixed. And their vessel—the venerable img with its sadly single src—affords no adaptation.
Faced with a Sophie’s choice—whether to make their pages fuzzy for some or slow for all—most designers choose the latter, sending images meant to fill the largest, highest-resolution screens to everybody. Thus, waste.
But! After three years of debate, a few new pieces of markup have emerged to solve the responsive images problem:
srcsetsizespicture- and our old friend
source(borrowed fromaudioandvideo)
These new elements and attributes allow us to mark up multiple, alternate sources, and serve each client the source that suits it best. They’ve made their way into the official specs and their first full implementation—in Chrome 38—shipped in September. With elegant fallbacks and a polyfill to bridge the gap, we can and should implement responsive images now. So, let’s!
Let’s take an existing web page and make its images responsive. We’ll do so in three passes, applying each piece of the new markup in turn:
- We’ll ensure that our images scale efficiently with
srcsetandsizes. - We’ll art direct our images with
pictureandsource media. - We’ll supply an alternate image format using
pictureandsource type.
In the process we’ll see firsthand the dramatic performance gains that the new features enable.
The status quo#section2
I guess I don’t so much mind being old, as I mind being fat and old.
We take as our subject a little web page about crazy quilts. It’s a simple, responsive page. There isn’t much to get in the way of its primary content: giant images (of quilts!). We want to show both the overall design of each quilt and as much intricate detail as possible. So, for each, we present two images:
- the whole quilt, fit to the paragraph width
- a detail that fills 100 percent of the viewport width
How would we size and mark up our images without the new markup?
First up: the whole quilts. To ensure that they’ll always look sharp, we need to figure out their largest-possible layout size. Here’s the relevant CSS:
* {
box-sizing: border-box;
}
body {
font-size: 1.25em;
}
figure {
padding: 0 1em;
max-width: 33em;
}
img {
display: block;
width: 100%;
}We can calculate the img’s largest-possible display width by taking the figure’s max-width, subtracting its padding, and converting ems to pixels:
100% <img> width
x ( 33em <figure> max-width
- 2em <figure> padding )
x 1.25em <body> font-size
x 16px default font-size
= 620pxOr, we can cheat by making the window really big and peeking at the dev tools:
(I prefer the second method.)
Either way we arrive at a maximum, full-quilt img display width of 620px. We’ll render our source images at twice that to accommodate 2x screens: 1,240 pixels wide.
But what to do about our detail images? They expand to fill the whole viewport, whose size has no fixed upper limit. So let’s pick something big-ish with a standard-y feel to it and render them at oh, say, up to 1,920 pixels wide.
When we render our images at those sizes our status-quo page weighs in at a hefty 3.5MB. All but 5.7kB of that is images. We can intuit that many of those image bytes constitute invisible overhead when delivered to small, low-resolution screens—but how many? Let’s get to work.
First pass: scaling with scrset and sizes#section3
Teatherball with a tennis ball for his shoelaces
Naturally adapt to have more than two faces
The first problem we’ll tackle: getting our images to scale efficiently across varying viewport widths and screen resolutions. We’ll offer up multiple resolutions of our image, so that we can selectively send giant sources to giant and/or high-resolution screens and smaller versions to everyone else. How? With srcset.
Here’s one of our full-viewport-width detail images:
<img
src="quilt_2-detail.jpg"
alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork." />quilt_2-detail.jpg measures 1,920 pixels wide. Let’s render two smaller versions to go along with it and mark them up like so:
<img
srcset="quilt_2/detail/large.jpg 1920w,
quilt_2/detail/medium.jpg 960w,
quilt_2/detail/small.jpg 480w"
src="quilt_2/detail/medium.jpg"
alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork.">The first thing to note about this img is that it still has a src, which will load in browsers that don’t support the new syntax.
For more capable clients, we’ve added something new: a srcset attribute, which contains a comma-separated list of resource URLs. After each URL we include a “width descriptor,” which specifies each image’s pixel width. Is your image 1024 x 768? Stick a 1024w after its URL in srcset. srcset-aware browsers use these pixel widths and everything else that they know about the current browsing environment to pick a source to load out of the set.
How do they choose? Here’s my favorite thing about srcset: we don’t know! We can’t know. The picking logic has been left intentionally unspecified.
The first proposed solutions to the responsive image problem attempted to give authors more control. We would be in charge, constructing exhaustive sets of media queries—contingency plans listing every combination of screen size and resolution, with a source custom-tailored for each.
srcset saves us from ourselves. Fine-grained control is still available when we need it (more on that later), but most of the time we’re better off handing over the keys and letting the browser decide. Browsers have a wealth of knowledge about a person’s screen, viewport, connection, and preferences. By ceding control—by describing our images rather than prescribing specific sources for myriad destinations—we allow the browser to bring that knowledge to bear. We get better (future-friendly!) functionality from far less code.
There is, however, a catch: picking a sensible source requires knowing the image’s layout size. But we can’t ask browsers to delay choosing until the page’s HTML, CSS, and JavaScript have all been loaded and parsed. So we need to give browsers an estimate of the image’s display width using another new attribute: sizes.
How have I managed to hide this inconvenient truth from you until now? The detail images on our example page are a special case. They occupy the full width of the viewport—100vw—which just so happens to be the default sizes value. Our full-quilt images, however, are fit to the paragraph width and often occupy significantly less real estate. It behooves us to tell the browser exactly how wide they’ll be with sizes.
sizes takes CSS lengths. So:
sizes="100px"…says to the browser: this image will display at a fixed width of 100px. Easy!
Our example is more complex. While the quilt imgs are styled with a simple width: 100% rule, the figures that house them have a max-width of 33em.
Luckily, sizes lets us do two things:
- It lets us supply multiple lengths in a comma-separated list.
- It lets us attach media conditions to lengths.
Like this:
sizes="(min-width: 33em) 33em, 100vw"That says: is the viewport wider than 33em? This image will be 33em wide. Otherwise, it’ll be 100vw.
That’s close to what we need, but won’t quite cut it. The relative nature of ems makes our example tricky. Our page’s body has a font-size of 1.25em, so “1em” in the context of our figure’s CSS will be 1.25 x the browser’s default font size. But within media conditions (and therefore, within sizes), an em is always equal to the default font size. Some multiplication by 1.25 is in order: 1.25 x 33 = 41.25.
sizes="(min-width: 41.25em) 41.25em,
100vw"That captures the width of our quilts pretty well, and frankly, it’s probably good enough. It’s 100 percent acceptable for sizes to provide the browser with a rough estimate of the img’s layout width; often, trading a tiny amount of precision for big gains in readability and maintainability is the right choice. That said, let’s go ahead and make our example exact by factoring in the em of padding on either side of the figure: 2 sides x 1.25 media-condition-ems each = 2.5ems of padding to account for.
<img
srcset="quilt_3/large.jpg 1240w,
quilt_3/medium.jpg 620w,
quilt_3/small.jpg 310w"
sizes="(min-width: 41.25em) 38.75em,
calc(100vw - 2.5em)"
src="quilt_3/medium.jpg"
alt="A crazy quilt whose irregular fabric scraps are fit into a lattice of diamonds." />Let’s review what we’ve done here. We’ve supplied the browser with large, medium, and small versions of our image using srcset and given their pixel widths using w descriptors. And we’ve told the browser how much layout real estate the images will occupy via sizes.
If this were a simple example, we could have given the browser a single CSS length like sizes="100px" or sizes="50vw". But we haven’t been so lucky. We had to give the browser two CSS lengths and state that the first length only applies when a certain media condition is true.
Thankfully, all of that work wasn’t in vain. Using srcset and sizes, we’ve given the browser everything that it needs to pick a source. Once it knows the pixel widths of the sources and the layout width of the img, the browser calculates the ratio of source-to-layout width for each source. So, say sizes returns 620px. A 620w source would have 1x the img’s px. A 1240w source would have 2x. 310w? 0.5x. The browser figures out those ratios and then picks whichever source it pleases.
It’s worth noting that the spec allows you to supply ratios directly and that sources without a descriptor get assigned a default ratio of 1x, allowing you to write markup like this:
<img src="standard.jpg" srcset="retina.jpg 2x, super-retina.jpg 3x" />That’s a nice, compact way to supply hi-DPI imagery. But! It only works for fixed-width images. All of the images on our crazy-quilts page are fluid, so this is the last we’ll hear about x descriptors.
Measuring up#section4
Now that we’ve rewritten our crazy-quilts page using srcset and sizes, what have we gained, in terms of performance?
Our page’s weight is now (gloriously!) responsive to browsing conditions. It varies, so we can’t represent it with a single number. I reloaded the page a bunch in Chrome and charted its weight across a range of viewport widths:
The flat, gray line up top represents the status-quo weight of 3.5MB. The thick (1x screen) and thin (2x) green lines represent the weight of our upgraded srcset’d and size’d page at every viewport width between 320px and 1280px.
On 2x, 320px-wide screens, we’ve cut our page’s weight by two-thirds—before, the page totaled 3.5MB; now we’re only sending 1.1MB over the wire. On 320px, 1x screens, our page is less than a tenth the weight it once was: 306kB.
From there, the byte sizes stair-step their way up as we load larger sources to fill larger viewports. On 2x devices we take a significant jump at viewport widths of ~350px and are back to the status-quo weight after 480px. On 1x screens, the savings are dramatic; we’re saving 70 to 80 percent of the original page’s weight until we pass 960px. There, we top out with a page that’s still ~40 percent smaller than what we started with.
These sorts of reductions—40 percent, 70 percent, 90 percent—should stop you in your tracks. We’re trimming nearly two and a half megabytes off of every Retina iPhone load. Measure that in milliseconds or multiply it by thousands of pageviews, and you’ll see what all of the fuss is about.
Second pass: picture and art direction#section5
srcsetif you’re lazy,pictureif you’re crazy™
So, for images that simply need to scale, we list our sources and their pixel widths in srcset, let the browser know how wide the img will display with sizes, and let go of our foolish desire for control. But! There will be times when we want to adapt our images in ways that go beyond scaling. When we do, we need to snatch some of that source-picking control right back. Enter picture.
Our detail images have a wide aspect ratio: 16:9. On large screens they look great, but on a phone they’re tiny. The stitching and embroidery that the details should show off are too small to make out.
It would be nice if we could “zoom in” on small screens, presenting a tighter, taller crop.
This kind of thing—tailoring image content to fit specific environments—is called “art direction.” Any time we crop or otherwise alter an image to fit a breakpoint (rather than simply resizing the whole thing), we’re art directing.
If we included zoomed-in crops in a srcset, there’s no telling when they’d get picked and when they wouldn’t. Using picture and source media, we can make our wishes explicit: only load the wide, rectangular crops when the viewport is wider than 36em. On smaller viewports, always load the squares.
<picture>
<!-- 16:9 crop -->
<source
media="(min-width: 36em)"
srcset="quilt_2/detail/large.jpg 1920w,
quilt_2/detail/medium.jpg 960w,
quilt_2/detail/small.jpg 480w" />
<!-- square crop -->
<source
srcset="quilt_2/square/large.jpg 822w,
quilt_2/square/medium.jpg 640w,
quilt_2/square/small.jpg 320w" />
<img
src="quilt_2/detail/medium.jpg"
alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork." />
</picture>A picture element contains any number of source elements and one img. The browser goes over the picture’s sources until it finds one whose media attribute matches the current environment. It sends that matching source’s srcset to the img, which is still the element that we “see” on the page.
Here’s a simpler case:
<picture>
<source media="(orientation: landscape)" srcset="landscape.jpg" />
<img src="portrait.jpg" alt="A rad wolf." />
</picture>On landscape-oriented viewports, landscape.jpg is fed to the img. When we’re in portrait (or if the browser doesn’t support picture) the img is left untouched, and portrait.jpg loads.
This behavior can be a little surprising if you’re used to audio and video. Unlike those elements, picture is an invisible wrapper: a magical span that’s simply feeding its img a srcset.
Another way to frame it: the img isn’t a fallback. We’re progressively enhancing the img by wrapping it in a picture.
In practice, this means that any styles that we want to apply to our rendered image need to be set on the img, not on the picture. picture { width: 100% } does nothing. picture > img { width: 100% } does what you want.
Here’s our crazy-quilts page with that pattern applied throughout. Keeping in mind that our aim in employing picture was to supply small-screened users with more (and more useful) pixels, let’s see how the performance stacks up:
Not bad! We’re sending a few more bytes to small 1x screens. But for somewhat complicated reasons having to do with the sizes of our source images, we’ve actually extended the range of screen sizes that see savings at 2x. The savings on our first-pass page stopped at 480px on 2x screens, but after our second pass, they continue until we hit 700px.
Our page now loads faster and looks better on smaller devices. And we’re not done with it yet.
Third pass: multiple formats with source type#section6
The 25-year history of the web has been dominated by two bitmap formats: JPEG and GIF. It took PNGs a painful decade to join that exclusive club. New formats like WebP and JPEG XR are knocking at the door, promising developers superior compression and offering useful features like alpha channels and lossless modes. But due to img’s sadly single src, adoption has been slow—developers need near-universal support for a format before they can deploy it. No longer. picture makes offering multiple formats easy by following the same source type pattern established by audio and video:
<picture>
<source type="image/svg+xml" srcset="logo.svg" />
<img src="logo.png" alt="RadWolf, Inc." />
</picture>If the browser supports a source’s type, it will send that source’s srcset to the img.
That’s a straightforward example, but when we layer source type-switching on top of our existing crazy-quilts page, say, to add WebP support, things get hairy (and repetitive):
<picture>
<!-- 16:9 crop -->
<source
type="image/webp"
media="(min-width: 36em)"
srcset="quilt_2/detail/large.webp 1920w,
quilt_2/detail/medium.webp 960w,
quilt_2/detail/small.webp 480w" />
<source
media="(min-width: 36em)"
srcset="quilt_2/detail/large.jpg 1920w,
quilt_2/detail/medium.jpg 960w,
quilt_2/detail/small.jpg 480w" />
<!-- square crop -->
<source
type="image/webp"
srcset="quilt_2/square/large.webp 822w,
quilt_2/square/medium.webp 640w,
quilt_2/square/small.webp 320w" />
<source
srcset="quilt_2/square/large.jpg 822w,
quilt_2/square/medium.jpg 640w,
quilt_2/square/small.jpg 320w" />
<img
src="quilt_2/detail/medium.jpg"
alt="Detail of the above quilt, highlighting the embroidery and exotic stitchwork." />
</picture>That’s a lot of code for one image. And we’re dealing with a large number of files now too: 12! Three resolutions, two formats, and two crops per image really add up. Everything we’ve gained in performance and functionality has come at a price paid in complexity upfront and maintainability down the road.
Automation is your friend; if your page is going to include massive code blocks referencing numerous alternate versions of an image, you’d do well to avoid authoring everything by hand.
So is knowing when enough is enough. I’ve thrown every tool in the spec at our example. That will almost never be prudent. Huge gains can be had by employing any one of the new features in isolation, and you should take a long, hard look the complexities of layering them before whipping out your claw and committing to the kitchen sink.
That said, let’s take a look at what WebP can do for our quilts.
An additional 25 to 30 percent savings on top of everything we’ve already achieved—not just at the low end, but across the board—certainly isn’t anything to sneeze at! My methodology here is in no way rigorous; your WebP performance may vary. The point is: new formats that provide significant benefits versus the JPEG/GIF/PNG status quo are already here, and will continue to arrive. picture and source type lower the barrier to entry, paving the way for image-format innovation forevermore.
size the day#section7
This is the secret of perfection:
When raw wood is carved, it becomes a tool;
[…]
The perfect carpenter leaves no wood to be carved.
For years, we’ve known what’s been weighing down our responsive pages: images. Huge ones, specially catered to huge screens, which we’ve been sending to everyone. We’ve known how to fix this problem for a while too: let us send different sources to different clients. New markup allows us to do exactly that. srcset lets us offer multiple versions of an image to browsers, which, with a little help from sizes, pick the most appropriate source to load out of the bunch. picture and source let us step in and exert a bit more control, ensuring that certain sources will be picked based on either media queries or file type support.
Together, these features let us mark up adaptable, flexible, responsive images. They let us send each of our users a source tailored to his or her device, enabling huge performance gains. Armed with a superb polyfill and an eye toward the future, developers should start using this markup now!
superb article, makes it really clear how to do all this stuff. thanks Eric!
I’ll probably start using this on my own site and for parts of client sites, but I’m wondering how to allow clients/users to upload their own images and still take advantage of this functionality.
Are there any CMSs that support responsive images, even minimally?
Re: 29th Floor —
For code-ier CMSes like Perch, integration is fairly simple.
And Drupal is hashing out a CMS UI for responsive images (which will hopefully land in Drupal 8) right now.
Some of the mockups in that thread may be instructive. But a good, universal CMS UI for this stuff is still a new/hard/interesting/open problem!
I’m still trying to get my head around responsive and you’re talking above my head for most of it. From what I understood, could this code be integrated into wordpress, where the thumb, medium and large media duplication that wordpress does can be integrated. Do you think there will be a plugin made for responsive images for wordpress until they add responsive media handling into the wordpress core?
Thanks, I’m going to re-read this a bit later when I’ve got some more practice under my belt!
Re: Cathie Heart —
Thanks for soldering through! There’s a lot of new stuff here to digest.
Tracy Rotton wrote a great article about integrating the new markup into WordPress themes, and I know of at least one plugin that’ll do it for you, but I’ll confess I haven’t tried it myself.
I’ll say too that the RICG is hoping to get responsive images into the WordPress core sooner, rather than later!
Thanks for a great article!
The only thing I’d add is that plugins or filters such as mod_pagespeed on the web server can take over some of the heavy-lifting regarding resizing or transcoding images. Ie. you always develop with webp images but the server will only serve webp to browsers than can digest it, it serves JPEG or PNG to the others. It can do more depending on what the browser tells it. This can vastly simplify workflow and markup.
Very good article. That said, I have one recommendation not covered in the article that I discovered in my testing: versions of Chromium (which Chrome and Opera, and many third-party mobile browsers like Puffin, Amazon Silk, Samsung/HTC/Cyanogenmod’s default browser are a part of) that support srcset’s with the “X” suffix but before it supported the “w” (so versions 35-37) will always load the very first image defined if it does not understand the “w” and no “x” match. This can cause these browsers to load the wrong image. To avoid issues with these browsers I would recommend you either always include the same image as the src with it’s width in the “w” operator, or always include a “1x” version. This will avoid that bug. This might be rare for your users, but it’s relatively simple to structure your output that way to avoid that bug (which at the very least will affect Cyanogenmod users).
Great article. Thanks for contributing!
Should we be concerned about the debate between srcN, srcset and picture?
Thank you so much Eric for summing things up in a clear article. I have to admit that it took me a little while to get the new srcset + size syntax since it changed a little bit over time.
Like 29th Floor, I can’t help to wonder how our CMSs will support this, and to go one step further, how we will be able to explain this to clients who tend to simply throw a 3000px in the WordPress drag and drop upload field and voilà. I bet we’re heading towards lot of server side development and client education 🙂
Really nice article , regarding wordpress there are some plugins that move the above said way , though not perfect. Thank you Erick for such a great article
Great article.
You might want to check the first CSS snippet for box-size. It should be box-sizing.
An informative article… yes. But how large a step backwards are we taking to take a different one forwards?
Backwards? Yes. For many years, we have been taking gradual steps to separate our content from its presentation. We decry table-based layout (as we should). We embrace CSS over in-HTML formatting. Of course, all the hacks that come along work against this principle; styles are applied to code instead of classes, etc.
And now this!
The concept of the sizes attribute – that how wide it will render must be embedded directly in the HTML, thereby brutally coupling the content to its presentation – is a step backwards. It is equivalent to a solution that relies on table-based layouts.
The best article I’ve read about responsive images. Very useful, thanks!
The problem I see is very limited support at this point. Chrome supports the suggestions fully, Safari is only supporting srcset with 1x and no one else is listed as supporting any of it. That is a lot of work for little support.
That said, about 50% of my traffic would benefit from srcset, so I may work on implementing it on areas I can.
One solution for a CMS is to use a server side resizing script. At least in images that you are writing out the img tag yourself and can append the URL string of the different sizes. This will automate the needed resources and help prevent your users from making stupid mistakes.
@Rick,
That is actually a very good point. It hadn’t occurred to me during all of this. While srcset is fine to me as that is content, sizes really does feel like it’s too presentational to be appropriate.
Truthfully, I feel that we are in an era where too many people are rushing to get things to run better on mobile that we are throwing away years of best practice and practicality to try and get things running well there. and not thinking thing through enough. This is ESPECIALLY true recent changes/recommendations from Google.
@Zach,
Safari will support the full range in an upcoming version, and Firefox support is coming. You can turn it on with a flag in about:config, it just hasn’t shipped for some reason. It’s only IE where things are totally left in the dark.
Our CMS has gone with the server side resizing script option. We probably going overboard with how many versions we create (320, 360, 414, 480, 600, 640, 768, 1024, and [orig_width – 100*n] > 320), and author’s original desired size * 1.5x, 2x, and 3x as long as the those values are < the original file size. The issue with all of this is that it's a lot of load on the server. Our images our generated upon request and we cache the resize so it's only done once, but that is slow for a lot of users who may not see it so we load 10 of those versions that have not yet been cached in the background afterwords to improve load time for the next visitor. It was either that or make things slow inside the CMS itself, which we'd rather not do.
Another brilliant article Eric — you have a great ability to make this stuff simple to understand.
The greatest part about all of this is it’s a no brainer to implement it today. If the browser doesn’t offer support, there’s the SRC, if it does then hoorah!
I am really keen to see how CMS are going to approach the implementation. I wasn’t overly happy with Drupals approach however I understand that the decision was made a little while ago and at some point you need to focus on a deliverable and build something.
There are some plugins available for WordPress and https://github.com/kylereicks/picturefill.js.wp is my favourite at the moment. It allows the content editor to add in the standard![]()
markup that provides backwards compatibility however when the page is generated for the front end it pulls the sizes and srcset attributes from a central location.
Any CMS that provides a template capability will be safe for images that form part of the template, because essentially that’s a rule you set for the design and it resides in a single location (the template).
My concern is the inline images that are associated with content and having a CMS add the current design ‘sizes’ that may change as part of the next redesign. It’s (almost) as bad as having inline styles to style headings.
I’m excited to see how each CMS tackles the issue, and hope they all head to the community (read RICG) for direction on best practices.
First, thanks to Eric for a well written, thoroughly researched article. Nicely done!
However… It seems like every time there is an article on how to implement responsive images “in practice”, the solution is tied to additional resources and requires verbose markup with a perplexing syntax. Look at that markup on the last example. Including a single image takes 27 lines of code and 12 different versions of the image. Is this something that any of you would really implement “in practice” on your production sites today?
More so than the markup, the creation of different image sizes requires the use of something like Sencha Src. Or you’re stuck rolling your own EC2 instance for this purpose. What if the client doesn’t want to pay for Sencha.io or AWS, then what?
While this article was very informative, I still didn’t see anything that can be used on any given project, any time. Not the fault of the author, just the reality of the situation right now.
I think the cms world needs to adapt to this with some decent plugins with an easy gui (especialy for art directed responsive images).
Otherwise this won’t spread the web because responsive images are a content editors nightmare (The very cool craftCMS has already a image transformation script in the core but it would need a step forward).
And besides: Writing sizes in html is just gross.
Re: Charlie Clark —
Automating as much of this stuff as possible on the server is a huge win. You should take a look at the (sadly maybe languishing?) Client Hints proposal, which integrates with (and simplifies the use of) the new markup via content negotiation.
Re: powrsurg #7—
The spec was recently changed, so that candidates whose descriptor isn’t understood are dropped. But you’re totally right that Safari 7 & iOS8 will load the first w-descriptor-resource that they see. The workaround that you suggest is relatively painless and effective… and will hopefully become an obsolete concern after Safari updates it’s implementation to match the spec.
Re: Mike Garrett #8 —
Nope! Src-N is dead (or rather, it was a stepping stone to the srcset spec that was finally settled on), and picture and srcset integrate in the ways that the article describes. They’re different tools for different jobs, which will happily coexist forevermore.
Re: Stéphanie Walter #9, anoopd #10 and Christophe Bram #13 —
Thanks for reading and I’m so very glad to hear that you found this helpful!
Re: Ronny Karam #11
Oooooooops! You are of course, correct. Luckily I didn’t make the same error in the actual demo code! I’ve got a note in, requesting the change. Thanks!
Re: Rick Yagodich 1 #12 —
Baking layout info into markup should give all of us pause. I wrote some (loose, brainstormy, not-very-organized) thoughts on markup, layout, sizes, and the future here.
Since I wrote that, a very exciting bit o’ javascript has been released, which injects sizes attributes on the fly while also lazyloading images. That’s one way around the problem! I’m hoping that the future brings others.
In the meantime, if this really gets under your skin (or is untenable for more practical reasons — say, if your markup is needs to be viewed in different layout contexts) the easiest solution is just to leave sizes off entirely. In many contexts, the default 100vw value isn’t a bad guess and will still provide real and tangible benefits to users vs the status quo.
Re: Zach Ritter #14 —
What powrsurg #15 said (: This stuff is being actively implemented in Safari and Firefox. I’ll add that while IE, officially, only lists the features as “under consideration,” there have been a few positive signs that this stuff will land in IE sooner, rather than later.
Re: justinavery #16 —
An emphatic ‘yes!’ to all of that. I’m excited to see how different CMSes tackle this issue too… and the picturefill.js.wp plugin has all of the advantages and disadvantages which you describe. Thanks for the kind words!
Re: Jonathan Melville #17 —
The last example is a worst-case scenario, as far as complexity goes, and was labeled as such. That kind of flexibility is there if you really, really need it; most of the time you won’t and can keep things much, much simpler.
I’m still reading, but “Or, we can cheat by making the window really big and peeking at the dev tools:” had me laughing out loud. Love it!
A great, clear and simple article to distinct all those parameters. Thanks so much Eric!
I have been using a JavaScript approach. Curious what your thoughts are on this:
– When uploading images, my CMS is built to create several (about a half dozen) versions of the same image: One very small (1px by 1px) and others for common viewport sizes in something like /samplePage/img/1024/
–JavaScript checks the size of the window, and changes the image path to replace the 1px place-fillers with the appropriate size for each respective class.
Very nice and complete article.
I’m still testing pictureFill and picturePolyfill with old browsers (IE7/8) and I can’t find a solution that work everywhere
Another article here about IMG src and PICTURE: http://ericportis.com/posts/2014/srcset-sizes/
Unfortunately you missed to explain what
vwactually is (viewport width, I guess?) when bringing it up.And, well, unfortunately for all of us,
sizesturned out to be the most complicated attribute in the history of html. I mean, this:sizes="(min-width: 41.25em) 38.75em, calc(100vw - 2.5em)"Really? There was no easy way to do this? No way without complicated maths?Not trying to come across as a doom sayer, but I have long been predicting this kind of confusion, and built a nuclear bunker cause of it. LOL. With that said, a fantastic article. And I love how you worked in the 3rd pass which I think is most important: the idea that you need to create a best #webperf scenario and/or conditions at all cost by using a mix of formats. I recall Chris Coyier saying that he was annoyed with all of this, and was saving files out imgs at 150dpi – just using them for 1x and 2x. That’s likely why he’s such a fan of SVGs.
Responsive design has been taking a beating, and unjustly so, for their page weight. But the actual challenge has been getting devs to write 20 lines of code instead of one to serve *a* correct img. Add to that you have to create the formats, adding to the work flow – and the laziness fall back of .jpg takes over. That to me is the single biggest hurdle. But do hope that articles like this one will drill home the idea that this is the new reality.
re: #30 Michael Femia –
Ilya Grigorik also likes the idea of automation, and has talked about it – since some of the bigger CDNs are employ it as well, but as someone added, I would love to see the img before uploading live – just in case. So, although I have yet to use or needed to use a CDN or another other back end solution for img optim, I almost rather have a droplet of a desktop script to be able to make some tweaks of my own.
Henri, I use Imagick (PHP Library) for compression and multiple sizing of images on upload. On the JavaScript side of things, there’s just a set of very simple switch statements that choose what size images to download: i.e. what size .imageClass should be downloaded when the window is ____ pixels?
For me, this works fine, and it’s pretty intuitive, at least for me. Just curious whether there are pitfalls to my method. (I’m not running a global commerce site or something, so I don’t care about people who have disabled JavaScript)
A great and comprehensive article on responsive images but what about webperf (spriting, lazy loading) and loading time depending on speed connection. We can’t decide to load an image only with screen size and DPI. On my 4G smartphone 640px width I have more speed than on my 1920px desktop screen at home with DSL.
nice and interesting article
Excellent article regarding using srcset and sizes but I still have concerns which I haven’t seen addressed anywhere,
In the first example where art direction isn’t a concern we see that on small width retina devices (which would be the majority of the mobile traffic to our sites these days) you they make a sizeable saving reducing the page total to about 1.1MB.
However, a simple change in device orientation will result in them hitting the larger ‘breakpoint’ that uses the next set of images resulting in little to no savings at all.
Or am I missing something here.
@Brian Hughes – One thing to ask is, how many users change their orientation while reading on a regular basis? Most people I watch use a tablet or phone stick to one orientation for the majority of what they are doing.
re: #31 stefan cova
Try respimage, it supports IE8+ out of the box and adds support to IE6+ using a plugin. Other than picturePolyfill it is a true polyfill, similiar to picturefill. (I.e: resimage is a bugfixed picturefill with a lot of improvements.)
re: #32 @Bärli Legal
This was done for performance reasons. If the browser has to wait for the stylesheet to be loaded and parsed to simply automatically calculate the “size” of the image, responsive images wouldn’t work with the preload parser.
Additionally even if the browser would wait, the browser can’t calculate the size of hidden (display none) elements.
Luckily, as soon as you use lazy loading you can calculate it with javascript.
re: David 2 #36
Spriting is a technique for background images. picture and srcset are for content images.
For lazyloading you can use lazyizes
I have the exact same question as David 2. My phone has a significantly faster connection than my desktop with its large monitor. My phone could handle 3.5 MB with ease, unlike my desktop. However, the solution described in this article seems to assume that larger screen size = larger bandwidth. Why is bandwidth checking not built in to the picture element?
re: Brian Hughes #38
While I’m also concerned about retina quality and increasing image size due to responsive image usage. Your usecase shouldn’t be a big concern though.
Despite the fact, that most users won’t change orientation. This is something the browser can optimize for. An example: I have created a polyfill for responsive images with a smart selection algorithm.
And there are three interesting parts here: The smart selection works basically as follows:
1. If you have a 2 dpr device and there are two image candidates one with 1.9x and another with 2.8x, the 1.9x will be chosen as “good enough”.
2. Additionally there is also another part in the selection algorithm (lazy change on resize): if the image already has a viewable source and the browser is resized and therefore the 1.9x becomes 1.6x and the 2.8x becomes 2.5x normally the selection would choose the 2.6x image, but because there is already a fully loaded image the selection becomes more lazier by adding the currently shown image virtual “advantage” pixels.
3. In case the browser is loaded in portrait mode the 1. algorithm is run less aggressive.
As you see the browser can optimize for this. As soon as the standard is much more in use, a lot data can be analyzed and browser vendors can improve their selection routines on the typical use cases the collected data.
my personal concerns about the retina problem
Letting the browser make the decision, which candidate to load is really great, but for making good decisions the browser needs enough crucial/relevant informations. And while the browser might have enough information about the image size, the device and the user’s preferences, he has not enough information about the image itself.
If you compare same images with 1x and there 2x counter parts, you will see, that there are big differences between different images. Most images simply do not gain much quality after a certain density (1.5), while others still on higher density do gain more perceived quality. Treating those big differences the same can’t be good. It would be simply nice to tell the browser wether a certain image has characteristics that it needs to be loaded full retina to have a good quality or the image has characteristics that it doesn’t gain much quality with higher densities.
re: jallred
I think you mean, “Why is bandwidth checking not built in to the srcset attribute?”
Because picture is all about art direction.
To answer your question: The solution does not assume smaller screensize = lower bandwidth.
The solution is simple: For less pixels on the screen (screen size * devicePixelRatio) you need a smaller image to satisfy the possible quality on the device.
And there is nothing in the spec saying, that lowbandwidth or GPU performance or what ever aren’t not part of the responsive solution.
Quite the contrary the responsive image spec explicitly names bandwidth to be takken into account when choosing the right image candidate.
The current implementations doesn’t do this, because even for a browser this information isn’t so easy to collect.
Re: Catherine Azzarello #28, Markus Seyfferth #29, Henri Helvetica #33, and Bee Infotech #37 —
Thanks!
Re: #30 + #35 Michaael Femia —
I love the automated-resizing-by-the-CMS part of your solution, but the reliance on Javascript to see anything except for a 1px by 1px placeholder, I don’t. Use a bigger fallback!
Before this new markup was A Thing, I used a solution on my own site that was similar, but my fallback images were the bare minimum I felt legible (96 x 96px), and I had text links to all of the larger versions visible in case JS was disabled or broken. Which, even for non-“global-commerce-sites” happens more than you’d think.
I’m in the process of switching every site that I maintain over to the new markup and would encourage you to experiment with it, too. If browser support is a concern, use PictureFill! But at the very least, don’t put 1px by 1px images in your markup.
Re: #32 Bärli Legal —
vws are indeed, newish, and confusing if you’ve never encountered them before. I went back and forth on whether to devote a couple sentences to explaining them, but decided that they were outside the scope of the article, and hoped that anyone that was confused by them would look ’em up. They’re great!As for
sizes, yeah, it can get gnarly. But it can be left, simple, too. As I stated in the article, trading a tiny amount of sizes accuracy for a lot of readability is often a much smarter choice.Re: #36 David 2 and #43 jallred —
That’s the dream – that bandwidth (and/or data-plan) considerations will get worked into browsers’ srcset picking logic, too. That’s a hard problem, and expect there to be user preferences about this sort of thing (“prefer low-res images”) before anything super-smart and automatic. But this is what everyone wants and what browsers are working towards.
Re: #38 Brian Hughes —
Changes in viewport size can trigger requests for new resources, and if your primary goal is to limit the total amount transferred, and if users are changing orientations a *lot* for whatever reason on your site, that’s something that you’d be wise to consider.
But, what Zach #39 said — if orientation changes aren’t the majority case, sending bigger resources up front just in case an orientation change happens will be wasteful for most of your users.
Re: afarkas —
Thanks a million for jumping in and answering a bunch of these!
Great article! Really made me understand the tags once for alle (I think…)- Did some test drives and tried to add some very simple explanations as well.
I’ve been playing with various responsive image methodologies on my personal site.
I have ended up with a workflow that handles my simple needs nicely. It is based on a “watched” local folder. I drop my full-size images into that folder, then a small PHP script produces various image size versions for me and generates a HTML snippet of the relevant <img> source which is then piped to my system clipboard for pasting directly into my CMS.
Then I am using the Picturefill polyfill on my website to select the appropriate image from the srcset. This workflow works well enough for me.
Great article, i wonder if responsive images will become unnecessary in the near future because of higher resolution screens on mobile (that match desktop screens) and faster and faster internet speeds…Also, If you use the ExpressionEngine CMS, the Channel Images plugin would allow you to upload images and auto-generate any size image you need automatically. It’s super easy to setup and works great.
Very nice article, i was consider about Responsive images because about 60% of mobile devices web traffic is generated by images (sic!) – on most websites images aren’t responsive.
It took me some time to find just the right solution for RWI and finally I had found Bildero.
Bildero is very powerfull image server and one of its features are responsive images. Just by attaching simple javascript on your websites you are able to server responsive images to your visitors.
How it works?
This simply JS is checking for screen resolution of your visitor and then it perfectly fit images to the div’s. It’s really easy in implementation and images are processed on the fly so you need only one source image on the Bildero server.
Great article. However I don’t like at all about this solution.
1 – this is way too complex and heavy markup language. Can you imagine yourselves doing that in 300 images in a web site? This will be a nightmare to manage.
2 – It goes against the separation of content and visual markup. It is a mess.
I see it as an important step to solve the responsive images problem but I think we can do much better than that and I believe that the path is automation. Something that should be explored at browser, server side or even a new image format.
Kaspar Allenbach 11:35 am on November 05, 2014 say:
I’ll probably start using this on my own site and for parts of client sites, but I’m wondering how to allow clients/users to upload their own images and still take advantage of this functionality. Are there any CMSs that support responsive images, even minimally?
—-
Adaptive display of photos and pictures. Bbcode tag photo
This gave me the idea of a cropping method based on a descendant list of important zones (maybe not new)
There are so many things wrong with these new responsive image systems.
Picture is what scares me the most. This notion of art directed images is bad news, even the example here is highlighting that. If I, as a content creator want you to see an image of let’s say this tapestry and it is a wide thing – that’s what I want you to see – not a square of it just because you have a smaller viewing screen and that is exactly what is going to happen. People everywhere serving up completely different images to what was intended and that is saying whatever the intended image was is not important and if that’s true, why did you put it on the page in the first place?
I spoke at UXCambridge about this last year and how selective cropping in the media has resulted in some pretty spectacular and sensationalised misrepresentations of events, this is allowing people to do that with anything and it is going to end horribly. I would rather have a big image that I can ‘pinch zoom’, because my device has been designed to enable that as a result of its small view window, than wanting to, for example, look at the new Kawasaki H2R only you decided to show me only the left hand indicator light because my device is small. This is just so, so bad for imagery and in particular photography on the web.
As so many have noted including @powrsurg I agree that this is not going to be thought through enough because someone somewhere needs to factor this into a system designed for people who actually produce and publish content and they do not have a clue what any of this means, they just want to make an image and add it to a page. Like with your CMS, most have image sizing options and even WordPress has had this for yonks, but again, this only solves one problem which is that of I have a file I have been given to use and it is 6MB and if I was to print it 1:1 it would be the size of a skyscraper billboard.
I’ve been trying to write something about my concerns with Picture in particular for a while but have found it hard to structure the argument. In producing these examples here it has helped me be able to see written down what I’ve been trying to say.
Great summary and I can see how from a perspective of progress to our authoring language this is good in some ways but isn’t picture just Object with a different name? Why have we not extended the existing img tag to allow for better width and height controls?
There’s a long long discussion here and I am sure it will be rolling on more now we have some browser support to experiment with. This can’t be the final solution though.
How about a little help from our friend the all mighty coders developing web servers so on the fly lossy scaling and compression based on the style sheet parameters defined by the Web Designer could be an standard extension.
Wouldn’t it would be a more elegant solution to summit a HQ master an modern format like JPEG XR and then have the server scale and compress it on the fly for maximum for the desired quality representations across any screen size and devices.
It’s a similar concept of what we already do with color profiles for each printer, screen and scanner model. A “simple” system, yet more complex that what has been requested from the Web Server, which enables the designers to abstract themselves from hardware (ceteris paribus) and enables them to accurately render and proof what would be the final output when it get backs from the printing press.
For me that’s where responsive design shoud go.
Please, don’t tell me that the servers will overload because they’ll not, as long as, they’re coded right. The problem is “lazy coding” and not a lack of resources (vast amounts of resources tend to derive in “Lazy Coding” and then “vast amounts” stop to be so vast and become not enough).
“Optimize, when you finish optimizing you code the optimize it a little bit more; ’cause it shall always be room for further optimization.”
“Less is more” by Ludwig Mies van der Rohe
Re: #47 Fredrik Jenson —
Thanks! Your tests are great!
Re: #48 Jonathan Hollin —
Sweet setup! Managing/marking up all of those versions gets tedious quick and all automation is good automation. I’ve got something sort of similar set up on my personal site, except it’s Jekyll and ImageMagick doing all of the dirty work at build time. Hopefully I can follow your lead and publish my workflow to GitHub sooner rather than later?
Re: Mike Lohrman #49 —
I’m sadly unfamiliar with ExpressionEngine, but that sounds like it does exactly what’s needed. As to the “do we need this?” question — you’d be surprised how slow most of the world’s internet connections are, have been, and probably will continue to be: http://responsivedesign.rferl.org/content/empathy-in-connection-speeds/25368750.html
Re: #50 Szymon Szybryt —
Totally automated, 3rd party server-side solutions like that can be great, but make sure that you’re not totally dependent on Javascript to show the user any image at all. Content images should be in markup, and not injected later via JS.
Re: #51 Mark De Souza Costa —
1) Hence all of the focus on automation of markup/image version generation down here in the comments. It is a lot to manage, even if you only have two or three separate sources per image. This is the cost of adaptability, at the moment.
2) I share your concerns. But this is the best that we can do at the moment, given the problem constraints.
Re: #53 Cahnory —
Woah! Cool!
Re: #54 Andy Parker —
I used to be a stickler about cropping, too. “That’s a presentational concern! The whole image is sacred, crop it with CSS if you must.” A couple of things swayed me to the “cropping is cool” camp. 1) seeing the performance gains of doing the cropping up front / not sending data to users that they’ll never see. 2) This post about adapting album art from vinyl LPs to fit cassettes. Cropping and art direction can be used poorly, but used well, they are an excellent tool to be able to show the user the essential thing that you are trying to show them (no pinch zoom required), no matter what their device. I tried with the quilt example to show this — if what you’re trying to show off are the stitches, unless you crop on small devices, they’re totally invisible. Cropping reveals, by zooming, what would have been lost by shrinking. It shouldn’t be used in every situation, but when it’s useful, it’s potentially very useful.
Re: #55 abetancort —
That’s my dream for authors, too. Stick one, high quality image somewhere, and let automated systems do the rest. I see this new markup as a building block / step towards that dream, and not something that displaces it.
Hi, not sure on the img src tag – shouldnt you use srcset else you will be downloading 2 images before polyfill kicks in?
Thanks for the article Eric, it’s a great help for me as I’m catching up on the changes in front-end development.
I am confused by Snippet 10 http://alistapart.com/article/responsive-images-in-practice#snippet10 however: the first
Alternatively, if that’s not true, when would the square be shown?
Hi Eric, have you inspected Crazy Quilt using Chrome’s Canary browser? I’m using the mobile emulator iPhone 4 view and it breaks for me, it seems to either lock up loading the images or simply ignore the layout entirely.
So what is the bottom line here for a production web application with such sparse support from mainstream browsers? Use media queries and load alternate css files appropriately?
Excellent article. Now to consume every bit of intelligence from it.
You guys should check out what we did for the Get Pre-Approved form at the top of the site that we used gravity forms for. Do a search for VA Loans Finance and IOM Partners of Houston, TX.
Very informative post. But I am not in favor of the solution which you provided for responsive image problem because this is a very complex and difficult to manage.
Please clarify what wood nymphs are so people don’t have their comments automatically deleted for a term they don’t understand.
wow, great article. THANKS for breaking down srcset and picture so clearly!
If you ask me, I think we’re barking up the wrong tree.
It seems that it would make most sense to look at image formats. Consider an interlaced/progressive JPG. If it can progressively load quality, why can’t progressively loading the image size work?
I got a question about sizes=”(min-width: 41.25em) 41.25em, 100vw”.
You say, that in media queries it takes the browser’s default em relative size. So shouldn’t the media query min-width: 41.25em still be 33em?
There are two interesting things I’ve noticed. First, the quote at the top from Einstein: “The devil has put a penalty on all things we enjoy in life.”
I believe it wasn’t the devil who did that. It was the people. They were the ones who made this insanely simple task of displaying an image a huge, complicated issue.
And the other thing I’ve noticed is that after all this great writeup, the article image at the top, is not responsive! Now what are the odds of preaching and practicing something completely different.
Here’s another oddity. People are worried so much about saving 40KB download, but at the same time they don’t have an issue paying $120/month for an unlimited data plan. DUH! If you’re so worried about kilobytes and saving the planet, purchase the cheapest data plan. People are just so out of touch with everything lately.
You saved 40KB of download. Great. At what cost? You had to store 3 times as many images on the server. Pfff.
I’m not saying all this responsive image blah blah is not great and doesn’t make sense. It is great. And it does make sense. Just not common sense.
Eventually people will realize in the (hopefully near) future, that they made everything so insanely complicated that they just need to return to basics and get a newspaper to read. A pencil and paper to draw. And walk over to the neighbor to talk.
We did some cool stuff with Visual Composer in WordPress after we were having hugely annoying issues by trying to use the responsive display using Revolution Slider. We inserted a “row” into the visual editor, set the size of the block to “Fill Width” and set the background image of the container’s width to 1920 so that it filled most people’s browser-width, even if they were larger. Rev Slider kept not ever playing nicely and we kept having to try all these hacks to, in the end, make it unsuccessful and just revert to the way we did it. I don’t want to URL spam but don’t hesitate to ask in case you’d like to see it in action.
Has anyone ever played around with a responsive image service like Respondy or ReSRCit ?
I’m a total newbie here so this article was way over my head for now.
How does all of this relate to frameworks such as Bootstrap? Don’t most frameworks these days already make their content, including images, responsive?
information about css and html code that is very helpful for me who is studying deeper .. keep working , thanks to quality article , if you need information about more try visiting..Jual Mukena Tasik