{{text}}
Share
Lazy loading images is a setting that tells the browser to download an image only when it approaches the screen, instead of loading it with the rest of the page. In HTML it fits in one attribute: loading="lazy". Used well, it lightens long pages. Used badly, it delays the main content and damages the metric Google actually looks at. Here is the rule for deciding, and the cases where you should not use it at all.
The rule in one sentence
Defer generously everything far from the screen, never what is visible on open. That is the conclusion of the web.dev study published by Felix Arntz and Rick Viscomi on 31 March 2022, and it has not changed since. Their measurement on HTTP Archive data is the one thing to remember if you read nothing else: the median LCP of pages using lazy loading was 3,546 ms, against 2,922 ms for pages that do not use it. That is 621 ms of delay, on pages meant to be faster.
The cause is short to explain. Lazy loading does not sort your images for you. Applied without judgement, it also hits the image filling the first screen, the one that triggers Largest Contentful Paint. The browser then has to know where the image sits before deciding to download it, which adds a round trip where none was needed.
How many sites shoot themselves in the foot
The 2025 Web Almanac from HTTP Archive puts a number on it. Between 16 and 17% of pages lazy-load their own LCP image. In detail, 10.4% of mobile pages and 11.5% of desktop pages set the native attribute on that element, and 5.9% of mobile pages use a custom data-src approach.
The same report explains why images concentrate the problem: 85.3% of desktop pages and 76% of mobile pages have an image as their LCP element. On most sites, perceived speed comes down to a single visual, and one page in six deliberately makes it wait.
Meanwhile the attribute meant to speed that image up stays underused: fetchpriority="high" appears on only 16.3% of desktop pages and 17.3% of mobile pages, up two points from 2024.
What the loading attribute actually does
It takes two values. lazy defers the download until the resource reaches a calculated distance from the viewport. eager is the browser default: the image is fetched immediately, wherever it sits.
The trigger distance is not the fold, contrary to what is often written. Chrome anticipates: roughly 1,250 px on 4G, roughly 2,500 px on 3G or slower. The browser therefore starts the download well before the image enters the screen, which is why the visible gain is often smaller than expected on a short page.
On browser support, the web.dev documentation updated on 13 August 2024 lists Chrome 77 and above, Edge 79, Firefox 75 and Safari 15.4. Compatibility is a closed subject. There is no longer a reason to load a JavaScript library for this job.
Two limits worth knowing. The attribute only works on img and iframe tags, so a background image declared in CSS escapes it entirely. And you have to set width and height on every image, otherwise the browser reserves no space and the page jumps when the image lands, which degrades Cumulative Layout Shift.
Which images to defer, which to load immediately
The decision is made image by image, looking at the page at phone width rather than on a wide screen. Here is the grid we apply in audits.
| Image | Setting | Why |
|---|---|---|
| Main visual in the first screen | loading="eager" plus fetchpriority="high" | It is almost always the LCP element. Deferring it delays the very metric you are measured on. |
| Logo and header icons | loading="eager" | Visible on open, negligible weight, nothing to gain from deferring them. |
| Second-screen visuals | eager if the content moves up on mobile | A visual below the fold on desktop often sits above it on a phone. |
| In-article illustrations | loading="lazy" | The ideal case: far from the viewport, and often never reached by part of your visitors. |
| Galleries and carousels past the first view | loading="lazy" | Real bandwidth savings, no effect on LCP. |
| Paginated CMS grids | lazy, except the first two or three thumbnails | The first thumbnails can be the LCP element on a listing page. |
| CSS background images | the attribute does not apply | The loading attribute only works on img tags. These need a different fix. |
The most common trap is the third row. A visual placed to the right of a text block on desktop ends up stacked under that text on mobile, or the other way round. The correct desktop setting becomes the wrong mobile setting, and it is the mobile version that counts in the measurement.
What Google asks for on the indexing side
Google Search Central's documentation on lazy-loaded content, updated on 10 December 2025, sets one substantive requirement: your implementation must load all relevant content whenever it is visible in the viewport. Google explicitly recognises three methods, browser-level lazy loading, the IntersectionObserver API, and libraries that load content entering the viewport.
The constraint that breaks custom implementations fits in one sentence: Google Search does not interact with the page, it neither scrolls nor clicks. Loading triggered by a user action, a "load more" button or a real scroll, will never be reached by the crawler.
To check, Google points to the URL Inspection tool in Search Console: read the rendered HTML and confirm that image URLs appear in the src attribute of img tags. It is a three-minute check, to be run once per page template rather than once per page. It belongs in any serious technical SEO audit.
One useful point on infinite scroll: Google asks for a unique, stable URL per chunk of content, with an absolute page number such as ?page=12, and sequential links between those URLs. A page that stacks results without ever changing its URL exposes a single document to indexing.
The Webflow case
Webflow has applied deferred loading by default to every new image since an update published on 27 August 2020. That switch did not affect images already in place on existing sites, and the setting is changed image by image in the settings panel.
The practical consequence on a Webflow project is counter-intuitive: the work is not to turn lazy loading on, it is already on. The work is to turn it off on the first-screen visual of every page template. On a CMS site that means the article template, the listing template, the home page and the service pages. Five to ten fixes, no more, for a gain you can read straight off PageSpeed Insights.
The setting does not cover background images set in styles. On a site built around background visuals, the trade-off moves to file weight and format, a subject covered in our guide to images and SEO and in our Webflow SEO optimisation steps.
What it changes on a real project
For Les Fermes de Marie, a luxury hotel group in Megève, we ran an SEO audit that led to more than 50 technical fixes. On that kind of site, where the visual carries the commercial promise, image loading is not a developer detail. It is what separates a home page that renders before the visitor gives up from one that renders after. Synqro is a Webflow Premium Partner agency in Paris, and this check is part of our standard delivery.
The four recurring mistakes
Deferring everything on principle. The most frequent case, and the one the Web Almanac measures. Lazy loading is not an optimisation you add, it is a trade-off you make.
Forgetting width and height. The weight saving is real, CLS gets worse, the net result is negative. Those two attributes cost ten seconds per image.
Stacking a JavaScript library on top of the native attribute. The two mechanisms get in each other's way, and the script adds main-thread work. Since Safari 15.4, native is enough.
Tuning on desktop and never checking on mobile. The first mobile screen almost always holds more images, relative to its height, than the first desktop screen.
How to verify, in three steps
Run PageSpeed Insights on the page and note which element is named as LCP. Open that element's markup and confirm it does not carry loading="lazy". If Lighthouse flags the lazy-loaded LCP image audit, you have your answer without looking further.
Then run the URL through Search Console's inspection tool and read the rendered HTML: every body image must have a real src. Finally, repeat the test at phone width, because that is the version Google indexes.
For reference, the Core Web Vitals thresholds at the 75th percentile, as defined by the Chrome team and updated on 7 May 2025: LCP good up to 2,500 ms, needs improvement between 2,500 and 4,000 ms, poor beyond. INP good up to 200 ms. CLS good up to 0.1.
FAQ
Does lazy loading hurt SEO?
No, as long as the image ends up in the rendered HTML. Google documents the methods it can follow, the native attribute and the IntersectionObserver API, and states that Search does not interact with the page: it neither scrolls nor clicks. An image that only appears after a real scroll will never be seen.
Do I still need a noscript tag around lazy-loaded images?
That was the advice back when lazy loading relied entirely on custom JavaScript. With the native attribute, the image stays an img tag with its src in the HTML, so there is nothing to recover. The recommendation still circulates, but it no longer has a purpose.
How do I find out which image is my LCP?
PageSpeed Insights and the Performance tab in Chrome DevTools both name the LCP element. Lighthouse adds a dedicated audit when that element carries loading="lazy". It is the cheapest check you can run before shipping.
Does the attribute work on CSS background images?
No. It only applies to img and iframe tags. For a background image you either move it to an img tag, load it conditionally, or accept that it ships with the stylesheet.
Does lazy loading improve Core Web Vitals?
It reduces transferred bytes and can help indirectly. On LCP the effect turns negative as soon as it touches the main image. On CLS it is neutral when dimensions are set, and harmful when they are not.
Should I lazy-load everything except the first image?
That is a decent approximation on desktop and a poor one on mobile. On a phone the first screen often shows two or three visuals. The right reflex is to look at the page at mobile width and eager-load everything visible without scrolling.
Does Webflow handle lazy loading on its own?
Webflow has applied deferred loading by default to new images since August 2020, and the setting is changed image by image in the settings panel. So the default is something to correct on first-screen visuals, not something to leave alone.
How much time can I expect to save?
No general figure is reliable, it depends on image weight and network conditions. What is documented is the opposite: across the HTTP Archive sample, the median LCP of pages using lazy loading was worse than that of pages not using it.
Going further
Image loading is one of the few jobs where half a day of work shows up directly in the measurement. If you want this check done on your site and built into your page templates rather than redone at every publish, our Webflow SEO agency takes it on, and our Webflow expert team works directly in the Designer. Let's talk about your project.
Synqro's latest achievement
