Waiting for Lazy-Loaded Images and Animations Before Taking a Screenshot

A screenshot that fires the instant the page finishes its initial load will often capture the wrong moment: a gray placeholder box where a hero image should be, a skeleton loader instead of a populated table, or a card mid-way through a fade-in transition. The page did technically load. It just was not done rendering yet.

This is one of the more common sources of "why is this screenshot broken" reports, and it has a straightforward fix once you know which knob to reach for.

Why This Happens

Modern front ends defer work on purpose, for good performance reasons:

• Lazy-loaded images only start fetching once they scroll near the viewport, or once a placeholder swap fires.
• Skeleton loaders render immediately and get replaced by real content after an API call resolves.
• Entrance animations (fade-ins, slide-ins, staggered lists) are visually incomplete for a few hundred milliseconds after mount.

A screenshot API renders the real page in a real browser, so it sees all of this exactly as a visiting user would — including the in-between states, if you capture too early.

Fix 1: delay

The simplest lever is delay, available on the screenshot endpoints. It tells the renderer to wait a fixed number of seconds after the page loads before capturing:

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "url": "https://example.com/dashboard",
    "format": "png",
    "width": 1440,
    "height": 900,
    "delay": 3,
    "fullSize": true
  }'

A 2-3 second delay is usually enough to let entrance animations finish and above-the-fold lazy images settle. It is a blunt tool, but it is reliable and works on any endpoint.

Fix 2: waitForDom

For pages where a fixed delay is either too short (slow API calls) or wasteful (fast pages that do not need 3 extra seconds every time), the v3/analyze endpoint accepts waitForDom, which waits for the DOM to settle rather than waiting a hardcoded number of seconds:

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v3/analyze \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "url": "https://example.com/dashboard",
    "format": "png",
    "width": 1440,
    "height": 900,
    "waitForDom": true,
    "fullSize": true
  }'

Combine both when a page has an initial slow data fetch and lighter cosmetic animations layered on top: waitForDom for the DOM to stabilize, and a short delay on top for any purely visual transitions that follow.

Fix 3: Full-Page Capture Reveals More Lazy Content

Lazy-loading is usually scroll-triggered, which means a full-page (fullSize: true) capture has to account for images further down the page than a fixed viewport screenshot would. If a full-page capture comes back with placeholder gaps lower on the page, that is almost always a delay or waitForDom problem, not a bug in the capture itself — the renderer needs a beat to let those lower sections trigger their own load.

A Simple Rule of Thumb

Start with a short delay (1-2 seconds) on the fast v1/v2 endpoints. If that is not enough for data-heavy pages, or you are already on v3/analyze, add waitForDom and keep the delay short as a safety margin rather than the primary fix.

This same class of "page rendered but not visually settled" problem shows up with other UI patterns too — see Why Infinite Scroll Is the Enemy of Screenshots and Why Sticky Headers Break Full-Page Screenshots for two related edge cases worth checking if screenshots still look off after tuning delay and waitForDom.

Getting this right once means every future capture of that page comes back looking the way a real visitor would actually see it — which is the whole point of using Snapshot Site instead of a raw headless browser script.