Most of the images on your homepage load before a single visitor scrolls past the fold. That is wasted bandwidth, wasted time, and a lower PageSpeed score — for no reason. Lazy loading fixes this by deferring images and other resources until the browser actually needs them.
What Lazy Loading Does, Exactly
Every image, video, and iframe on a page has a file size. When a browser loads your page, the default behavior is to fetch all of those resources immediately — whether or not they appear in the visible viewport. Lazy loading changes that default. Resources below the fold only load when a user scrolls close to them.
The browser uses an Intersection Observer API to watch which elements are near the viewport. When an element enters the defined margin — typically 200–500px before it becomes visible — the browser fetches it. Before that point, a lightweight placeholder holds the space.
This is not a trick. It is how browsers are supposed to work when configured correctly.
Why It Matters for Performance Metrics
Google’s Core Web Vitals score your site on three signals: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). Lazy loading affects all three.
LCP measures how fast the largest visible element loads. When you stop the browser from downloading 20 off-screen images at page load, it can dedicate more bandwidth to the hero image or headline — the elements that actually determine your LCP score.
CLS measures layout stability. Properly implemented lazy loading uses explicit width and height attributes on images, which reserves space before the image loads. This prevents content from jumping around as images pop in — one of the most common causes of poor CLS scores.
INP measures how fast the page responds to input. A page processing 2MB of images it does not need yet is a page with a congested main thread. Deferring that work frees the browser to respond to clicks faster.
The Native vs. JavaScript Difference
There are two ways to implement lazy loading.
Native lazy loading uses a single HTML attribute: loading="lazy". Every modern browser supports it. No JavaScript required. This is the right default for most images and iframes.
JavaScript-based lazy loading uses a library — typically with the Intersection Observer API directly — and gives you more control over thresholds, animation, and fallbacks. This is useful when you need to lazy load background images (which native loading does not support) or when you need precise control over the load trigger distance.
WordPress 5.5 added native lazy loading automatically for images below the fold. But that only works when images are added through the block editor or standard <img> tags. Page builder shortcodes, custom ACF fields, and background images set in CSS often bypass this entirely — which is why hand-coded sites have a structural advantage here.
What Not to Lazy Load
This matters as much as what you do lazy load. The hero image — whatever is visible above the fold when the page first renders — should never be lazy loaded. Deferring it delays your LCP directly. You want that image to load as fast as possible.
The same applies to:
- Any image in the first viewport on mobile
- Critical fonts used in the headline
- The logo in the header
A common mistake is applying loading="lazy" to all images globally. This tanks LCP scores. The correct approach is to lazy load everything below the fold and leave the first viewport untouched.
Lazy Loading Video and Iframes
Video embeds — especially YouTube and Vimeo — are some of the heaviest resources on a page. A single YouTube embed loads 500KB–1.5MB of third-party JavaScript before the user has touched a play button. Lazy loading iframes defers that entire payload until the user scrolls to the video.
For YouTube, the recommended approach is a facade: a thumbnail image with a play button overlay. When the user clicks, the actual iframe loads. This can reduce page weight by 1MB or more on video-heavy pages. Google’s Lighthouse tool flags YouTube embeds without facades directly in the diagnostics.
How Much Difference Does It Make?
On image-heavy pages — product galleries, case studies, blog posts with inline photos — lazy loading can reduce initial page payload by 40–70%. That translates to measurable load time reductions: 1–3 seconds faster on average mobile connections.
On a hand-coded WordPress site built from scratch, lazy loading is configured precisely — native loading="lazy" for standard images, custom JS for background images, facade patterns for video. There is no page builder inserting its own image rendering logic on top of yours.
On an Elementor or Divi site, the page builder’s rendering pipeline often conflicts with or overrides native lazy loading. You get partial implementation at best.
Lazy Loading and SEO
Google can crawl lazy-loaded content. Googlebot uses a headless Chrome renderer that simulates scrolling, which means images and text loaded via lazy loading are indexed normally. The myth that lazy loading hides content from Google has been obsolete since 2019.
What does affect SEO is page speed — and lazy loading improves it. PageSpeed Insights and Core Web Vitals are direct ranking signals. Shaving 1–2 seconds off your LCP with proper lazy loading is a concrete ranking lever, not a marginal improvement.
Implementation in WordPress
In a custom-built WordPress theme, lazy loading is implemented at the template level. Images output through PHP use the loading="lazy" attribute. Background images use a small Intersection Observer script. Video embeds use facade components.
In a plugin-based WordPress setup, you are relying on a caching or performance plugin — WP Rocket, LiteSpeed Cache, or similar — to inject lazy loading attributes. These work reasonably well, but they operate on rendered HTML after the fact. That is a patch, not a build.
If you want a performance audit of your current site before making changes, honest.designodin.com will show you exactly where lazy loading is missing and what it is costing you.
FAQ
Does lazy loading break anything? It can if implemented carelessly. Applying it to above-the-fold images delays LCP. Missing width and height attributes causes CLS. Both hurt scores more than not having lazy loading at all. Correct implementation is straightforward — the errors come from bulk application without thought.
Do I need a plugin to add lazy loading to WordPress?
No. WordPress has added native lazy loading for images since version 5.5. If your theme outputs standard <img> tags with width and height attributes, you already have it for most images. You only need additional tooling for background images and video facades.
Will lazy loading help on mobile? Yes, and the improvement is more pronounced on mobile than desktop. Mobile connections are slower, so deferring off-screen resources has a larger impact on perceived load time. Mobile users are also more likely to abandon a slow page — Google reports 53% of mobile sessions end if a page takes longer than 3 seconds.
Does lazy loading affect images in the page footer? Yes, and that is exactly where it should be applied. Footer images — team photos, client logos, certificates — are rarely visible on first load. Lazy loading them is correct behavior.
How do I know if lazy loading is working on my site? Open Chrome DevTools, go to the Network tab, filter by “Img,” and reload the page. Images that lazy load will not appear in the network requests until you scroll down. You can also check Lighthouse — it flags images that are eligible for lazy loading but do not have the attribute.
Can I lazy load fonts?
Fonts are different from images. You do not lazy load fonts — you either preload them (for above-the-fold text) or load them asynchronously with font-display: swap. Lazy loading fonts would cause invisible text during load, which is the opposite of what you want.
If you are building a new WordPress site or auditing an existing one, start here: identify your LCP element, make sure it is not lazy loaded, and lazy load everything else. That one rule covers 80% of the implementation correctly.
Our custom WordPress development includes lazy loading configured correctly from the start — no plugin required, no after-the-fact patching. If you are ready to build something that performs, get started.