1
00:00:01,200 --> 00:00:10,138
Traditionally print newspapers put the most important story above the fold, where you see it without opening the paper.

2
00:00:10,349 --> 00:00:16,732
Web pages have a fold too: the bottom edge of the first screen.

3
00:00:16,932 --> 00:00:20,227
Everything above it is what the reader sees first.

4
00:00:20,601 --> 00:00:23,792
Everything below it can wait, for now.

5
00:00:24,165 --> 00:00:31,059
On this trail page, one image sits above the fold: the big photograph of the lake.

6
00:00:31,352 --> 00:00:34,322
Seven more wait below.

7
00:00:34,522 --> 00:00:37,910
Getting images right is mostly about order.

8
00:00:38,051 --> 00:00:41,614
The one the reader sees first should arrive first.

9
00:00:41,825 --> 00:00:45,457
The rest should wait until they're needed.

10
00:00:46,157 --> 00:00:50,149
That big first photograph seen on a page has a name.

11
00:00:50,232 --> 00:00:52,575
Designers call it the hero.

12
00:00:52,786 --> 00:00:58,578
It's usually the largest thing on the first screen and it often sets the tone of everything.

13
00:00:58,778 --> 00:01:04,697
Given its importance, the hero is usually what the browser ends up measuring.

14
00:01:05,094 --> 00:01:15,378
Largest Contentful Paint, or LCP, is the moment the biggest image or block of text on the first screen appears.

15
00:01:15,578 --> 00:01:22,612
A good LCP value is two point five seconds or less, for at least three readers in four.

16
00:01:22,916 --> 00:01:27,674
On many pages, the hero photograph is what decides it.

17
00:01:28,374 --> 00:01:33,701
When the page arrives, the browser finds a dozen things to fetch at once.

18
00:01:34,098 --> 00:01:43,395
Images sometimes wait behind the stylesheets and scripts, because the browser can't yet tell which images will be on screen.

19
00:01:43,595 --> 00:01:44,743
You can tell it.

20
00:01:44,942 --> 00:01:53,253
Add fetchpriority="high" to the hero's image tag, and its request moves to the front of the line.

21
00:01:53,452 --> 00:01:56,411
Use it on one image, maybe two.

22
00:01:56,703 --> 00:02:00,660
If everything is high priority, nothing is.

23
00:02:00,860 --> 00:02:08,265
And put the hero in the HTML, as an image tag, where the browser finds it straight away.

24
00:02:08,465 --> 00:02:17,229
Make it a CSS background instead, and the browser can't even start until the stylesheet arrives and a rule matches.

25
00:02:17,625 --> 00:02:21,640
The hero is found last, when it should be first.

26
00:02:21,851 --> 00:02:27,132
It gets worse if JavaScript generates the CSS that sets the background.

27
00:02:27,215 --> 00:02:31,892
Remember, we want to work with the web medium, not against it.

28
00:02:32,593 --> 00:02:36,434
The images below the fold should be handled differently.

29
00:02:36,645 --> 00:02:43,760
A reader might never scroll that far, so why make them wait for the bytes, or pay for them?

30
00:02:43,959 --> 00:02:56,380
Add loading="lazy", and the browser leaves the image alone until the reader scrolls toward it, starting it well before it comes into view, so it's usually ready on time.

31
00:02:56,580 --> 00:02:59,272
Just never put lazy on the hero.

32
00:02:59,575 --> 00:03:06,563
A lazy image waits until the browser has laid out the page and seen where it lands.

33
00:03:06,774 --> 00:03:10,998
Your most important picture would start last.

34
00:03:11,198 --> 00:03:16,630
There's also a decoding attribute, a hint about when to unpack the image.

35
00:03:16,933 --> 00:03:22,922
Its effect is usually small, so likely the default is fine.

36
00:03:23,622 --> 00:03:26,499
Late images bring one more danger.

37
00:03:26,803 --> 00:03:36,683
If the browser doesn't know an image's dimensions, it lays the text out where the image will go, then shoves everything down when the image arrives.

