We updated the ReviewPage
to use the Next Image component.
But to get it to work we had to configure
which server it's allowed to load the images from.
Now, let's go and inspect this image,
and see what's different,
now that we're using the Image component.
First of all, note how it's still rendered
as an HTML "img" element.
The most important difference is that
the image is now loaded from the Next.js server,
not directly from Strapi.
The address is "localhost" port 3000,
that's the Next.js server.
Which image to load is then passed
as the "url" parameter,
but we're look at that in more detail later.
Now, the original size is 1280 by 720,
which is actually the same as the Strapi image.
But note that there's a "srcset" attribute.
This is used to provide different images
for different pixel densities.
You can see that there's a "2x" src,
that will be used for high density screens,
like Retina displays on Mac.
That is in fact what it's currently
using on my machine,
so that's why the image is larger than
the "width" set on this element.
If we look at the "1x" src instead,
that one has "w=640" in the URL,
so it would be resized down to 640 pixels wide.
Anyway, the point is that Next.js
provides different image URLs
and then the browser decides which one to load,
based on the screen type.
Another attribute set automatically
is "loading: lazy",
but we'll talk more about that in the next video.
Let's focus on sizes for the moment.
You can see that the file is 87
point something kilobytes.
It should be the same number
we see in the Network tab.
But first, note that the type is now "webp",
rather than "jpeg", that was the
format returned by Strapi.
So Next.js automatically converted
the image to WebP.
Now, to see the actual size here
we'll need to do a hard-reload,
because it was being cached.
You can see that it's again 87
point something kilobytes.
If you remember, it was 147 kB
before we changed our code to
use the Next Image component.
So now it's about 40% smaller,
simply by converting the image
from "jpeg" to "webp".
Now, let's go to the Console.
There's a warning here, mentioning
something about "priority".
We'll fix this in the next video,
when we talk about lazy loading.
What I wanted to do is copy the image address
and paste it here, to explain
this URL a bit better.
It's calling the Next.js server on port 3000,
at the special "_next/image" path.
That's what runs the Image Optimization
code on the server.
But it also includes a "url" parameter,
that I'm going to pass to "decodeURIComponent"
to show its value in a more readable format.
You can see that this is the original image URL,
as served by Strapi, on port 1337.
So basically the browser calls the Next.js server
and says: can you give me this image from Strapi?
Let me explain this with a diagram.
We have a web browser, the Next.js
server running on port 3000,
and the Strapi server on port 1337.
The browser finds an img element in the page,
and so it loads that img src,
sending a request to the Next.js server.
The Image component we use in our code
rewrites the src value to point
to the Next.js address.
But it also sets a "url" parameter, pointing
to the original Strapi src.
So the Next.js server then calls Strapi
requesting that image, for example "hades.jpg".
And Strapi will return the original image file.
At this point Next.js optimizes that image,
by converting it to "webp",
that reduces the file size.
It might also scale the image
to different dimensions,
depending on the props we set in our code.
The server will then save the
resulting file to a cache.
And finally it will return it to the browser.
So, the Next.js server acts as a kind of proxy,
that optimizes the images on demand.
Each image is converted the
first time it's requested,
and then it's kept in a cache,
so that if the server receives another
request for the same URL
it will simply return the pregenerated file,
without having to call the CMS again.
This also explains why
Image Optimization doesn't
work with a Static Export.
We need Node.js to run the code that
optimizes the images on demand.
This is not possibleÂ with a fully static website.
Now, I mentioned a cache.
We can see that if we look at the ".next"
folder inside our project.
This contains a "cache" folder,
with "images".
And here we should find the optimized image.
You can see that it is in fact a "webp" file.
We don't need to worry about the details,
like why it's using that very long file name.
Next.js will manage the cache internally.
But this is how we can use Image Optimization:
configure which image servers are allowed,
and then simply use the Image
component in our code,
instead of the standard HTML "img" tag.
And Next.js will take care of the rest.