To conclude this section on Image Optimization,
I want to test a production build of our app,
and show you how images work in that environment.
Let me go and stop the dev server,
and maximize the terminal,
so we can see the full build output.
Ok, our production build is ready.
Now let's start the server,
and to test our app we want to
look at the Network requests.
Let's go and reload the page,
doing a full "empty cache and hard reload".
You can see that
the images have been converted to "webp".
The first one is loaded right
after the stylesheet,
because it has the "priority" property set.
While the other two are loaded
after the "main-app" script
because they use lazy loading.
If we look at the details for a request
you can see that the URL is always the one
for the special Next.js image path,
and then the "url" parameter points
to the original Strapi image.
So everything works pretty much
like with the dev server.
In fact, if we look inside the ".next" folder
we should also see the image
files in the local cache.
This is the one for "Hades".
Note how the image has been resized to "640x360",
and the file size is just 31KB.
So, there isn't much difference between
dev and production server,
when it comes to Image Optimization.
Now, for completeness I shall mention that
it is possible to use the Image component
even when doing a static export.
But only if we don't use the default image loader.
In other words, if we don't use the Next.js server
to convert and resize the images.
One alternative is to set the
"unoptimized" option to true.
This effectively tells the Image component
to just use the original "src" URLs.
Let me show you how this works in practice,
if we do another production build.
Since we configured "output" to "export"
it generated a static website in the "out" folder.
Now, the build process does not download
any of the images from Strapi.
We do have some images here actually,
but these have been copied
from our "public" folder.
In fact, we should really delete
these old images now.
We only needed them before moving to Strapi.
Let me do another build, without
those extra images.
Ok, let's serve the static website.
And let's go and reload the page
in the browser once more.
We can see straight away that
the images are in "jpeg" format.
And if we look at the request URL,
you can see that the image is
loaded directly from Strapi.
So this is how it works with
the "unoptimized" option.
Since we're not running a Next.js server
we cannot use any of the optimizations
done by the server,
like converting to the WebP format,
or resizing the images.
But we can still use the Image component
which enables some browser optimizations,
like setting the "fetchpriority"
on the first image,
or, a better example would be lazy loading,
that's enabled on this other image.
So there is still a small benefit
in using the Image component,
even with the "unoptimized" option.
Although I have to say that
you could also set the "loading"
attribute yourself
directly on the standard HTML "img" element,
without using the Next Image component.
Now, there's also another option:
you can set the "loader" property
which is useful if you host your
images in a cloud platform,
like "akamai", "cloudinary", or "imgix".
These are services that specialize
in managing digital assets.
Or you can also write your own "custom" loader,
in which case you also need to
set the "loaderFile" option,
pointing to the JavaScript
file with your own code.
You can find out more about this
in the Next.js documentation.
The page for the Image component includes
the Configuration Options,
and if we look at "loaderFile"
we can see some sample code.
Basically, a custom loader is simply a function
that returns the URL for a given image,
given some parameters like "width" and "quality".
So if you want to host your images
on some other platform
you can always write your own loader file.
That said, it seems to me that
you only get the full benefits
of the Image component
if you also use the Next.js server
to do the image optimizations.
So that's what we'll do in this project.