> That's what srcset & <source> were invented for. next/image makes use of srcset. > This has been done many times before. For images outside the viewport it'

> That's what srcset & <source> were invented for. next/image makes use of srcset. > This has been done many times before. For images outside the viewport it's great; for images which are in the viewport, the browser isn't able to discover the image until the JS has loaded and decided which image size to fetch. In my experience this slows down the overall rendering of the page. >I see the Google Chrome team was involved in creating this component so I'd like to know what's different this time, because they have the data. No knowledge of what Google contributed to this, but my experience of running Google PageSpeed Insights on many sites is that this sort of optimization does improve the metrics Google measures. Also, while I agree in part with most of your points, I still think we should give credit to nextjs for making this easy. Sure, maybe you don't need a library to use srcset. If you are going to run our own custom build processes (or server endpoints) that generate images in a range of appropriate sizes and write the corresponding front-end code, good for you. Next.js has done nothing to stop any of this. But many (most?) websites don't bother with any of that and just load one giant image for everyone. If there is a tool that makes using optimized images as easy loading one giant image for everyone, I think that's great.