Whenever you need to display an image within an Xjs application, you should use the next JS provided image component as it offers a number of optimizations, which we will cover in this lesson. Let me start off by removing a common misconception that you cannot use the standard B browser native IMG component in next js. In fact, you can use it and it does work in XJS the same way it would work in any React app, but you miss out on the optimizations offered by the next image component. The recommended place for putting static assets like images within your next JS application is within the public folder.

Anything within the public folder automatically becomes accessible on the public internet. As an example, this dog PNG file will be available on slash images slash dog png. Now let's try to use it with a native IMG component. It's always good practice to provide an all text for screen readers and for our source, we provide the public path to our image and this will actually work perfectly fine, but what might confuse you is that the next JS developer tools, specifically the e estin plugin, will complain that you shouldn't be using IMG and instead you should use the image

component provided by next js. This message can be a bit daunting the first time you see it, so let me break it down. What it is saying is that your website might have a slower user experience if you use IMG to give your website users a better experience. You should use the image component provided by X js. However, the next image component might incur additional cost as it uses server resources. If you are happy with the universal experience of the IMG component, you can actually disable this rule within ES lint. And if you look at the website, you can see that the IMG component is working as expected.

However, as expected in this case means that the browser is going to load the image in its full, doesn't matter what size of the window it is, even if it's small, the full three meg image is going to be downloaded even if you provide a different bits for our image. As far as the browser is concerned, it's going to have to load the full image in addition to server bandwidth, which is normally quite cheap. The main issue is that the user's browser is going to be loading an image at a high quality, which might not even be required to easily take advantage of all the next JS image component offers. You should use images imported

as an ES module, but don't worry. We will also look at using URLs with the image component. Once we build a solid foundation, we bring in the image component from the next slash image module, and then we import our image as a static ES module import, providing the relative path into the public folder. And finally, we use this image component, provide a nice alt text followed by setting the source to the imported image file. If you look at this application in the browser, it behaves the same as it did previously, except you might feel that it rendered a bit faster and the reason is revealed.

When we look at the network tab, you can see that the image request is now only 94 kilobytes, and additionally, instead of being PNG, it is a more web friendly web P file. Underneath the image component is still going to render an ING tag, but additionally it's Automatically figured out the widths in the height because we statically imported that image file, this means that even while the image is loading, there will be no layout shift. If we choose to set an explicit width or height, the next day's image component will even resize our source image. Currently, our image request sits at 94 kilobytes, but if you provide a specific dimension, for example,

set the width to 500, you can see that our image request has shrunk down to 36 kilobytes. The image component offers a number of additional conveniences for a better user experience, and one of them is a nice placeholder. Here we have a number of images that we are displaying on screen and we add the placeholder prop setting its value to blur next, yes, will automatically calculate a blurred version of the source image module. Now, when we look at our application while the image is loading, we see a nice blurred version of the final destination image, and that blurred copy is seamlessly removed when the

image is done loading. Another feature offered by the image component is the ability to specify a quality value to control the level of compression in the optimized image. Currently our optimized image sits at 94 kilobytes. The default value for quality is actually 75, so we can squeeze it a bit further by providing a lower value, for example, 50. With this change in place, you can see that the image is now squeezed to around 67 kilobytes. Now, just as a thought experiment, let's see what happens. If I squeeze the quality value all the way down to one, you can see that the image size is now around 19 kilobytes.

And while this image does not look too bad, it's not a value that I feel comfortable using. Now let's see what happens if I bump the quality all the way to the top, which should be value 100. Now the optimized image sits at 528 kilobytes, and while it is quite large, it is still actually smaller than the original source image, which sat at around three megabytes. The next year's image component also supports responsive scaling of the source image file. For responsive scaling of the source image, we need to set the sizes property, and here we are setting it to 100 viewport width so that it scales according to the browser viewport.

Right now you can see that our image is sitting at 94 kilobytes, but let's resize and do a page reload. And because the viewport is now smaller, you can see that the browser requests an image that is now only 36 kilobytes. The way this works under the hood is the image tag has an SRC set, which instructs the browser to download different images for different displayed widths. Another optimization offered by the next year's image component is automatic lazy loading of images. As you scroll through the page to demonstrate this, we have a page with five large images. If you look at this application in the browser, you can see

that only three images have been requested till now. But once we start to scroll towards the bottom of the page and the images are likely to enter the report, the browser automatically makes a request for those additional images. We can actually modify this default behavior using the loading prop by default. It is lazy, but we can actually set it to eager with this modification in place. If you look at the application again, you can see that all five images have been loaded upfront. Now this will result in an increase in the bandwidth, so it's nice that next JS defaults too lazy. A neat way to improve website performance is

to preload important images like the hero image. The way to achieve this is to add them to the head of the H TM L document as a link tag set to preload. And next JS does all of this work with this simple image component prop. We want the browser to start loading the image even before it starts parsing the document body. For this, we simply set the priority prop for the image component to true. Notice that this image is going to be way down on this page thanks to a diviv before it, which is 900 view put height. So by default it wouldn't have loaded, but because of this priority prop,

it is actually going to preload. And if we jump to the browser, that is exactly what we observe. You can see that even though the image is not on screen right now, a request has been made to load that image. And for the curious, I can look at the document head and you can see there is a link with the re set to preload pointing to our image source set.