# The Hero Comes First — narration script Runtime 7:03. Timecodes are when each chapter starts; the film's animation is keyed to these cue times, so a recorded voice-over should keep each line near its timecode. ## 0:00 · Above the fold - `0:01` Traditionally print newspapers put the most important story above the fold, where you see it without opening the paper. Web pages have a fold too: the bottom edge of the first screen. - `0:16` Everything above it is what the reader sees first. Everything below it can wait, for now. On this trail page, one image sits above the fold: the big photograph of the lake. Seven more wait below. - `0:34` Getting images right is mostly about order. The one the reader sees first should arrive first. The rest should wait until they're needed. ## 0:45 · The hero - `0:46` That big first photograph seen on a page has a name. Designers call it the hero. It's usually the largest thing on the first screen and it often sets the tone of everything. - `0:58` Given its importance, the hero is usually what the browser ends up measuring. Largest Contentful Paint, or LCP, is the moment the biggest image or block of text on the first screen appears. - `1:15` A good LCP value is two point five seconds or less, for at least three readers in four. On many pages, the hero photograph is what decides it. ## 1:27 · First in line - `1:28` When the page arrives, the browser finds a dozen things to fetch at once. Images sometimes wait behind the stylesheets and scripts, because the browser can't yet tell which images will be on screen. - `1:43` You can tell it. Add fetchpriority="high" to the hero's image tag, and its request moves to the front of the line. Use it on one image, maybe two. If everything is high priority, nothing is. - `2:00` And put the hero in the HTML, as an image tag, where the browser finds it straight away. - `2:08` Make it a CSS background instead, and the browser can't even start until the stylesheet arrives and a rule matches. The hero is found last, when it should be first. It gets worse if JavaScript generates the CSS that sets the background. Remember, we want to work with the web medium, not against it. ## 2:32 · Below the fold, later - `2:32` The images below the fold should be handled differently. A reader might never scroll that far, so why make them wait for the bytes, or pay for them? - `2:43` 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. - `2:56` Just never put lazy on the hero. A lazy image waits until the browser has laid out the page and seen where it lands. Your most important picture would start last. - `3:11` There's also a decoding attribute, a hint about when to unpack the image. Its effect is usually small, so likely the default is fine. ## 3:23 · Hold the space - `3:23` Late images bring one more danger. 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. You're reading, or about to tap, and the page jumps. - `3:41` The fix is two attributes: width and height. From them the browser knows the shape, and saves exactly the right space before a single byte arrives. CSS can still make the picture any size. The shape is what matters. - `3:59` The browser measures those jumps too, as Cumulative Layout Shift, CLS. Good is a tenth or less. Our demo image without dimensions scored nearly seven hundredths. With them: zero. Fun fact: Apple's interface guidelines named this back in nineteen eighty-seven, as perceived stability. It isn't a new technical concept. It's a simple human expectation: once set, things should stay put and act predictably. ## 4:33 · Something while you wait - `4:33` Even the hero takes a moment. The reserved space can show something in the meantime: the photo's main color, or a tiny blurred version of it. - `4:45` This one is a thirty-two pixel copy of the lake: a hundred eighty-six bytes, small enough to put right in the page. Stretched and blurred, it gives the reader the scene's colors and shape, until the real photograph replaces it. - `5:02` Old HTML had an attribute for this, lowsrc. It's long gone, but the idea came back. Today we call them low-quality image placeholders, or LQIP. ## 5:17 · Less often, from nearby - `5:17` Everything so far was about the first page load. A second visit to the page can be almost free, if we set up for it. - `5:27` The browser keeps images it has downloaded, in its cache. The server's Cache-Control header says for how long, and whether to check first. - `5:37` This site asks the browser to check each time. The check is a short question, and if the image hasn't changed, the answer is a three-oh-four: no body, no bytes. 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. - `6:02` 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. ## 6:15 · The golden rule - `6:16` Put it all together, and it's the course's golden rule for performance. Load less data, less often, from nearby, and only when needed. - `6:27` Less data: the right format, at the right size. Less often: caching. When needed: the hero first, everything else later. From nearby: host your images close to the user. - `6:44` Try it. Open the Lazy Loading demo on the Image Performance page, open the Network panel, and scroll. Watch the high-priority hero image go first, and every other image wait its turn.