What Is Lazy Loading?

Lazy loading tells the browser not to download an image or an <iframe> until the user approaches it. Since 2020 no library is needed: loading="lazy" on the tag is enough. The opposite value is eager, which is also the default behaviour.

When the download starts is the browser's own decision, made with a distance threshold that adapts to the connection: on a slow network it begins earlier so the image arrives in time. There is no fixed pixel value, and tuning it from the CMS achieves nothing.

Before the attribute existed, every site solved this with its own JavaScript library: you marked the image with an invented attribute, a script watched the scroll position and moved the path into the real src at the right moment. It worked, and it cost two things. One was the weight of the script itself; the other was that a JavaScript failure left the page with no images at all, which a crawler sees as empty as a visitor does.

The native version removes both problems and adds a subtler one: because switching it on costs nothing, it gets switched on everywhere. A global setting in the CMS marks every image on the site in one click, and nobody looks again at which one came first. That convenience is why the attribute now shows up in many technical SEO audits as the cause of a problem rather than as a solution.

The rule fits in one sentence: lazy load everything except the first visible image. Below the fold it saves data and frees bandwidth; above the fold it delays the very element that sets the LCP.

The damage is not theoretical. Google documents the case explicitly because many content management systems apply the attribute to every image as a rule, hero image included. The browser then stops requesting the most important file early and waits to learn where it lands in the layout, which a template using responsive design decides late.

It is worth understanding why so small a cause does so much damage. The browser builds a priority list while reading the HTML and starts downloading the most important things before it has finished reading. An image marked as lazy drops out of that early list by definition: the browser will not request it until it knows where it lands, and to know that it needs the CSS applied and the layout computed.

In a modern template that happens well after the first byte. The result is that the most important file on the page gets requested among the last, and LCP absorbs that entire wait. This is why the effect is stronger on mobile, where mobile-first indexing decides and the network is usually worse, than on the desktop of the team that made the change.

A lazily loaded image without declared width and height causes a layout shift when it finally arrives: the browser reserved no space. That worsens another of the Core Web Vitals and disturbs the user exactly while reading.

<iframe> elements take the same attribute, and that is often the bigger win: an embedded video or map pulls hundreds of kilobytes of third-party scripts. For background images set in CSS the attribute does not exist; there you need an intersection observer in JavaScript, with the maintenance cost that implies in technical on-page SEO.

A third requirement gets forgotten more often than the other two: lazily loaded images must still sit in the HTML as ordinary <img> elements, with their src and ALT attribute in place. If the CMS replaces them with a placeholder that a script fills in later, the content depends on that script running, and that affects the indexing of the images themselves in Google Images.

For pages that live on images, an e-commerce product page or a gallery, this detail decides whether the photos appear in image results at all. Measure it with data rather than by ear: the performance report in Search Console separates image search from web search, so the drop shows up where it happens.

Open the page, look up which element sets the LCP in PageSpeed Insights, and check whether that <img> carries loading="lazy". If it does, you have cause and fix in the same step.

Then look at field data in Google Search Console, which takes weeks to move, rather than only the lab test. And if the site lives on e-commerce, cross-check the change against conversion: speed shows up in the business before it shows in the report.

The second check is duller and more useful: look at the template's code, not a single page's. The problem almost never lives in one post but in the file that generates them all. Fixing the page you happened to look at leaves the rest untouched, and a week later the report turns red again with a different URL.

With many templates it pays to sort by traffic before touching anything and to re-measure by the same standard afterwards. A KPI that rises on one template and falls on another says nothing when both are read together.

• Switching lazy loading on site-wide from a global setting without excluding the first image.
• Forgetting width and height, trading a speed problem for a visual stability one.
• Applying it to tiny images such as icons, where the extra request costs more than it saves.
• Maintaining a JavaScript library for something the browser has long done by itself.
• Assuming it helps the crawler: the robot does not scroll the way a person does.

And an underlying misunderstanding that explains several of the mistakes above: lazy loading does not make the page faster, it redistributes the work. The total downloaded across a full visit may stay the same; what changes is how much of that total happens before the user sees anything. Anyone expecting the total weight to drop will be disappointed, and anyone measuring only total weight will miss the improvement that genuinely exists in perceived page speed.