Image Load Lab

Guides Browser Behaviour Tested Oct 17, 2026 Chrome 155 · 2 viewports · 2 networks

Lazy-Loaded iframes: Chrome Loads Them Twice as Far Ahead as Images

Chrome 155 loaded lazy iframes up to 2,400 pixels below the fold and lazy images up to 1,200 pixels, identically on phone and desktop and on fast and throttled networks.

Video players, maps, social posts and comment widgets usually arrive in an <iframe>, and each one can pull in hundreds of kilobytes of its own scripts and images. Iframes support loading="lazy" just like images. How far below the fold does Chrome start loading a lazy iframe, and is that the same distance it uses for lazy images? We placed probes at measured distances and recorded which ones were requested without any scrolling.

The test

Each test page has an empty first screen and a column of probes placed with absolute positioning at fixed distances below the bottom of the viewport. In the first round, probes sat at 0, 250, 500, 750, 1,000, 1,250, 1,500, 2,000, 2,500, 3,000, 4,000 and 5,000 pixels. Once the boundaries were clear, a second round used finer steps: iframe probes every 100 pixels from 1,500 to 3,500, and image probes every 50 pixels from 700 to 1,450. Iframes loaded a tiny local HTML document; images loaded a small JPEG. Every probe used loading="lazy" and had a unique URL, so our local server could log exactly which ones were requested.

Pages were loaded in Chrome 155.0.8059.82 on a phone viewport (390 × 844, 3× density) and a desktop viewport (1440 × 900), on a fast connection and on a throttled 4G profile (1.6 Mbit/s, 150 ms latency, CPU 4× slower), three times each, and observed for three seconds without scrolling. See the methodology.

Results

Grouped bar chart: lazy images loaded up to 1,200 pixels below the fold and lazy iframes up to 2,400 pixels, on both phone and desktop viewports
Distance below the bottom of the viewport of the farthest lazy probe Chrome requested without any scrolling. Chart generated from the linked CSV.
Probes every 50 px (images) or 100 px (iframes), measured from the bottom of the first screen
Element Viewport Network Farthest loaded Nearest not loaded Runs agreeing
<img> Phone Fast 1200 px 1250 px 3/3
<img> Phone Throttled 4G (1.6 Mbit/s, 150 ms) 1200 px 1250 px 3/3
<img> Desktop Fast 1200 px 1250 px 3/3
<img> Desktop Throttled 4G (1.6 Mbit/s, 150 ms) 1200 px 1250 px 3/3
<iframe> Phone Fast 2400 px 2500 px 3/3
<iframe> Phone Throttled 4G (1.6 Mbit/s, 150 ms) 2400 px 2500 px 3/3
<iframe> Desktop Fast 2400 px 2500 px 3/3
<iframe> Desktop Throttled 4G (1.6 Mbit/s, 150 ms) 2400 px 2500 px 3/3

Lazy iframes were loaded twice as far ahead as lazy images. Chrome requested every iframe probe up to 2,400 pixels below the fold and none from 2,500 pixels onward. For images, the farthest request was 1,200 pixels below the fold, and the probe at 1,250 pixels was never fetched. The two boundaries were identical on the phone and the desktop viewport, on the fast and the throttled network, and in all 24 runs.

In the coarse first round, the farthest iframe requested was the one at 2,000 pixels and the farthest image the one at 1,000 pixels, which is consistent with the fine result: those were simply the last probes before each boundary.

The image distance matches what we measured in our earlier test of Chrome’s lazy-loading distance, and also our sideways measurement in a horizontal carousel, where the look-ahead was about 600 pixels.

What this means for embeds

  • A lazy embed placed about two to three phone screens below the fold still loads at page load. On a 844-pixel-tall phone screen, 2,400 pixels is less than three screens. A video or map in the middle of a typical article will therefore load immediately, lazy attribute or not.
  • Embeds near the end of long pages benefit most. Comment widgets and “related videos” blocks beyond 2,500 pixels were not loaded until the visitor scrolled closer.
  • For heavy embeds that are not needed right away, a click-to-load placeholder (a static image with a play button that inserts the iframe on click) avoids the load entirely. Native lazy loading only postpones it.
  • Do not lazy-load an embed that is in the first screen. It will load anyway, slightly later than an eager one.

Practical conclusion

Chrome 155 loaded lazy iframes up to 2,400 pixels below the fold and lazy images up to 1,200 pixels, regardless of viewport or network speed. Add loading="lazy" to every embed below the first screen, but expect it to help only for embeds more than about 2,500 pixels down the page; for heavier embeds closer to the top, use a click-to-load placeholder.

Limitations

Chrome only. Our probes were tiny local pages, so we measured when the iframe request started, not how much a real third-party embed would download afterwards. Distances were measured to the top edge of each probe, with a resolution of 100 pixels for iframes and 50 pixels for images.

Data and files

Download lazy-iframes.csv (18 rows, 0.6 KB) · Download lazy-iframes-fine.csv (24 rows, 0.8 KB) · Method: testing methodology.

Client Hints on Image Requests: What Chrome Sends

Chrome 155 sent DPR, width and network hints with image requests only after Accept-CH, and to another origin only with Permissions-Policy delegation. Width was in device pixels.

Browser Behaviour 4 min read

Video Poster Images and LCP: Same as an img?

A video poster was discovered as early as an img, got the same priority and counted as the LCP element with the same timing, 1,316 ms against 1,320 ms. It cannot use srcset.

Browser Behaviour 3 min read