1
00:00:03,000 --> 00:00:04,951
We updated the ReviewPage

2
00:00:04,951 --> 00:00:07,726
to use the Next Image component.

3
00:00:07,726 --> 00:00:10,846
But to get it to work we had to configure

4
00:00:10,846 --> 00:00:14,534
which server it's allowed to load the images from.

5
00:00:14,534 --> 00:00:16,960
Now, let's go and inspect this image,

6
00:00:16,960 --> 00:00:18,472
and see what's different,

7
00:00:18,472 --> 00:00:21,144
now that we're using the Image component.

8
00:00:21,144 --> 00:00:24,500
First of all, note how it's still rendered

9
00:00:24,500 --> 00:00:26,498
as an HTML "img" element.

10
00:00:26,578 --> 00:00:29,228
The most important difference is that

11
00:00:29,228 --> 00:00:32,927
the image is now loaded from the Next.js server,

12
00:00:32,927 --> 00:00:35,042
not directly from Strapi.

13
00:00:35,042 --> 00:00:38,066
The address is "localhost" port 3000,

14
00:00:38,066 --> 00:00:40,191
that's the Next.js server.

15
00:00:40,273 --> 00:00:42,680
Which image to load is then passed

16
00:00:42,680 --> 00:00:44,308
as the "url" parameter,

17
00:00:44,379 --> 00:00:47,095
but we're look at that in more detail later.

18
00:00:47,095 --> 00:00:51,017
Now, the original size is 1280 by 720,

19
00:00:51,017 --> 00:00:54,001
which is actually the same as the Strapi image.

20
00:00:54,001 --> 00:00:57,456
But note that there's a "srcset" attribute.

21
00:00:57,456 --> 00:01:00,502
This is used to provide different images

22
00:01:00,502 --> 00:01:02,786
for different pixel densities.

23
00:01:02,863 --> 00:01:05,844
You can see that there's a "2x" src,

24
00:01:05,844 --> 00:01:08,926
that will be used for high density screens,

25
00:01:08,926 --> 00:01:11,341
like Retina displays on Mac.

26
00:01:11,341 --> 00:01:13,585
That is in fact what it's currently

27
00:01:13,585 --> 00:01:14,868
using on my machine,

28
00:01:14,932 --> 00:01:17,491
so that's why the image is larger than

29
00:01:17,491 --> 00:01:19,645
the "width" set on this element.

30
00:01:19,713 --> 00:01:22,831
If we look at the "1x" src instead,

31
00:01:22,831 --> 00:01:26,925
that one has "w=640" in the URL,

32
00:01:26,925 --> 00:01:31,752
so it would be resized down to 640 pixels wide.

33
00:01:31,752 --> 00:01:34,425
Anyway, the point is that Next.js

34
00:01:34,425 --> 00:01:36,775
provides different image URLs

35
00:01:36,856 --> 00:01:40,166
and then the browser decides which one to load,

36
00:01:40,166 --> 00:01:42,196
based on the screen type.

37
00:01:42,196 --> 00:01:44,832
Another attribute set automatically

38
00:01:44,832 --> 00:01:46,263
is "loading: lazy",

39
00:01:46,339 --> 00:01:49,473
but we'll talk more about that in the next video.

40
00:01:49,473 --> 00:01:52,336
Let's focus on sizes for the moment.

41
00:01:52,336 --> 00:01:54,762
You can see that the file is 87

42
00:01:54,762 --> 00:01:56,797
point something kilobytes.

43
00:01:56,875 --> 00:01:58,672
It should be the same number

44
00:01:58,672 --> 00:02:00,341
we see in the Network tab.

45
00:02:00,405 --> 00:02:04,372
But first, note that the type is now "webp",

46
00:02:04,372 --> 00:02:06,685
rather than "jpeg", that was the

47
00:02:06,685 --> 00:02:08,562
format returned by Strapi.

48
00:02:08,636 --> 00:02:11,730
So Next.js automatically converted

49
00:02:11,730 --> 00:02:13,368
the image to WebP.

50
00:02:13,459 --> 00:02:15,545
Now, to see the actual size here

51
00:02:15,545 --> 00:02:17,565
we'll need to do a hard-reload,

52
00:02:17,630 --> 00:02:19,524
because it was being cached.

53
00:02:19,524 --> 00:02:21,710
You can see that it's again 87

54
00:02:21,710 --> 00:02:23,604
point something kilobytes.

55
00:02:23,677 --> 00:02:27,650
If you remember, it was 147 kB

56
00:02:27,650 --> 00:02:29,706
before we changed our code to

57
00:02:29,706 --> 00:02:31,762
use the Next Image component.

58
00:02:31,833 --> 00:02:34,932
So now it's about 40% smaller,

59
00:02:34,932 --> 00:02:37,219
simply by converting the image

60
00:02:37,219 --> 00:02:38,897
from "jpeg" to "webp".

61
00:02:38,973 --> 00:02:40,947
Now, let's go to the Console.

62
00:02:40,947 --> 00:02:43,031
There's a warning here, mentioning

63
00:02:43,031 --> 00:02:44,686
something about "priority".

64
00:02:44,747 --> 00:02:47,023
We'll fix this in the next video,

65
00:02:47,023 --> 00:02:49,230
when we talk about lazy loading.

66
00:02:49,299 --> 00:02:52,572
What I wanted to do is copy the image address

67
00:02:52,572 --> 00:02:54,737
and paste it here, to explain

68
00:02:54,737 --> 00:02:56,379
this URL a bit better.

