What Lazy Loading Actually Does
Lazy loading tells the browser to only load content when a visitor is about to see it, rather than loading everything the moment they arrive. If your page has 40 images but only 3 are visible without scrolling, lazy loading means the browser fetches those 3 first and waits on the other 37 until the visitor scrolls down toward them. The result is a page that appears and becomes usable much faster, because the browser isn’t wasting time and bandwidth on content nobody has looked at yet.
That’s genuinely it. No algorithms, no complex engineering philosophy. It’s the digital equivalent of a restaurant not cooking every menu item the moment they open. They prepare what’s been ordered, and they start on the next dish when the next order comes in.
Where this matters for your business is speed, search rankings, and conversions. A product page with 25 high-resolution images can weigh 8-12MB if everything loads at once. With lazy loading, the initial page weight might drop to 1-2MB because only the hero image and a couple of thumbnails load upfront. That difference is the gap between a page that loads in 1.5 seconds and one that takes 7 seconds, and every extra second costs you visitors who simply leave.
The Problem Lazy Loading Solves
To understand why lazy loading exists, you need to understand how browsers normally work. When someone visits your page, the browser reads through your HTML code from top to bottom and starts fetching every resource it finds: images, videos, fonts, scripts, stylesheets. It does this eagerly, as if every single element is critical to showing the page.
For a simple page with a heading, two paragraphs, and one photo, this works fine. But modern business websites aren’t simple. A typical services page might include a hero image, team photos, client logos, case study thumbnails, an embedded video, background images in various sections, and decorative icons. The browser tries to load all of this simultaneously, which creates a traffic jam. Your visitor’s connection has finite bandwidth, and when 40 assets are fighting for it at the same time, everything slows down.
The visible part of the page, the section you see before scrolling (often called “above the fold”), gets delayed because the browser is also busy fetching an image in a testimonials section the visitor hasn’t reached yet. It’s like trying to carry every shopping bag from your car in one trip when you could make two easy ones and actually get through the door faster.
What we see on most mid-market sites is that 60-80% of images on any given page are below the fold. That means the majority of what the browser is loading on arrival is content the visitor hasn’t asked for and may never see. If someone bounces after reading only your hero section, all those resources loaded for nothing, wasting your server resources and the visitor’s data.
What Can Be Lazy Loaded
Most people think of lazy loading as an image thing, and images are the most common use case. But the concept applies to several types of content.
Images
Images are the biggest payload on most websites, typically accounting for 50-70% of total page weight. They’re also the easiest to lazy load because modern browsers support it natively. A developer simply adds loading="lazy" to an image tag, and the browser handles the rest. No special library, no complex setup. This native approach works in Chrome, Firefox, Edge, and Safari, covering well over 95% of your visitors.
Videos and Embeds
An embedded YouTube video doesn’t just load a video player. It pulls in roughly 500-800KB of scripts, stylesheets, and thumbnail data the moment it appears in your code. If you have a customer testimonial video halfway down a page, that’s almost a megabyte of resources loading before anyone has scrolled to it. Lazy loading video embeds means displaying a static thumbnail image with a play button, then loading the actual video player only when someone clicks to watch. This single change can shave a full second off your page load time.
Iframes
If your site embeds maps, social media feeds, booking widgets, or third-party tools using iframes, each one pulls in external resources as soon as the page loads. A Google Maps embed, for instance, loads around 600KB of assets. Lazy loading iframes is supported natively in the same way as images, and it’s one of the fastest wins available when your page includes embedded third-party content.
Below-the-Fold Sections
Some more advanced implementations lazy load entire sections of the page, including their background images, scripts, and interactive elements. This is less common and typically requires a developer to implement with JavaScript, but for very long pages (think resource hubs or product catalogues), it can make a substantial difference.
How Lazy Loading Affects Your Core Web Vitals
Google measures your website’s user experience through three Core Web Vitals metrics, and lazy loading directly influences two of them.
Largest Contentful Paint (LCP) measures how quickly the main content of your page becomes visible. This is where lazy loading has a dual nature. When applied correctly, it speeds up LCP because the browser can focus its resources on loading the hero image or main content element without competing requests from below-the-fold images. When applied incorrectly (more on this shortly), it actually harms LCP because the browser delays loading the very image that determines this score.
Interaction to Next Paint (INP), which measures how responsive your page feels when someone clicks or taps something, benefits indirectly. Fewer resources loading simultaneously means the browser’s main thread is less congested, so it can respond to user interactions more quickly. We’ve seen pages where INP improved by 40-60ms purely from reducing the initial resource load through lazy loading, which can be the difference between a “needs improvement” and “good” rating.
Cumulative Layout Shift (CLS) measures visual stability, and this is where lazy loading can cause problems if implemented carelessly. When a lazy-loaded image finally loads, it needs space on the page. If that space wasn’t reserved in advance, the content below it jumps downward. This shifting is frustrating for users and penalised by Google. The fix is straightforward: always define the width and height of images in your HTML so the browser reserves the correct space before the image arrives. Your developer might call this “specifying aspect ratios” or “using dimension attributes.”
The Mistakes That Make Lazy Loading Backfire
Lazy loading is not a switch you flip and forget. Implemented poorly, it creates worse problems than it solves. These are the mistakes we encounter most frequently when auditing sites.
Lazy Loading the Hero Image
This is the single most common error, and it’s remarkably easy to make. Many WordPress plugins and theme frameworks apply lazy loading to every image on the page by default. That includes the large hero image or banner at the top of your page, the one that visitors see first and that Google uses to calculate your LCP score.
When you lazy load your hero image, you’re telling the browser to wait before loading the most important visual element on the page. The browser has to first load the HTML, then parse it, then notice the image is approaching the viewport, and only then start fetching it. This adds 200-500ms of unnecessary delay to your LCP, which directly harms your Core Web Vitals score.
The fix: explicitly exclude above-the-fold images from lazy loading. In WordPress, most performance plugins let you exclude images by position (first image on page) or by CSS class. Your hero image, main product image, and any logos or images visible without scrolling should load eagerly.
Not Reserving Space for Images
As mentioned in the CLS section, if your images don’t have defined dimensions, the page reflows every time a lazy-loaded image appears. On a long page with 20 lazy-loaded images, a visitor scrolling down experiences 20 small layout shifts. Each one feels like the page is broken. Always set explicit width and height attributes on every image, or use CSS aspect-ratio properties. This lets the browser create placeholder space of the correct size, and the image fills that space smoothly when it loads.
Using JavaScript Libraries When Native Loading Works
Before browsers supported native lazy loading, developers had to use JavaScript libraries to achieve the same effect. Some of these libraries are still in circulation, and some themes and plugins still load them. The irony is that you’re loading an extra 10-20KB JavaScript file to reduce page weight, and that JavaScript has to run on the main thread to observe scroll positions, which can actually make the page less responsive. Native browser lazy loading requires zero JavaScript. If your site is still using a library like lazysizes or lozad for basic image lazy loading, it’s worth checking whether you can switch to the native approach.
Setting the Loading Threshold Too Aggressively
Some implementations wait until an image is almost on screen before loading it. This sounds efficient, but on fast-scrolling visitors (especially on mobile), it means images appear as blank spaces that then pop in visibly. The experience feels janky and unfinished. Browsers handle this sensibly with native lazy loading, starting to fetch images when they’re roughly 1250 pixels below the viewport on fast connections and earlier on slow ones. If you’re using a custom implementation, make sure there’s a generous threshold so images have time to load before they become visible.
How to Check If Lazy Loading Is Working on Your Site
You don’t need developer tools to do a basic check. Here’s a practical approach anyone can follow.
Open your website in Chrome, right-click anywhere on the page, and select “Inspect.” Click the “Network” tab at the top of the panel that opens, then click “Img” to filter for images only. Now reload the page and watch the list of images that appear. If lazy loading is working, you should see only the images visible in the initial viewport. Then slowly scroll down the page and watch new images appear in the network list as you approach them. If all 40 images load immediately on page load, lazy loading either isn’t enabled or isn’t working correctly.
For a more thorough assessment, run your page through Google’s PageSpeed Insights. If lazy loading is missing or misconfigured, you’ll typically see opportunities labelled “Defer offscreen images” in the results. This recommendation literally means “you should lazy load images that aren’t visible on arrival.”
You can also check your LCP element. In PageSpeed Insights, scroll to the Diagnostics section and look for the LCP element. If it’s an image, check whether that image has loading="lazy" applied. If it does, that’s the hero image mistake described above, and fixing it is often worth 0.3-1.0 seconds of LCP improvement on its own.
Lazy Loading in WordPress, Shopify, and Other Platforms
Since WordPress 5.5, the platform adds native lazy loading to images automatically. WordPress 5.9 went further by excluding the first image in content from lazy loading, addressing the hero image problem. However, this automatic behaviour doesn’t always get it right. If your hero image is added through a theme’s custom header function rather than standard content, WordPress may not recognise it as “first” and may lazy load it anyway.
Most WordPress performance plugins (WP Rocket, Perfmatters, FlyingPress, and similar tools) offer lazy loading controls that go beyond the defaults. They typically let you lazy load iframes and videos, exclude specific images by class or filename, add placeholder effects while images load, and handle background images added via CSS. If you’re running WordPress and care about performance, reviewing these settings is worthwhile. But plugin settings alone won’t save a site that was architected without performance in mind, which is why we cover the broader planning process in our performance architecture guide.
Shopify handles lazy loading differently depending on your theme. Newer themes built for Online Store 2.0 generally include native lazy loading, but older themes may not. Shopify’s Liquid templating language lets developers add loading attributes to images, but if your theme wasn’t built with performance in mind, you may need a developer to retrofit this.
For custom-built sites using frameworks like Next.js or Nuxt, lazy loading is typically built into the image component provided by the framework. Next.js’s Image component, for example, lazy loads by default and includes automatic placeholder generation. The challenge on custom-built sites isn’t usually enabling lazy loading but ensuring it’s configured correctly for each page template.
Lazy Loading and SEO: What Google Actually Sees
A reasonable concern from marketing teams is whether lazy-loaded images still get indexed by Google. The short answer is yes, Google can see and index lazy-loaded images, provided you’re using either native browser lazy loading or a JavaScript implementation that Google’s renderer can execute. Googlebot renders pages using a modern Chromium-based browser, so it processes JavaScript and native loading attributes the same way a real visitor’s browser would.
That said, there are edge cases. If your lazy loading implementation requires a scroll event to trigger (and some older JavaScript approaches do), Googlebot may not scroll far enough to trigger all images. Native lazy loading doesn’t have this problem because the browser decides when to load based on viewport proximity, and Googlebot handles this properly during rendering.
For image-heavy sites where image search traffic matters (think e-commerce, portfolio sites, or property listings), make sure your images have proper alt text regardless of how they’re loaded. Lazy loading doesn’t affect whether Google reads alt text, but it’s worth confirming that your implementation doesn’t strip or modify image attributes during the lazy loading process. Some poorly coded plugins have been known to rewrite image tags in ways that lose metadata.
How Much Difference Does Lazy Loading Actually Make?
The impact depends entirely on the page. A text-heavy blog post with two images won’t see dramatic improvement. A product category page with 60 thumbnails will see a transformative difference.
Here are realistic numbers from projects our team has worked on. A B2B services company with long, image-rich case study pages saw their average page weight drop from 6.2MB to 1.8MB on initial load after implementing lazy loading properly. LCP improved from 4.1 seconds to 2.3 seconds. An e-commerce client with product listing pages containing 48 thumbnails each saw initial page weight go from 9.4MB to 1.1MB, with LCP improving from 5.7 seconds to 1.9 seconds.
These numbers aren’t unusual for sites where lazy loading was either missing or poorly configured. The key phrase is “on initial load.” The total page weight doesn’t change; you’re simply deferring when resources are requested, so the browser can prioritise what matters first.
Where the impact is most noticeable for business metrics is on mobile devices with slower connections. A visitor on a 4G connection loading a 6MB page might wait 8-10 seconds. The same visitor loading a 1.5MB initial payload (with the rest lazy loaded) gets a usable page in 2-3 seconds. That’s the difference between a bounce and a lead form submission.
Lazy Loading Is One Piece of a Bigger Picture
It’s tempting to treat lazy loading as a silver bullet for page speed. It isn’t. A site with uncompressed 4MB hero images, three chat widgets, a tag manager firing 15 tracking scripts, and an unoptimised web font stack will still be slow even with perfect lazy loading. Lazy loading optimises when resources load, not how large or numerous those resources are.
The real performance gains come from combining lazy loading with properly sized and compressed images, efficient hosting and CDN delivery, minimal third-party scripts, modern image formats like WebP or AVIF, and correct resource prioritisation. Think of lazy loading as one instrument in an orchestra. It plays an important part, but the performance only sounds right when everything works together.
If your site currently has no lazy loading, adding it is the fastest, lowest-risk performance improvement you can make. It typically takes a developer less than an hour to implement and verify, the risk of breaking something is minimal (as long as you don’t lazy load above-the-fold content), and the results are immediate and measurable. Start there, confirm it’s working correctly, and then address the other layers of your performance stack. The order matters: fix the quick wins first, then tackle the architectural decisions that require more planning and investment.
