Browsers at Odds With Web Developers Over ‘Adaptive Images’
The web design community continues to debate the merits and drawbacks of the WHATWG’s proposed adaptive images solution.
As we reported last week, a new
srcset attribute has been added to the
<img> element in the WHATWG’s HTML specification. The new attribute will allow developers to specify different sized images based on the user’s screen size.
The idea is to find a way to serve smaller images to devices that don’t need large images — saving precious bandwidth — while serving high-resolution images to screens that warrant them. And the WHATWG’s
srcset attribute does solve some of the problems surrounding adaptive images, but it’s far from ideal.
Now developer Jason Grigsby argues that not only will the
srcset solution not completely solve the problem, but the goal of adaptive images is fundamentally at odds with how web browsers currently handle images. In other words, there currently is no way to solve the problem.
Adaptive images are at odds with how browsers handle images thanks to what’s known as a “lookahead pre-parser.” Browsers use lookahead pre-parsers to start downloading images as soon as possible (to speed page-load times), which means images are parsed and downloads started before the browser has determined the full page layout.
However, a truly useful adaptive image solution needs the browser to first determine the page layout and then determine which images to use.
Grigsby rightly calls it a chicken and egg dilemma. “How do we reconcile a pre-parser that wants to know which size image to download ahead of time with an image technique that wants to respond to its environment once the page layout has been calculated?”
Grigsby argues that the smart thing to do might be for browsers to eliminate pre-fetching:
For existing web content, the lookahead pre-parser is undoubtedly the fastest way to render the page. But if web development moves towards responsive images as standard practice, then delaying the download of images until the proper size of the image in the layout can be determined may actually be faster than using the lookahead pre-parser. The difference in size between a retina image for iPad and an image used on a low resolution mobile phone is significant.
That’s going to be a tough sell to browser makers right now. Browser makers are understandably loath to do anything that might slow down page-load times — even if that slow-down is temporary.
Other possible solutions Grigsby covers include progressive image formats (which suffer from similar chicken-and-egg dilemmas) and of course the
<picture> element. The whole article is well worth a read since it gets into more details about why all of these solutions are ultimately less than ideal.