Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The reliable test is to watch network requests during a fresh page load, then scroll toward below-the-fold content. A resource that is absent at first, starts loading as it approaches the viewport, and appears when reached is behaving as expected. Confirm the rendered DOM and, for SEO-sensitive media, Google’s rendered HTML as well. The loading="lazy" attribute alone is not proof: browser thresholds, JavaScript, cache state, errors, and layout can change the result.
What lazy loading should look like
Lazy loading defers non-critical images, videos, or iframes until they are near the visible area. Browsers normally fetch content before it crosses the viewport so it can be ready in time; the exact distance is heuristic and can vary by browser, connection, viewport, and resource type. An iframe may therefore request earlier or later than an image without indicating a bug. web.dev documents this threshold variation for embeds.
A functional pass has three parts:
- The below-the-fold resource is not unnecessarily requested during the initial load.
- Its request begins as you approach it, rather than only after a click or other manual action.
- The image, video, or embed renders when you reach it, without an error or disruptive layout shift.
For content that search engines must index, also verify that the eventual URL is present in rendered HTML. Google’s guidance is at Fix Lazy-Loaded Website Content.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Step 1: Test from a clean browser state
- Open the page in a private/incognito window, or clear the relevant browser cache. A warm cache can make a deferred resource appear to load immediately.
- Open DevTools (F12 or Ctrl+Shift+I on Windows/Linux, Cmd+Option+I on macOS).
- Select the Network panel, enable Preserve log if navigation matters, and reload the page.
- Use the request-type filter for Img to inspect images. For embedded documents, inspect Doc requests and search for the iframe URL. Use the Network panel’s disable-cache option while DevTools is open if you want repeatable cold-load runs.
- Record the browser, viewport dimensions, device emulation, network throttling, and approximate scroll position. Without those details, two runs can look different even when both are correct.
Step 2: Observe requests before scrolling
Identify below-the-fold candidates
Choose an image or iframe well below the initial viewport. Note its URL or a distinctive filename. Do not use the hero or another element visible immediately when the page opens; those resources are expected to load promptly.
#1 Best Overall
Read the initial request list
After reload, look for the candidate in Network. If it is absent initially, that is evidence that loading was deferred. If it is already present, check whether it was actually below the viewport, whether a script requested it for another reason, and whether a previous cache or preloading rule affected the run. One early request does not by itself prove that lazy loading is broken.
Check timing and status
When a request appears, inspect its status code, transferred size, initiator, and timing. A successful 200 (or a valid cached response) followed by a rendered resource is the useful result. A 404, blocked request, CORS failure, timeout, or content-type error is a loading failure, not a lazy-loading success.
Step 3: Scroll in controlled stages
- Scroll a small distance toward the target and pause briefly.
- Watch for the image or iframe request to appear. It may start before the element visibly enters the viewport because the browser is preparing ahead of time.
- Continue until the element is visible. Confirm that the content appears, not merely that a request was sent.
- Repeat for another below-the-fold element. Test a long page because one successful component does not prove every lazy-loading path works.
For embeds, compare the iframe’s document request with the visible frame. Browser implementations use different distance thresholds, so requiring a request at the exact viewport edge is an incorrect pass/fail rule. web.dev’s embed guidance explains why.
Step 4: Verify the rendered DOM
Inspect the actual image or iframe
In the Elements panel, find the target element after it has loaded. Confirm that an image has the intended URL in its src (or that a script has moved a URL from a data attribute into src). For an iframe, verify its src and that the frame’s document request succeeded.
Markup such as <img loading="eager" data-itgw-was-lazy-src="/photo.jpg"> is not enough if JavaScript never copies data-src to src. Conversely, an image can load lazily through an Intersection Observer even without the native attribute. Test behavior and the final DOM, not one implementation detail.
Use Search Console for crawlability
For an indexed page, open Google Search Console, choose URL Inspection, enter the URL, and inspect the rendered page or rendered HTML. Google recommends confirming that image or video URLs appear in the rendered element’s src. This checks what Google can discover, which is separate from what your local browser displayed. Google also cautions that visibility-triggered loading should not depend on a user scrolling or clicking, because Google Search does not interact with the page: official documentation.
Rank #2
Step 5: Check completion for a particular image
The page’s load event is not a complete lazy-loading test. MDN notes that lazy images, iframes, video, and audio can still be unloaded when that event fires: MDN lazy-loading guidance.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteIn the DevTools console, select an image in Elements so it is available as $0, then run:
$0.completetrue means the image has finished loading (or failed and finished); it does not guarantee a successful decode. Correlate it with the Network status and the visible result. You can also check natural dimensions:
({ complete: $0.complete, width: $0.naturalWidth, height: $0.naturalHeight, src: $0.currentSrc || $0.src })A zero natural width or height with a broken visual usually indicates a failed load, an invalid response, or an image that has not decoded yet.
What not to lazy-load
The LCP or hero image
Do not apply lazy loading to the image that forms the page’s Largest Contentful Paint (usually the prominent hero image). web.dev’s LCP guidance states: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” Let the browser discover that image immediately and use appropriate dimensions and priority hints.
Content visible on open
Google advises against lazy-loading content likely to be visible when a user opens the page because it can delay the first view: Google Search Central. Reserve lazy loading for genuinely non-critical, below-the-fold media.
Content that requires a user action
Do not make essential text, images, or video appear only after scrolling or clicking. Load them automatically when they become visible so both users and crawlers can access them.
Check layout stability and performance separately
Reserve space
Give images explicit width and height attributes or an aspect-ratio box. Give iframes dimensions and responsive CSS. Without reserved space, the late response can push content downward and create Cumulative Layout Shift. web.dev’s embed recommendations cover iframe sizing and layout stability.
Measure impact, not just requests
Lazy loading can reduce initial work, but the attribute alone does not prove a speed improvement. Compare cold-load and scroll behavior in Chrome DevTools and run Lighthouse. Inspect transfer size, main-thread work, third-party provider cost, LCP, and layout shifts. The web.dev image-performance guidance and embed article explain why third-party media can compete for bandwidth even when deferred.
Recommended Free Tools
| Question | Where to check | Pass signal |
|---|---|---|
| Was below-fold media deferred? | DevTools Network after a cold reload | No initial request; request starts near the element |
| Did it load correctly? | Network status plus visible page | Successful response and rendered content |
| Is the final URL discoverable? | Elements and Search Console URL Inspection | URL appears in rendered src |
| Did it hurt the first view? | Lighthouse, Performance panel | LCP remains prompt; no avoidable layout shift |
Common failures and fixes
The resource loads immediately
Likely causes: the element is within the browser’s preload threshold, it is above the fold at the tested viewport, a preload or script requested it, or cache was not cleared. Fix: test a resource farther down, disable cache, inspect the request initiator, and compare a private-window run.
The request starts but the element stays blank
Likely causes: a 4xx/5xx response, blocked third-party request, invalid URL, JavaScript error, or an image URL left in a data attribute. Fix: read the Network error, check the Console, verify the final src, and test the asset URL directly.
Content appears only after a click
Cause: user-action-only loading. Fix: trigger loading from visibility (native lazy loading or an Intersection Observer) and ensure required content is available without interaction for crawlers.
The page jumps when media appears
Cause: no reserved dimensions. Fix: add image dimensions or CSS aspect-ratio; set iframe width and height and keep the box stable while it loads.
Free tools Windows power users keep installed
One-click scans. No signup required.
The page load event seems to say everything is done
Cause: lazy resources are allowed to remain unloaded after load. Fix: observe each resource’s Network request, visual result, and image complete state instead of relying on the page event.
Search Console cannot see an image
Likely causes: the URL exists only in CSS or a data attribute, or it requires scrolling/clicking. Fix: make the final URL appear in rendered img or video src, and load it automatically when visible. Re-run URL Inspection after deployment.
A repeatable test record
For each run, record:
- URL, date, browser and version, viewport, device emulation, and network profile.
- Whether cache was disabled or the run used a private window.
- The target element and its initial distance from the viewport.
- Request start point, status, transferred size, and initiator.
- Whether the final DOM contained the URL and whether the content rendered.
- LCP and layout-shift observations from Lighthouse or the Performance panel.
This makes regressions comparable across releases and browsers instead of relying on a single visual impression.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Or skip the browser setup
If you need repeatable screenshots while checking different scroll states or responsive layouts, ScreenshotNeo provides a website screenshot API and MCP server. It accepts consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be disabled. Only clean shots are billed: bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing state.
One GET request returns PNG, JPEG, WebP, or PDF. The API supports full-page capture with lazy images loaded, CSS-selector element capture, device presets or custom viewports, retina scale, dark mode, waits for selectors/delays/network idle, custom JavaScript and CSS, cookies and headers, blocking rules, geolocation and timezone, resizing, caching, signed links, asynchronous webhooks, bulk capture of up to 100 URLs per call, and a usage API. Its MCP server exposes take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.
cURL
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpPython
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)Node.js
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);See the ScreenshotNeo API documentation for parameters and response headers. The Free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account to begin.
FAQ
Should a lazy image wait until it touches the viewport?
No. Browsers intentionally request near-viewport resources early so they are ready when scrolled into view. Judge the request against the browser and test conditions, not an exact pixel boundary.
Can I verify lazy loading from page source alone?
No. Source can show an attribute or data URL, but only Network timing, rendered DOM, and the visible result establish that the implementation works.
Does a successful request prove good performance?
No. It proves fetching, not whether the hero image was delayed, bandwidth was saved, or layout remained stable. Measure LCP, transfer size, main-thread work, and layout shifts separately.
Do images loaded by JavaScript count as lazy loading?
Yes, if visibility controls when the request begins and the resource renders correctly. Verify that the script reliably writes the final URL to src and does not depend on a user action.
Frequently Asked Questions
Which browser should I use for the test?
Start with the browser your visitors use most. If cross-browser behavior matters, repeat the same clean-run procedure in each target browser because lazy-loading thresholds and heuristics differ.
How far below the fold should my test element be?
Choose an element clearly outside the initial viewport, then test additional distances. This distinguishes genuine deferral from a resource that was already within the browser’s near-viewport loading range.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
