Combine that with my plugin "imagemin-webpack-plugin"  which will ensure they are all compressed as well as you want, and you can get a fairly drop-in solution to massively reduce the size of images downloaded while keeping extremely high resolutions for user agents that want it, and without a ton of manual work on your part!
I've always wanted to look into taking this a step further and somehow determine the actual size of the image on the screen in various resolutions and then generate more accurate image sizes and fill in the `sizes` attribute. I've thought that you might be able to pull it off with some automated headless browsing of the built app with some work, but I never got around to trying it.
It feels like we are slaves to the tech and not the other way around.
It's Chrome only for now but it's a nice future.
As long as you provide a `src` attribute, older browsers will just ignore the `srcset/sizes` attributes and work like always. So it's backward compatible.
About a year ago, I went all the way down the rabbit hole of programmatically generating `srcset` attributes and wrote about it:
With the advantage that you have attributes (background-size, etc) to handle image resizing and alignment without having to faff around with imgs, divs to contain said imgs and a bunch of CSS rules for each for hours?
AND the advantage that you can have one single file for "media" definitions that allows you to swap images around when needed (just change the url()) without having touch 347 HTML files just to set the image src?
Or maybe I am missing the point.
The cascading part of CSS means the a later rule could override an earlier one, so to determine which image variant to download when looking at the css the browser needs to parse the html, parse the css, link the two. A css rule may end up not even applying to any elements on the page if a particular selector has no matches. Only after all this can it begin downloading the actual images.
Using srcset/sizes the browser parses the html and can begin downloading the correct image variants immediately, before it parses css.
With prefetching enabled this means your browser could parse the html and cache all the image variants on the page that you'll need when hovering over a link to another page. So when you actually click on it everything is loaded from cache and super fast.
It's up the browser to manage situations of lower network speed, pixel density, etc. and to determine when and how much preloading to do. Using srcset/sizes just gives the browser the option to optimize as much as needed.
I did not consider the overhead of the browser parsing the CSS file and then figuring out which rules are applied where and depending on what rules are being applied, figuring out what else needs to be downloaded, etc.
But is that overhead really that significant? Or will the responsive images approach merely shave off a few % off the page load time?
And something like srcSet will possibly allow the useragent to become "smarter" in the future. Perhaps halving image size when low on battery, or when on a limited mobile plan.
This isn't you choosing which image to serve who as a developer, it's serving up a bunch of options and letting the useragent choose which it knows is best for the user at that time.
If you're on a slow connection, it can make a page load like it was loading from cache. Which can be quite significant compared to the css approach.
The question of whether the time spent implementing the feature is worth the benefits for a particular project / audience will vary on your use case.
What you're describing can mean loading something large and resizing responsively -- which can result in enlarged photos or wasted bytes to load an image of a size you don't need.
This is an interesting approach for people who don't mind cluttering their HTML, but want to scale media appropriately.
So you could have media queries for small size, medium size and large size with urls pointing to different images, and only the appropriate image will be downloaded and applied, thus achieving the same effect.
Almost all CDNs/services compress images lightly if at all, offline tools are better at this, e.g. images from the reference page can be ~20% smaller. Ideally, hidpi images should be compressed harder, e.g. lower JPEG quality.
Hopefully talking about the 'why' will help others make the right choices for their project.
The reference page will see improvements in the future as we enhance our process, but certainly resizing and optimizing variants by hand can yield even better results if you have the time.
What is worth noting from part 1 is that using pixel width variants in `srcset` will let the browser factor in dpi of your monitor as part of the calculation. So it wouldn't serve a 2x image where it only needed 1x.
It's not recommended to use high dpi images, 72dpi is the way to go for web content, with a larger (dimensions) version serving as the 2x variant.
<img width="43" height="44" srcset="https://s2.construct.net/images/v173/r/global/construct-3-logo_v43.png 1x, https://s2.construct.net/images/v173/r/global/construct-3-logo_v64.png 1.5x, https://s2.construct.net/images/v173/r/global/construct-3-logo_v90.png 2x, https://s3.construct.net/images/v173/r/global/construct-3-logo_v110.png 2.5x, https://s3.construct.net/images/v173/r/global/construct-3-logo_v130.png 3x" src="https://s2.construct.net/images/v173/r/global/construct-3-logo_v43.png" alt="Logo"/>
<img class="jsEnabled" data-src="https://s1.construct.net/images/v173/r/home/monster_v350.png" width="350" height="367" data-srcset="https://s1.construct.net/images/v173/r/home/monster_v350.png 1x, https://s1.construct.net/images/v173/r/home/monster_v550.png 1.5x, https://s3.construct.net/images/v173/home/monster.png 2x" src="https://s1.construct.net/images/v173/1.gif" alt="Monster"/>
<img width="350" height="367" srcset="https://s1.construct.net/images/v173/r/home/monster_v350.png 1x, https://s1.construct.net/images/v173/r/home/monster_v550.png 1.5x, https://s3.construct.net/images/v173/home/monster.png 2x" src="https://s1.construct.net/images/v173/r/home/monster_v350.png" alt="Monster"/>
It can be quite fiddly doing this, but it's nice when it's done and works as expected!
Some sort of hybrid between the two, and the recs in the article, seem to be the future of visual imagery online.