Lazy loading means not fetching images that are not on screen. A page with twenty images further down requests none of them until the visitor scrolls there. WordPress applies this by default — a good default, and one you should usually leave alone.
There is one exception
The exception is the large image in the first screen: the hero banner, the lead photograph, whatever the visitor sees the instant the page opens.
A lazily loaded image is only requested after layout has been calculated and the browser concludes it is in view. It starts one step late. Meanwhile, the moment the largest piece of content finishes painting is a value performance tooling measures directly — and that largest piece is very often this exact image. You end up delaying the thing being measured.
Identify the element rather than guessing
Confirm it, do not assume it. The performance panel in browser developer tools, and most speed testing services, will tell you which element was judged the largest contentful paint. The answer is often a surprise — sometimes it is a large heading rather than the hero you expected.
If it turns out to be an image, there are three moves: turn lazy loading off for it, mark it as high priority, and where appropriate preload it. Leave every image below it lazy — an exception is only useful while it stays singular.
This is where design decisions land
Here a designer’s decisions touch performance directly. Whether to put a large image in the first screen at all is the first choice; if you do, that single image becomes the one worth optimising hardest. It is also the only image where revisiting format, dimensions and compression against the earlier parts genuinely repays the effort.
Sliders deserve a second look in the same light. If there are five slides, most visitors only ever see the first — yet some implementations fetch all five up front.
The other half of first-screen work (fonts and CSS) is covered in the performance archive, and identifying and correcting the target on a live site is part of the performance work in our optimization program.
Next part
So far this has all been about pixel images. The next part turns to icons and shapes — which do not need to be image files at all, and once they are not, the whole sizing problem disappears.