Lazy-load images that are not needed for the initial view, not the image that forms the main visible content. Deferring a long gallery can reduce early network work, but applying the same rule to a hero image can delay Largest Contentful Paint. Classify images by their role before adding loading attributes.
Identify the initial-view images
Use a narrow mobile viewport as well as a desktop viewport. A layout change can move an image into or out of the first screen, and the LCP element can differ between the two. Identify it with a performance trace instead of assuming the largest source file is the critical image.
Use native lazy loading for secondary images
Set the loading attribute to lazy on appropriate image elements. The browser decides when a nearby image should start downloading, so there is no fixed distance or exact download moment you should promise. Keep a usable src, useful alternative text and width and height representing the correct aspect ratio.
Illustrative example: on a product page, load the main product photo normally and defer a related-products grid farther down. Scroll through that grid on a slow connection and confirm images arrive without blank gaps or sudden layout movement.
Keep the LCP request discoverable
Do not defer the LCP image. Make it discoverable in the initial HTML where possible, and consider a high fetch priority when the request needs help. Preloading is useful in some discovery problems, but preloading every image creates competing work and can waste bandwidth.
Measure the part that changed
Compare request start times and transferred bytes under the same viewport, network and cache conditions. A shorter initial image queue does not directly improve the server response time for the HTML. Check LCP and layout stability independently, and use field measurements when available rather than treating one lab score as a universal result.