69
00:02:56,453 --> 00:03:00,603
It's calling the Next.js server on port 3000,

70
00:03:00,603 --> 00:03:04,565
at the special "_next/image" path.

71
00:03:04,565 --> 00:03:07,179
That's what runs the Image Optimization

72
00:03:07,179 --> 00:03:08,452
code on the server.

73
00:03:08,519 --> 00:03:11,301
But it also includes a "url" parameter,

74
00:03:11,301 --> 00:03:14,683
that I'm going to pass to "decodeURIComponent"

75
00:03:14,683 --> 00:03:17,679
to show its value in a more readable format.

76
00:03:17,679 --> 00:03:21,122
You can see that this is the original image URL,

77
00:03:21,122 --> 00:03:25,543
as served by Strapi, on port 1337.

78
00:03:25,543 --> 00:03:29,318
So basically the browser calls the Next.js server

79
00:03:29,318 --> 00:03:32,559
and says: can you give me this image from Strapi?

80
00:03:32,559 --> 00:03:34,986
Let me explain this with a diagram.

81
00:03:34,986 --> 00:03:37,813
We have a web browser, the Next.js

82
00:03:37,813 --> 00:03:40,140
server running on port 3000,

83
00:03:40,224 --> 00:03:44,087
and the Strapi server on port 1337.

84
00:03:44,087 --> 00:03:46,986
The browser finds an img element in the page,

85
00:03:46,986 --> 00:03:49,451
and so it loads that img src,

86
00:03:49,451 --> 00:03:52,556
sending a request to the Next.js server.

87
00:03:52,556 --> 00:03:55,073
The Image component we use in our code

88
00:03:55,073 --> 00:03:57,439
rewrites the src value to point

89
00:03:57,439 --> 00:03:59,195
to the Next.js address.

90
00:03:59,271 --> 00:04:02,520
But it also sets a "url" parameter, pointing

91
00:04:02,520 --> 00:04:04,513
to the original Strapi src.

92
00:04:04,587 --> 00:04:08,120
So the Next.js server then calls Strapi

93
00:04:08,120 --> 00:04:12,325
requesting that image, for example "hades.jpg".

94
00:04:12,325 --> 00:04:15,972
And Strapi will return the original image file.

95
00:04:15,972 --> 00:04:19,507
At this point Next.js optimizes that image,

96
00:04:19,507 --> 00:04:21,721
by converting it to "webp",

97
00:04:21,721 --> 00:04:23,937
that reduces the file size.

98
00:04:24,019 --> 00:04:26,176
It might also scale the image

99
00:04:26,176 --> 00:04:27,962
to different dimensions,

100
00:04:28,036 --> 00:04:30,876
depending on the props we set in our code.

101
00:04:30,876 --> 00:04:32,867
The server will then save the

102
00:04:32,867 --> 00:04:34,651
resulting file to a cache.

103
00:04:34,720 --> 00:04:37,766
And finally it will return it to the browser.

104
00:04:37,766 --> 00:04:41,956
So, the Next.js server acts as a kind of proxy,

105
00:04:41,956 --> 00:04:45,080
that optimizes the images on demand.

106
00:04:45,080 --> 00:04:47,086
Each image is converted the

107
00:04:47,086 --> 00:04:49,017
first time it's requested,

108
00:04:49,092 --> 00:04:50,767
and then it's kept in a cache,

109
00:04:50,767 --> 00:04:53,590
so that if the server receives another

110
00:04:53,590 --> 00:04:55,372
request for the same URL

111
00:04:55,447 --> 00:04:58,672
it will simply return the pregenerated file,

112
00:04:58,672 --> 00:05:01,485
without having to call the CMS again.

113
00:05:01,485 --> 00:05:03,544
This also explains why

114
00:05:03,544 --> 00:05:05,505
Image Optimization doesn't

115
00:05:05,505 --> 00:05:07,466
work with a Static Export.

116
00:05:07,542 --> 00:05:10,373
We need Node.js to run the code that

117
00:05:10,373 --> 00:05:12,810
optimizes the images on demand.

118
00:05:12,889 --> 00:05:16,843
This is not possibleÂ with a fully static website.

119
00:05:16,843 --> 00:05:18,839
Now, I mentioned a cache.

120
00:05:18,839 --> 00:05:21,526
We can see that if we look at the ".next"

121
00:05:21,526 --> 00:05:23,229
folder inside our project.

122
00:05:23,295 --> 00:05:25,375
This contains a "cache" folder,

123
00:05:25,375 --> 00:05:26,703
with "images".

124
00:05:26,703 --> 00:05:29,796
And here we should find the optimized image.

125
00:05:29,796 --> 00:05:33,167
You can see that it is in fact a "webp" file.

126
00:05:33,167 --> 00:05:35,650
We don't need to worry about the details,

127
00:05:35,650 --> 00:05:38,842
like why it's using that very long file name.

128
00:05:38,842 --> 00:05:41,920
Next.js will manage the cache internally.

129
00:05:41,920 --> 00:05:45,379
But this is how we can use Image Optimization:

130
00:05:45,379 --> 00:05:48,264
configure which image servers are allowed,

131
00:05:48,264 --> 00:05:50,215
and then simply use the Image

132
00:05:50,215 --> 00:05:51,694
component in our code,

133
00:05:51,761 --> 00:05:55,553
instead of the standard HTML "img" tag.

134
00:05:55,553 --> 00:05:58,120
And Next.js will take care of the rest.

