Compare image requests before and after scrolling
An HTML attribute alone does not prove that lazy loading works. A reliable check shows which files the browser really requested when the page opened and which appeared only as they approached the viewport.
Simple browser check
- Open the page in a private window and do not scroll.
- Open DevTools → Network, enable Disable cache and select Img.
- Reload and save the list of images already requested.
- Slowly scroll towards the next section containing images.
- Confirm that new requests appear shortly before the images become visible.
- Save two screenshots: before and after scrolling.
How to assess the result
| Observation | Level | Conclusion |
|---|---|---|
| The LCP or first-screen image waits for scrolling | Critical | Lazy loading is applied to the wrong element |
| Dozens of invisible images load immediately | Important | The initial load is unnecessarily heavy |
| One or two small images preload | Minor | Check their purpose and position |
| The first screen is immediate; others load nearby | Good | Lazy loading works |
Inspect the markup
Select an image below the first screen, open Inspect and locate its element. Native lazy loading normally contains:
<img src="..." loading="lazy" ...>Older scripts may use data-src, a class and noscript. Always verify Network as well: the attribute alone proves nothing.
Why results can differ
A browser may preload an image placed close to the viewport. Cache, screen width, CMS behaviour, sliders and JavaScript also affect the result. The automatic audit therefore treats low-priority requests as candidates; the final decision follows a manual position check.
The count and price refer to unique candidates on the submitted URL. Repeated use of one file and one shared-template correction should not be charged repeatedly. If confirmed, you can order the lazy-loading setup.
