It's worth noting ImgIx is proprietary, and not particularly cheap.

300$ a month for 20 unique users and 10 sources. For business' which are very media focused, ImgIx could solve some headaches, yet those same people are going to be very limited with a billing system like that.

ImgIx is just an ancillary detail to point the post is trying to make though, and if anything is used as an excuse to _not_ talk about the 3rd of the three problems the author raised.

Replace it with whatever asset packaging responsive image generator you want to add to your build pipeline.

I doubt you would need so many srcset rules, since there's likely an upper maximum of image size in bytes that you'd like to deliver, and a minimum size you can expect the image to get to. If you're being so pragmatic as to worry about the filesize of your markup, you don't want to then blow up your download budget with massive images.

I think browsers and protocols could do more to help this issue, by sending some context along with the request for the image in the first place, so the server can make some decisions. We can do that ourselves too, but it's not a very robust solution to be using javascript to make decisions for image sizes before you've even finished loading your page.

IIUC, the idea is to prevent resizing on common phone sizes so they don't spend additional time and CPU/GPU resources processing the images once they are downloaded.