<story><title>Next.js 10</title><url>https://nextjs.org/blog/next-10</url></story><parent_chain><item><author>pbowyer</author><text>&amp;gt; Nowadays users browse the web using their phones, tablets, and laptops, yet images are still as a one size fits all. For example: sites load a 2000 by 2000 pixel image, but phones are only displaying it as 100 by 100 pixels.&lt;p&gt;That&amp;#x27;s what srcset &amp;amp; &amp;lt;source&amp;gt; were invented for.&lt;p&gt;&amp;gt; Furthermore, 30% of images on web pages are outside of the initial viewport, meaning the browser loads images that a user does not see until they scroll further down the page.&lt;p&gt;That&amp;#x27;s why we now have a loading=lazy HTML attribute&lt;p&gt;&amp;gt; When using the next&amp;#x2F;image component, images are automatically lazy-loaded, meaning they&amp;#x27;re only rendered when the user is close to seeing the image. This prevents loading that 30% of images outside of the initial viewport.&lt;p&gt;This has been done many times before. For images outside the viewport it&amp;#x27;s great; for images which are in the viewport, the browser isn&amp;#x27;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.&lt;p&gt;I see the Google Chrome team was involved in creating this component so I&amp;#x27;d like to know what&amp;#x27;s different this time, because they have the data.&lt;p&gt;&amp;gt; Developers can mark images that are in the initial viewport, allowing Next.js to automatically preload these images. Preloading images in the initial viewport has shown improvements to the Largest Contentful Paint by up to 50%.&lt;p&gt;How can smart preloading work when the image size isn&amp;#x27;t known until the JS component runs? If we&amp;#x27;re back to loading the 2000px image then we&amp;#x27;re losing a lot of optimization.&lt;p&gt;If they&amp;#x27;re relying on client hints [1] then we can get as far as an image as wide as the browser window width, but no more - at the price of poor browser compatibility.&lt;p&gt;Preloading also has its own costs, as it messes with the browser&amp;#x27;s prioritization of page content. I&amp;#x27;ve found it easy to prioritize something you know is essential and unintentionally increase load time metrics.&lt;p&gt;1. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;caniuse.com&amp;#x2F;client-hints-dpr-width-viewport&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;caniuse.com&amp;#x2F;client-hints-dpr-width-viewport&lt;/a&gt;</text></item></parent_chain><comment><author>mulholio</author><text>&amp;gt; That&amp;#x27;s what srcset &amp;amp; &amp;lt;source&amp;gt; were invented for.&lt;p&gt;Next.js is going to be using srcset under the hood, I&amp;#x27;m sure. The whole point of Next.js is to make best practices like this defaults, not to do anything groundbreaking and new.</text></comment>
<story><title>Next.js 10</title><url>https://nextjs.org/blog/next-10</url></story><parent_chain><item><author>pbowyer</author><text>&amp;gt; Nowadays users browse the web using their phones, tablets, and laptops, yet images are still as a one size fits all. For example: sites load a 2000 by 2000 pixel image, but phones are only displaying it as 100 by 100 pixels.&lt;p&gt;That&amp;#x27;s what srcset &amp;amp; &amp;lt;source&amp;gt; were invented for.&lt;p&gt;&amp;gt; Furthermore, 30% of images on web pages are outside of the initial viewport, meaning the browser loads images that a user does not see until they scroll further down the page.&lt;p&gt;That&amp;#x27;s why we now have a loading=lazy HTML attribute&lt;p&gt;&amp;gt; When using the next&amp;#x2F;image component, images are automatically lazy-loaded, meaning they&amp;#x27;re only rendered when the user is close to seeing the image. This prevents loading that 30% of images outside of the initial viewport.&lt;p&gt;This has been done many times before. For images outside the viewport it&amp;#x27;s great; for images which are in the viewport, the browser isn&amp;#x27;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.&lt;p&gt;I see the Google Chrome team was involved in creating this component so I&amp;#x27;d like to know what&amp;#x27;s different this time, because they have the data.&lt;p&gt;&amp;gt; Developers can mark images that are in the initial viewport, allowing Next.js to automatically preload these images. Preloading images in the initial viewport has shown improvements to the Largest Contentful Paint by up to 50%.&lt;p&gt;How can smart preloading work when the image size isn&amp;#x27;t known until the JS component runs? If we&amp;#x27;re back to loading the 2000px image then we&amp;#x27;re losing a lot of optimization.&lt;p&gt;If they&amp;#x27;re relying on client hints [1] then we can get as far as an image as wide as the browser window width, but no more - at the price of poor browser compatibility.&lt;p&gt;Preloading also has its own costs, as it messes with the browser&amp;#x27;s prioritization of page content. I&amp;#x27;ve found it easy to prioritize something you know is essential and unintentionally increase load time metrics.&lt;p&gt;1. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;caniuse.com&amp;#x2F;client-hints-dpr-width-viewport&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;caniuse.com&amp;#x2F;client-hints-dpr-width-viewport&lt;/a&gt;</text></item></parent_chain><comment><author>jaredklewis</author><text>&amp;gt; That&amp;#x27;s what srcset &amp;amp; &amp;lt;source&amp;gt; were invented for.&lt;p&gt;next&amp;#x2F;image makes use of srcset.&lt;p&gt;&amp;gt; This has been done many times before. For images outside the viewport it&amp;#x27;s great; for images which are in the viewport, the browser isn&amp;#x27;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.
&amp;gt;I see the Google Chrome team was involved in creating this component so I&amp;#x27;d like to know what&amp;#x27;s different this time, because they have the data.&lt;p&gt;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.&lt;p&gt;Also, while I agree in part with most of your points, I still think we should give credit to nextjs for making this easy.&lt;p&gt;Sure, maybe you don&amp;#x27;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.&lt;p&gt;But many (most?) websites don&amp;#x27;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&amp;#x27;s great.</text></comment>