WEBVTT

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.