I had been lazy loading images for years before the browser started to make it feel ordinary.
On image-heavy websites, especially portfolios, blogs and landing pages, loading every image immediately rarely made sense. A visitor might never scroll to the bottom of the page, but the browser would still download assets sitting far below the fold unless I did something about it. The usual answer was a JavaScript library, an IntersectionObserver implementation or some theme-specific image loading behaviour.
When native lazy loading started appearing as a browser feature in 2019, the interesting part was not just the attribute itself. It was the direction of travel. A performance pattern that used to require custom code was becoming something the browser could understand directly.
Why Lazy Loading Was Usually Custom Code
The old approach worked, but it added another layer to maintain. Images would often be rendered with a placeholder source, a data attribute for the real image and a script that swapped the values when the image moved close to the viewport. That was fine if it was implemented carefully, but every implementation had its own edge cases.
Sometimes the script loaded too late. Sometimes images failed when JavaScript was blocked. Sometimes the placeholder affected layout. Sometimes the same lazy loading library was copied between projects without anyone checking whether it still suited the design. None of those problems were impossible to solve, but they were small pieces of maintenance that attached themselves to a very common requirement.
That is why browser-level lazy loading felt important. It suggested that common performance behaviours could become part of HTML rather than something every developer had to rebuild slightly differently.
What The Attribute Changed
The attribute itself was simple, which was part of its appeal. Instead of relying entirely on a custom script, I could mark an image or iframe as a candidate for lazy loading and let the browser make a decision based on its own loading behaviour.
<img src="project-gallery.jpg" loading="lazy" alt="Project gallery image">That small piece of markup changed the conversation. It meant lazy loading could become part of the content output rather than a separate behaviour attached afterwards. For a WordPress site, that mattered because so many images are generated through templates, blocks, galleries and media fields. A small change in markup could affect a lot of pages.
I still would not have removed every existing solution immediately. Browser support needed checking, and some projects still needed more control over loading thresholds, placeholders or animation. The point was that the native option gave me a simpler default to consider.
Where I Would Still Be Careful
Lazy loading should not be applied blindly. Images that are visible immediately, especially hero images or key product visuals, usually need to load as early as possible. Marking those as lazy can make the first impression worse, even if the page technically downloads less at the beginning.
That is why I tend to think about image priority rather than applying one rule everywhere. Above-the-fold images need to support the first render. Images further down the page can usually wait. Decorative or secondary images should not compete with important content during the first load.
The practical decision is not whether lazy loading is good. It is where it belongs. A performance feature used in the wrong place can create a worse user experience, and that is not a win just because the waterfall looks cleaner.
WordPress And Media-Heavy Pages
WordPress sites made this particularly relevant because clients can keep adding images long after launch. A developer might optimise the original templates carefully, but the site can still become heavier over time as new posts, galleries and case studies are added. That is the normal life of a content-managed website.
For that reason, I liked the idea of performance decisions being baked into the output. If the theme, blocks and templates handle image loading sensibly, the site has a better chance of staying usable as content grows. The client does not have to remember a performance rule every time they upload an image.
This is the kind of detail that often goes unnoticed when the site is launched, but it matters over months and years. Media-heavy pages either remain manageable because the foundations are sensible, or they gradually become slower because every new image adds more weight to the first load.
Retrospective Thoughts
Native lazy loading was not a complete performance strategy. It did not replace image compression, responsive images, caching or good layout decisions. What it did was make one useful behaviour much easier to express.
That is why I found it interesting in 2019. It was another example of the browser taking on work that developers had been solving with custom scripts for years. When the browser can handle something well, I would rather let it. The less custom behaviour a site needs to achieve a basic performance outcome, the easier that site usually is to maintain.