Make an image inventory by page position
List the images in a representative page template and classify them by their actual position in the initial mobile and desktop views. Include the hero, logos, article illustrations and related-content thumbnails. Record where a responsive layout changes an image’s visibility. A shared image component needs an explicit exception mechanism when its instances serve different purposes.
The decision is about when the resource is needed, not whether the image is decorative or informative. A decorative image can still dominate the initial view, while an important diagram may sit far down a long guide. Keep alternative-text review separate from loading policy; one does not establish the other.
Keep initially needed images available promptly
The web.dev guidance recommends avoiding lazy loading for images visible in the initial viewport, especially an LCP image. Review the emitted markup to ensure a blanket loading="lazy" rule has not reached these instances. Removing that attribute is a loading-policy change, not proof that all performance delays are solved.
For images clearly outside the initial view, native lazy loading can defer work until the browser considers the resource close enough to be needed. Do not promise that a request begins at an exact scroll position. Browser decisions and conditions can differ, so verify the actual behavior in the environments relevant to the page.
Account for hidden and responsive content
Check cards, tabs and galleries in the states visitors actually use. An image outside the viewport during initial loading may become important after a control is activated. Record whether the image becomes visible in time and whether the interface communicates any wait. Do not classify every hidden image as disposable simply because it is absent in the first screenshot.
Inspect the HTML produced by the template and any script that also manages image loading. Two independent mechanisms can make debugging confusing. Prefer a clearly owned implementation and test its output rather than combining plugins without checking their interaction. Reserve suitable layout space separately so loading changes do not introduce avoidable movement.
Illustrative example: a service page and a long gallery
Imagine a fictional service page with a visible introductory illustration and a gallery well below the first screen. The reviewer keeps the introductory image eager and proposes native lazy loading for the gallery items. This is a candidate policy based on that layout, not a claim of measured savings or a universal rule for all service pages.
The mobile layout places the first gallery item much higher than the desktop layout. The reviewer adjusts that instance’s policy and retests both views. If a gallery image appears too late during the tested journey, the team records the case and revises the choice. It does not report success just because the markup contains a lazy attribute.
Verify requests and the visible journey
Test initial loading and a normal scroll through the page while observing network requests and visible content. Record the device, viewport, cache state and any throttling so comparisons are meaningful. Check that initially important content has not been delayed and that deferred images appear when the reader reaches them.
After the change, retain before-and-after observations under comparable conditions. Distinguish a lower initial request count from improved user experience, and do not infer field performance from one local run. A website audit can locate loading attributes for review; the final choice should follow the page’s layout, measured behavior and reader journey.