Lazy Loading and SEO: 2026 Guide for Images
Put the lazy setting on a photo at the bottom of a long page, and it saves data for a reader who never scrolls that far. Put the same setting on the big photo at the top, and that reader waits for the one image they see first.
Our take: lazy loading is a rule about position, not about images. In our view, most of the trouble comes from a blanket rule, applied to every image by a theme or plugin, instead of a choice about where each image sits.
This page is for developers, technical SEOs, and WordPress and store owners whose Lighthouse report flags offscreen images.
What is lazy loading, and how does it work?
It is deferred loading: the browser waits to fetch an image or iframe until it nears the screen, instead of fetching everything as the page opens. The loading attribute set to lazy does this with no script. Eager, the default, is the same as leaving the attribute out, and loads the image wherever it sits.
web.dev's guide to the loading attribute, last updated August 13, 2024, notes that Chrome already loads images below the screen at a lower priority, but still fetches them, and the lazy setting stops that early fetch. Google Search Central lists two other methods: the Intersection Observer API with a polyfill, and a JavaScript library that loads content as it enters the viewport.
Does lazy loading hurt SEO?
Not when it is done well: Google calls it "a common performance and UX best practice." The risk is content that waits for a scroll or a click, because Google says its search does not interact with your page. If an image only loads after a user action, Google may never see it.
Google's Fix lazy-loaded content page, last updated December 10, 2025, warns that "if not implemented correctly, this technique can inadvertently hide content from Google." The methods it lists "don't rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page." Our take: the scroll trap is the real SEO risk, not the lazy setting.
Which images should never be lazy-loaded?
Never lazy-load what a reader sees as the page opens. That means the main image, often the Largest Contentful Paint (LCP) element, plus the header logo and the first row of product photos. web.dev warns, "Don't lazy-load images that are likely to be in-viewport when the page loads, especially LCP images."
Google gives the same advice for content "likely to be immediately visible when a user opens a page." Our take: decide per template position, not per photo, by working out which slots sit in the first screen on a phone and on a laptop and keeping those eager.
What did the web.dev study show about LCP?
It showed a link, not proof: in an HTTP Archive analysis on web.dev, the median page with lazy loading had a slower 75th percentile LCP than the median page without it. A follow-up lab test pointed to the problem, deferred images in the first screen, and keeping those eager reversed the lab slowdown.
web.dev's LCP study was last updated March 31, 2022, and these dated figures come from that study. In its HTTP Archive data, the median page without the lazy setting had a 75th percentile LCP of 2,922 milliseconds, against 3,546 with it. The study itself calls these correlational results, not proof of cause, and its lab test found that WordPress deferral "very clearly helps reduce image bytes at the cost of a delayed LCP." Our Core Web Vitals guide covers how to measure LCP.
How should you raise the priority of the main image?
Set fetch priority to high on the main image, and leave the lazy setting off it. web.dev says the eager value does not load an image faster than one with no loading attribute: fetch priority is the lever that moves the main image up the queue. Never put high priority and the lazy setting on one image.
The WordPress 6.3 notes from July 13, 2023, put it bluntly: "lazy-loading an image while also marking it as high priority is an anti-pattern that should be avoided." Our take: give high priority to one image per template, never to every image.
Why do width and height matter more for lazy images?
Without width and height, an image that has not loaded takes up no space, and if it arrives late, the content below can jump, which adds to Cumulative Layout Shift (CLS). web.dev advises the width and height attributes on all images and says lazy-loading makes them more important. Missing sizes can also trick a gallery into loading every photo at once.
MDN's image reference adds that an unloaded lazy image has a width and height of 0. Our guide to image formats, compression and srcset covers the file itself, and our alt text guide is a reminder that a lazy image still needs its alt text.
Which page elements should load eager, and which late?
Keep the main image eager with high priority, and keep the logo and first row of photos eager. Lazy-load photos further down and embeds far down the page, but note that CSS background images cannot use the loading attribute at all. Hidden slides and infinite scroll feeds depend on how they are built.
The third column paraphrases Google, web.dev and WordPress pages, saved on October 7, 2026. The second is our advice.
| Element | Lazy or eager | Why | Source |
|---|---|---|---|
| The main or hero image | Eager with high priority | Deferring the LCP image delays it, and high priority helps it. | web.dev, WordPress 6.3 notes |
| Product photos in the first row | Eager | First-viewport images should use default eager loading. | web.dev images guide |
| Product photos further down | Lazy | They can wait until they near the viewport. | web.dev images guide |
| An iframe or video embed far down the page | Lazy | Readers pay for offscreen embeds they may never see. | web.dev iframe guide |
| A CSS background image | Not possible | The attribute works only on image elements, and Google does not index CSS images. | web.dev, Google image guide |
| An image in a closed tab or carousel slide | Depends | Hidden images may not load, and Chrome 121 changed carousel rules. | web.dev images guide |
| Images in an infinite scroll feed | Depends | Fine if each chunk has its own URL and loads in view. | Google lazy content page |
Should you use the loading attribute or a script library?
Start with the loading attribute. web.dev says that with lazy loading built into browsers, you probably do not need a library, apart from a fallback for old browsers or more control over timing. Browsers that do not support the attribute ignore it with no harm done, and Google Search Central lists both approaches among its methods.
web.dev notes that in July 2020, Chrome cut its trigger distance from 3,000 pixels to 1,250 pixels on 4G, and from 4,000 pixels to 2,500 pixels on 3G or slower. With a library such as lazysizes, Google's test still applies: the real image URL should end up in the src attribute in the rendered HTML. Our take: use the browser attribute first, and add a library only for a reason you can name.
What about iframes, video embeds, maps and ads?
The loading attribute is standardized for iframes too, and embeds far down the page are good candidates, because readers still pay for an offscreen iframe they may never see. Ads shown as images or iframes lazy-load like any other. Our view: a video that is the main content of the page should stay eager.
web.dev's iframe guide, last updated September 23, 2024, cites Chrome's research on Data Saver users: lazy-loading offscreen iframes could bring 2 to 3 percent median data savings and 1 to 2 percent cuts to First Contentful Paint at the median. If a video matters for search, our video indexing guide lists a lazy-loaded embed as one of four video indexing failures.
What about carousels, hidden images and infinite scroll?
A hidden lazy image may never load: web.dev says Chrome, Safari and Firefox skip images hidden with display set to none, while images with an opacity of zero still load. CSS background images cannot use the loading attribute at all. For infinite scroll, Google asks for each chunk of the feed to have its own lasting URL.
Google's image guide says, "Google doesn't index CSS images." Our take: if an image matters for Google Images, put it in a real image element with its URL in the src attribute. For infinite scroll, Google asks for a page number such as page 12 in the URL, and for the History API to update the shown URL, and our pagination guide covers the URL design.
What does WordPress do by default?
WordPress core handles lazy loading and priority on its own. As of WordPress 6.3, it leaves the lazy setting off the image it judges most likely to be the LCP image and gives that image fetch priority set to high, which the WordPress core notes say typically improves LCP by 5 to 10 percent. Images lower on the page get the lazy setting.
Those notes also say the work on leaving the lazy setting off started in WordPress 5.9 and ended in WordPress 6.3, when the number of top images kept eager rose from 1 to 3, to better fit multi-column layouts. By default, WordPress gives high priority only to images over 50,000 square pixels: 300 by 200 qualifies, and 200 by 200 does not. Our WordPress defaults guide covers the other settings worth changing, and our Webflow guide covers that platform's default.
How does this play out on store and blog pages?
The rule stays the same on every site: eager at the top, lazy below. What changes is where the top ends, and a product grid, a long travel post and a tall product page each draw that line in a different place. These three examples are invented to show the pattern.
- For example, an Austin, Texas furniture store in the United States has a category page with 48 product photos: the first row stays eager, the rest load late, and every photo has width and height set.
- For example, a travel blog in Munich, Germany, written in German and English for readers across Europe, puts maps and videos far down each post. Those embeds take the lazy setting, and the cover photo stays eager. Our travel SEO guide covers destination guides and seasonal timing.
- For example, a Seoul cosmetics store in South Korea has a product page with a tall stack of detail images below the main photo. The main photo stays eager with high priority, and the stack loads late. If Naver matters to you too, our Naver guide covers Korean search.
How do you test lazy loading in Search Console?
Open the URL Inspection tool in Search Console and read the rendered HTML. Google says that if your image or video URLs appear in the src attribute on the image or video elements there, your setup works. Then run Lighthouse and check its "Defer offscreen images" audit for images that should load late.
Our take: test one URL per template, not every page. Our Search Console guide covers the tool in depth, and our technical SEO audit guide covers the wider check.
To fix lazy loading on your site, start with the template that sets every image to lazy, and take the lazy setting off the first screen. Give the main image fetch priority set to high, and add width and height to every image. Then inspect one URL per template in URL Inspection, and confirm each real image URL sits in the src attribute.
Frequently asked questions
Does lazy loading work without JavaScript?
Partly: web.dev says images using the loading attribute still load when a visitor turns JavaScript off, but the delay itself only happens with JavaScript on. MDN's image reference calls this "an anti-tracking measure." Without it, a site could follow how far a person scrolls by watching which images get requested, and when. Our view: this changes little for SEO, because Google's own test is the rendered HTML in URL Inspection. Just do not build a feature that depends on the delay being active for every visitor.
Can I change how early lazy images start to load?
Not with the browser attribute: web.dev says the distance values are hardcoded and cannot be changed, though browsers may adjust them over time. The same page cites experiments in Chrome on Android: on 4G, 97.5 percent of lazy-loaded images were fully loaded within 10 milliseconds of becoming visible, and 92.6 percent on slow 2G. Our view: for a typical page, the default distance is good enough, and a custom trigger is rarely worth the extra script you would need to load and maintain.
Will deferred images hurt my Google Images traffic?
Not if Google can find them: Google's image guide says Google finds images in the src attribute of the image element. Google's lazy content page adds that a setup works when image URLs appear in that attribute in the rendered HTML. Trouble starts when a script keeps the real URL out of the src attribute until a scroll, or when the image is a CSS background. Our view: check one image-heavy page in URL Inspection before you worry about traffic numbers.
Should the logo in my header be lazy-loaded?
No: a header logo usually sits in the first screen, and web.dev warns against deferring images that are likely to be in view when the page loads. Google gives the same advice for content likely to be seen as soon as a page opens. Our view: a logo is small, the saving from deferring it is tiny, and the delay is easy to notice. A theme that marks the logo lazy is applying a blanket rule, and that is the habit worth breaking first.
Do older browsers break when they see the loading attribute?
No: web.dev says browsers that do not support the loading attribute simply ignore it. Those visitors miss the data savings, but there is no negative impact from including it. That makes the attribute a safe default for images far down the page. web.dev names a fallback for old browsers as one reason some sites still keep a script library on top of the attribute. Our view: for a typical business site in 2026, that fallback is rarely worth the extra code and upkeep.
Do lazy images load when someone prints the page?
Yes: web.dev says all images and iframes load right away when a page is printed, whatever their loading setting. A reader who prints a long recipe or a product spec sheet still gets every photo on paper. This matters little for search, but it is a fair answer to anyone worried that deferral breaks printing. Our view: if your team prints pages for sales calls or trade shows, test one print preview after you change the lazy setting, just to be sure.
Does the lazy setting affect ads on my page?
Yes, in the same way it affects everything else: web.dev says ads shown as images or iframes lazy-load just like any other image or iframe. An ad slot far down the page will wait until the reader scrolls near it. web.dev's iframe guide adds that lazy-loading ad iframes can bring benefits like those for media embeds. Our view: keep any ad that sits in the first screen eager, and check with your ad partner before you change how their slots load.
Why does a speed report flag my main image?
If a speed report says the main image was lazy-loaded, the lazy setting sits on an image in view as the page opens. web.dev warns against lazy loading images likely to be in view at load, especially LCP images. Lighthouse's "Defer offscreen images" audit points the other way, at images below the screen that could load late. Our view: read which warning fired before you change a single template, because one means remove the lazy setting from that image, and the other means add it.
Should images in an image sitemap be lazy-loaded?
They can be, if they sit below the first screen. Google's image guide says an image sitemap can list images Google might not otherwise find. Google's lazy content page, for its part, says a setup works when image URLs appear in the src attribute in the rendered HTML. Our view: the sitemap helps discovery, but it is a backup, not a fix for a broken page. Our XML sitemaps guide covers when an image sitemap helps and what belongs in a sitemap.
Is the eager value the same as fetch priority?
No: web.dev says the eager value only tells the browser to load an image as usual, without extra delay. It does not make the image load faster than one with no loading attribute. Fetch priority set to high is a separate signal that moves an important image up the queue. WordPress 6.3 adds it on its own to the image it judges most likely to be the main one. Our view: leave eager as the default, and save high priority for one image per page.