Why images come out blank in a full page screenshot

Lazy loading exists because loading forty images on a page where a visitor will see four is wasteful. The browser holds off until an image is near the viewport, then requests it. That is good for page speed and directly hostile to screenshot capture.

This is one of the two failures that separate a naive full page capture from one that handles real pages. A capture scrolls faster than a human. It arrives at an image, triggers the load, photographs the viewport perhaps 300 milliseconds later, and moves on. If the image needed 600 milliseconds to arrive and decode, what got photographed was the placeholder.

The fix that always works

Twenty seconds of preparation, and it resolves the problem regardless of which capture tool you use.

1. 1

   Scroll to the very bottom of the page

   Press End, or drag the scrollbar down. Every lazy image passes through the viewport and starts loading.

2. 2

   Wait for the network to settle

   Two or three seconds on a normal connection. On an image-heavy page, watch for the images to visibly appear.

3. 3

   Scroll back to the top

   Press Home. The images stay loaded — browsers do not unload them.

4. 4

   Capture

   Everything is already decoded, so nothing is waiting on the network.

What a capture can do automatically

Prompt content to load before starting

Dispatching scroll and resize events, and touching each image's loading attribute, makes most lazy loaders release their images before the capture loop begins.

Wait for decoding, not just for the request

An image that has arrived is not necessarily painted. Waiting on the decode step rather than the load event is the difference between a partial fix and a real one.

Increase the per-step delay

The blunt instrument, and sometimes the only thing that works with an aggressive custom loader. It makes the capture slower in exchange for being right. The setting lives with the rest of the automatic scrolling behaviour.