Images make up about 45 percent of a typical desktop page, so lazy loading images can help. In HTTP Archive data, the median desktop page weighs about 1511 KB, and about 650 KB of that is images.
Lazy loading images means the browser delays downloads of pictures a visitor cannot see yet. The browser waits until the visitor scrolls near each picture before it fetches it.
The viewport is the part of a web page a visitor can see in the browser window at any moment. Page speed issues make visitors leave before they reach the products or offers. A slow page hurts user experience, and every lost visitor can mean a lost business customer.
This technique is simple, but it can backfire when it is used on the wrong images. The steps below show how to add it to a page and where it can hurt.
Key Takeaways
- The technique waits to download a picture until the visitor scrolls near it.
- Images are often the heaviest part of a page, so they are the first place to save time.
- Images at the top of a page should load right away.
- Slow pages lose visitors before they see products or offers.
- Test the same page before and after the change to see the real effect.
Why Images Slow Down Most Pages
A visitor opens a bakery website on a phone. The hero section, the large banner at the top, stays blank while the page loads. The browser is busy downloading photos further down the page.
Image weight is often the main reason. Images are usually the largest files on a page, and the browser must fetch each one over the network.
Images are usually the heaviest part of a page, so they are the first place to save bytes. Many mobile plans limit data, and every extra kilobyte counts against that limit.
Images are usually the heaviest part of a page, so they are the first place to save bytes.
https://www.youtube.com/watch?v=qQiGnLvs3nk
Picture a product page with six large photos below the fold. A page that loads all six at once uses bandwidth the text and scripts need first. A page that loads only the photos on screen sends the text sooner.
Page load time grows with every photo that competes for the same connection. Each photo also needs its own request and reply, so a long list of images adds delay even on fast links.
The Web Almanac by HTTP Archive tracks page weight across millions of websites. Its 2025 chapter found that images were the largest resource type on the median home page. That was about 911 KB on mobile and 1,058 KB on desktop.
Slow pages also cost sales. A guide to conversion rate work says 53 percent of mobile users leave a site that takes longer than three seconds to load.
The opposite of lazy loading is eager loading, which is how browsers handle images by default. Knowing that default shows what the change really does.
How the Loading Attribute Works in Browsers
Adding loading=”lazy” to an img tag is the whole change. The browser reads that one attribute and waits to download the image until it nears the screen.
Current versions of Chrome, Firefox, Safari and Edge support the attribute. Browsers without support ignore it and load every image normally.
Setting loading=”lazy” on an image tag
The lazy loading images html change takes one line of code. Here is a photo of a garden bench that sits below the fold:
<img src=”garden-bench.jpg” alt=”A wooden garden bench” loading=”lazy”>
Place the attribute only on images that sit low on the page. Leave the rest of the tag as it was.
Values for the loading attribute
The attribute takes three values, and a missing attribute works like one of them. Each value tells the browser when to fetch the image.
- lazy: the browser waits and fetches the image as it nears the viewport.
- eager: the browser fetches the image right away, wherever it sits on the page.
- auto: the browser picks the timing for the image.
- Browser default: a missing attribute means the image loads eagerly, which is the default behavior.
Picking a value is a choice about timing, not about how the image looks. Eager loading is the safe choice for any image the visitor sees at once.
How far the image sits from the screen decides when the download begins, and that distance is the next question.
When the Browser Starts Loading an Image
The browser starts fetching a lazy image before it reaches the screen. The exact point depends on how far the image sits from the visible area and on the connection speed.
Lazy loading how it works comes down to distance from viewport, which is measured in pixels. A pixel is one dot on the screen, so 1250px means 1250 dots away from the visible area.
Chromium, the open source engine behind Chrome, lowered its thresholds in July 2020. The table shows the old and new distances.
| Connection type | Old threshold | New threshold | Effect |
|---|---|---|---|
| Fast 4G | 3000px | 1250px | Downloads start closer to the screen |
| Slower 3G | 4000px | 2500px | Downloads still start early, because slow links need more time |
The threshold also depends on the image type and the effective connection type the browser detects. Developers cannot set these thresholds through an API, so the browser decides them.
Pictures far below the screen wait, while pictures close to it start early. That split is what saves data on a long page.
That raises a fair question: is lazy loading or eager loading better for a given image?
Which Images Should Stay Eager
A banner across the top of a homepage should never wait for a scroll. Above the fold images are the ones a visitor sees before scrolling, so they should load right away.
The viewport decides which images count as above the fold. Any image inside the first view belongs in the eager group.
Above-the-fold and LCP images
Largest contentful paint (LCP) is the render time of the main content. Adding loading=”lazy” to a hero image delays that render, so keep the hero tag plain.
<img src=”hero-banner.jpg” alt=”A bakery counter with fresh bread”>
For product photos lower on the page, the lazy loading example is simple: add loading=”lazy” to each one.
<img src=”bread-loaf.jpg” alt=”A sourdough loaf on a wooden board” loading=”lazy”>
Images with fetchpriority
The fetchpriority attribute raises the priority of an important image. Set fetchpriority=”high” on the hero image, and leave loading out of that tag.
<img src=”hero-banner.jpg” alt=”A bakery counter with fresh bread” fetchpriority=”high”>
Lazy loading in carousels and hidden images
The browser skips images with display:none, but it loads images with opacity:0. Those images look invisible, yet they still use bandwidth.
Chrome 121 changed how horizontal carousels load, so lazy images inside them now start loading earlier than before. Missing size settings cause another problem, and fixing them is the next step.
Setting Width and Height to Prevent Layout Shift
A lazy image without dimensions makes the page jump when it arrives. Cumulative layout shift (CLS) is the measure of that unexpected movement on a page.
Without width and height, an image takes 0 by 0 pixels until it downloads, so a gallery can load every picture at once. Image dimensions reserve the space before the download starts.
Width and height attributes on img tags
Add the dimensions as attributes on the tag, using the photo’s real pixel size.
<img src=”ceramic-mug.jpg” alt=”A blue ceramic mug” width=”600″ height=”400″ loading=”lazy”>
Work through these steps for each lazy image:
- Add width, using the photo’s pixel width.
- Add height, using the photo’s pixel height.
- Use inline style when the layout needs a fixed size.
- Check the picture fallback.
- Test the gallery in a narrow window.
Inline style alternative
Inline style works when the page needs a fixed box, as in style=”width:600px;height:400px;”. Use it only when the attributes cannot hold the size.
Galleries that load everything at once
A picture element can offer a modern format with a plain img fallback. The fallback img takes the loading attribute and the dimensions.
<picture><source srcset=”mug.webp” type=”image/webp”><img src=”mug.jpg” alt=”A blue ceramic mug” width=”600″ height=”400″ loading=”lazy”></picture>
In a gallery, unsized images can all fit the viewport at once, so the browser fetches every one. Setting sizes lets each image wait for its turn. Next comes the lazy loading images javascript fallback for browsers that lack native support.
Using JavaScript for Older Browsers and Background Images
A script can stand in for the attribute in older browsers. The lazy loading images javascript approach watches each image and loads it when it nears the viewport.
Three methods are common, and each one trades effort for control. The table compares them.
| Method | Support | Trade-off |
|---|---|---|
| Native loading attribute | Current Chrome, Firefox, Safari and Edge | Least code, but the browser sets the trigger point |
| Intersection Observer | Modern browsers, with a fallback for older ones | More code, but the script sets the trigger point |
| Scroll event listeners | Nearly all browsers | Most code, and the script checks position on every scroll |
A JavaScript library is only needed as a fallback for browsers that lack support. Many sites need only a few lines of script for this.
Intersection Observer approach
The Intersection Observer API reports when an element enters the viewport. A script creates an observer, watches each img, and sets its src when the element appears.
Sites built to order often need this kind of script, and a custom web development team can write it. Once an image loads, the script stops watching it, so no work repeats.
Lazy loading CSS background images
The loading attribute does not work on CSS background images. A script can fix that by storing the image address in a data attribute and setting the background-image style when the element enters the viewport.
A visitor who waits for a background image sees an empty box, and placeholders solve that problem.
Designing Placeholders That Keep Visitors Engaged
A visitor scrolls quickly through a product grid on a phone. Each photo area would sit blank without a placeholder. An image placeholder fills that space until the picture arrives.
A solid grey box is the simplest choice, and it adds no extra bytes. A dominant color placeholder uses the photo’s main color, and it can be a single pixel scaled up.
A low quality image placeholder (LQIP) is a small blurred version of the photo. A blurred version gives the visitor a sense of the image, such as whether a shirt is blue or red.
Match the placeholder to the image size. A box that is shorter or narrower than the photo makes the page jump when the photo appears.
Designers who map user flows, as some web design firms do, treat placeholders as part of the interface. Hiding the wait does not save any data, and some visitors pay for every byte they download.
Trade-offs for Offline Reading and Bandwidth Limits
A reader on a train opens a long article with no signal. Lazy loaded images are missing for offline readers, since the browser never fetched them.
Those gaps can make a how-to guide hard to follow. Long articles show this problem most clearly, because readers save them for later.
Removing the attribute after the first load
Some sites remove the attribute about 5 seconds after the page loads. The images then download in the background, and the first render stays fast.
A short script can do this with a timer and a loop over the image tags.
Measuring the effect on the performance score
A performance score can drop even when the first render gets faster. Extra downloads after the first render can count against the score in some tests.
Check the first render and the score together. Do not judge the change by one number.
Balancing bandwidth against visitor experience
Visitors on limited mobile plans may prefer not to download images they never see. A page can lazy load only its large photos and leave small icons eager.
Site owners who want help with that balance can read client testimonials from 11thagency. They describe design and usability work for businesses.
Measuring the result with testing tools shows whether the trade-off pays off.
Measuring the Effect with Page Speed Tools
Run a before and after test on the same page. Use the same test settings each time, or the numbers will not match.
Test one page before and after the change, using the same tool and settings. Lighthouse 6.0 and higher accept lazy loading that uses different thresholds when passing the defer offscreen images audit.
Test one page before and after the change, using the same tool and settings.
Watch four measures in each report.
- Largest contentful paint (LCP): the render time of the main content.
- Cumulative layout shift (CLS): the measure of unexpected movement.
- Page weight: the total bytes the page downloads.
- Defer offscreen images audit: whether the page defers images that sit off screen.
Lab tests run on one machine, so real user data adds value. Core Web Vitals scores from field data show how real visitors experience the page on phones and slow networks.
Better numbers help with page speed issues that cost sales. A guide to search engine optimized websites explains why visibility matters too.
The numbers show whether the change works, and the next question is what they mean for sales.
Conclusion
Lazy loading is a small change with a visible effect. It suits images below the fold, and eager loading suits the top of the page.
A slow page loses customers before they see the offer. Faster pages keep the visitor long enough to read a product name or a price.
The next step is simple. Pick one page with several photos below the fold, add loading=”lazy” to those images, and measure largest contentful paint and page weight before and after.
