An image that loads only when it is nearly on screen saves the visitor everything below the fold. If the browser did not know how big it would be, the page then jumps when it arrives - and the reader loses their place, or taps a link that has moved.

Always give width and height

<img src="/img/rack.webp" width="1600" height="900" alt="A server rack" loading="lazy" decoding="async">

They are not the display size. They are the aspect ratio, and the browser reserves exactly the right space from them while the file is still downloading. With CSS width:100%;height:auto the picture still scales normally.

Never lazy-load the top of the page

loading="lazy" on the hero image delays the largest thing on screen, which is the one metric that measures how fast the page feels. The rule is simple: everything above the fold loads eagerly, everything below it is lazy.
<!-- hero: eager, and asked for early -->\n<img src="/img/hero.webp" width="1600" height="900" alt="" fetchpriority="high">

The same applies to embeds

An iframe takes width and height and loading="lazy" too. A video embed left eager is often the single heaviest thing on a page and it is usually below the fold.

And to anything a script reveals

A reveal-on-scroll effect that starts at opacity 0 shows a blank card to anyone whose script did not run. Make the hidden state opt-in - applied by the script once it is alive - so the content is visible by default.

Check it

Load the page with the network throttled and watch whether anything moves after the images arrive. Cumulative Layout Shift in a Lighthouse run puts a number on the same thing - see measuring Core Web Vitals.