Image loading checker

Lazy loading defers a fetch until the image approaches the viewport. For an image already in the viewport, there is nothing to defer and the deferral is pure delay.

Worse, it removes the image from the browser's early discovery: the fetch is scheduled later than it would otherwise have been, not merely at the same time.

The largest element painted in the initial viewport is frequently an image — a hero, a product photograph, a banner. Marking it lazy directly delays the paint that most rendering measurements are built around.

The rule is therefore simple and absolute: never lazy-load an image that is visible without scrolling, and lazy-load essentially everything that is not.

A blanket lazy attribute applied by a template or a plugin to every image is how this happens, and it is applied by well-meaning optimisation tooling more often than by hand.

Which images carry a lazy loading attribute, read from the served markup.

Which images appear above the fold, established from the layout information available to the scan.

Which image is the likely candidate for the largest painted element, so the one that matters most is identified specifically rather than left inside a list.

Whether a fetch priority is declared, which is the way to tell the browser that one image matters more than the others rather than merely that it should not be deferred.

Whether the same image is also preloaded, since a preload and a lazy attribute on the same element are contradictory instructions.

No lazy attribute on any image visible without scrolling, and a lazy attribute on essentially all of the rest.

The likely largest painted image loaded eagerly, ideally with a high fetch priority so it is scheduled ahead of other resources.

No image carrying both a preload and a lazy attribute.

Below-the-fold images deferred, which on a long page is the majority of the image weight and the whole reason the mechanism exists.

Which image sits above the fold depends on the layout, which depends on the viewport. A banner above the fold on a desktop width can be below it on a phone.

Templates make the mistake systematically rather than individually: one component with a hard-coded lazy attribute produces the defect on every page that uses it.

The symptom is also unhelpfully subtle. The page works, the image appears, and the only evidence is a rendering measurement that is worse than the page deserves.

So the finding is usually one attribute in one component, reported across many pages — which reads as a large problem and is a small edit.

`images.lazy_loading` reads the lazy loading attributes. `images.above_the_fold` establishes which images appear without scrolling.

`images.lcp` identifies the image most likely to be the largest element painted, which is the one the rule above is really about.

`performance.lazy_loading` reads the same declarations from the performance side, and `performance.preload` is what detects the contradictory preload.

Above the fold is relative to a viewport. What the scan measures is one set of dimensions, and a different screen produces a different boundary.

The largest painted element is identified as a likely candidate from the served markup and layout, not measured in a real browser over real visits.

Images inserted by script after render are outside the inventory, and a lazy attribute applied by script is not visible in the served markup.

Whether deferring a given image measurably helps depends on the page and the connection, which is field measurement rather than a static check.