38
00:03:36,683 --> 00:03:41,059
You're reading, or about to tap, and the page jumps.

39
00:03:41,259 --> 00:03:45,379
The fix is two attributes: width and height.

40
00:03:45,659 --> 00:03:52,972
From them the browser knows the shape, and saves exactly the right space before a single byte arrives.

41
00:03:53,357 --> 00:03:56,770
CSS can still make the picture any size.

42
00:03:56,770 --> 00:03:59,253
The shape is what matters.

43
00:03:59,452 --> 00:04:05,452
The browser measures those jumps too, as Cumulative Layout Shift, CLS.

44
00:04:05,454 --> 00:04:07,809
Good is a tenth or less.

45
00:04:07,985 --> 00:04:12,327
Our demo image without dimensions scored nearly seven hundredths.

46
00:04:12,327 --> 00:04:14,288
With them: zero.

47
00:04:14,557 --> 00:04:22,763
Fun fact: Apple's interface guidelines named this back in nineteen eighty-seven, as perceived stability.

48
00:04:22,788 --> 00:04:25,039
It isn't a new technical concept.

49
00:04:25,180 --> 00:04:33,096
It's a simple human expectation: once set, things should stay put and act predictably.

50
00:04:33,796 --> 00:04:35,896
Even the hero takes a moment.

51
00:04:36,106 --> 00:04:44,870
The reserved space can show something in the meantime: the photo's main color, or a tiny blurred version of it.

52
00:04:45,070 --> 00:04:53,683
This one is a thirty-two pixel copy of the lake: a hundred eighty-six bytes, small enough to put right in the page.

53
00:04:53,894 --> 00:05:02,785
Stretched and blurred, it gives the reader the scene's colors and shape, until the real photograph replaces it.

54
00:05:02,985 --> 00:05:07,697
Old HTML had an attribute for this, lowsrc.

55
00:05:08,001 --> 00:05:11,168
It's long gone, but the idea came back.

56
00:05:11,251 --> 00:05:16,938
Today we call them low-quality image placeholders, or LQIP.

57
00:05:17,638 --> 00:05:21,154
Everything so far was about the first page load.

58
00:05:21,458 --> 00:05:26,994
A second visit to the page can be almost free, if we set up for it.

59
00:05:27,194 --> 00:05:31,488
The browser keeps images it has downloaded, in its cache.

60
00:05:31,792 --> 00:05:37,664
The server's Cache-Control header says for how long, and whether to check first.

61
00:05:37,864 --> 00:05:42,053
This site asks the browser to check each time.

62
00:05:42,264 --> 00:05:51,492
The check is a short question, and if the image hasn't changed, the answer is a three-oh-four: no body, no bytes.

63
00:05:51,889 --> 00:06:02,545
Name your files after their contents, and you can tell browsers to keep them for a year without asking at all, because a new image gets a new name.

64
00:06:02,745 --> 00:06:15,352
And a content delivery network keeps copies close to readers, all over the world, so even a first visit fetches from nearby instead of from one distant server.

65
00:06:16,052 --> 00:06:20,868
Put it all together, and it's the course's golden rule for performance.

66
00:06:21,079 --> 00:06:27,265
Load less data, less often, from nearby, and only when needed.

67
00:06:27,465 --> 00:06:31,585
Less data: the right format, at the right size.

68
00:06:31,610 --> 00:06:33,709
Less often: caching.

69
00:06:33,909 --> 00:06:38,342
When needed: the hero first, everything else later.

70
00:06:38,727 --> 00:06:43,880
From nearby: host your images close to the user.

71
00:06:44,080 --> 00:06:45,088
Try it.

72
00:06:45,171 --> 00:06:51,961
Open the Lazy Loading demo on the Image Performance page, open the Network panel, and scroll.

73
00:06:52,265 --> 00:06:58,637
Watch the high-priority hero image go first, and every other image wait its turn.