How to Capture Dynamically Loaded Content Using a Website Screenshot API
Capture dynamic pages reliably by waiting for the content you need, triggering lazy loading, and choosing the right screenshot method.
A screenshot API can capture dynamically loaded content when you tell it what “ready” means for the page and, when needed, trigger content that loads only as a visitor scrolls. Prefer a wait tied to the content you need—such as a selector—over assuming that navigation completion or an arbitrary delay means the page is visually ready. For lazy-loaded sections and images, use a capture mode that scrolls the page before or during a full-page capture, then inspect the result and adjust the wait, scroll pace, viewport, or capture method.
There is no universal wait setting that guarantees a correct screenshot on every site. A selector can exist in the DOM before it is visible or populated, and full-page capture can miss content if scrolling is too fast for the page to load it.
1. Decide what “ready” means
Dynamic pages can finish navigation before their application has rendered the content you care about. Before choosing a wait, identify a page-specific signal and the capture area.
| Page behavior | Useful readiness or capture strategy |
|---|---|
| Content appears after application rendering | Wait for a selector that identifies the needed content; verify it is populated and visible where your tooling allows. |
| Content appears after a known event or interaction | Wait for that event or perform the required interaction, then capture. |
| Images or sections load when scrolled into view | Use scrolling or section-by-section full-page capture, with enough time between scroll steps. |
| Only one component matters | Capture the element if the provider supports element capture. |
| The page has animation or full-page layout issues | Try a section-by-section capture mode if available, and tune its scroll step and delay. |
A selector wait generally establishes that an element appeared in the DOM. It does not necessarily prove that the element is visible, contains final data, or has finished its visual updates. ScreenshotOne documents selector, page-event, delay, and full-page options, and explicitly cautions about the distinction between DOM presence and visibility in its options documentation. Use the selector that represents the data or component you need, not merely a generic page shell.
2. Configure a screenshot API for dynamic content
- Choose the capture scope. Use a viewport screenshot for above-the-fold content, full-page capture for the document, or an element capture for a specific component when supported.
- Set a content-specific wait. Prefer a selector or page-specific signal. Use a delay only when the page gives you no better observable signal or as an additional settling interval.
- Trigger lazy content. If content loads on scroll, enable the provider’s scrolling or section capture feature. For long pages, allow time for each section to load.
- Set a realistic timeout. Account for navigation and content readiness. If the API has separate navigation and total capture timeouts, configure both for the page’s behavior.
- Inspect the result at the intended viewport. Viewport size changes responsive layout and can change which elements load or appear.
- Tune based on the output. If a section is missing, check the selector, visibility, scroll behavior, wait duration, and full-page algorithm.
Provider settings are not interchangeable. Use the names and semantics documented by the API you choose rather than assuming an option from one service works on another.
Wait for a selector before screenshot
Pick a selector tied to the actual content—for example, a result list or article body—rather than a broad container that is present before data arrives. If the page can render an empty container first, the selector alone may be insufficient: where supported, wait for a populated state, a visible element, or a page-specific condition. Then inspect a sample capture to confirm that the content is visible and complete.
Capture lazy-loaded images and sections
Many pages defer images or sections until they enter the viewport. A screenshot taken without scrolling may therefore omit them, even if the page’s initial viewport looks correct. Browserless documents a scrollPage option and recommends combining scrolling with full-page capture for long pages. ScreenshotOne describes section-by-section full-page capture and tuning scroll step and delay to trigger deferred content. See the Browserless Screenshot API documentation and ScreenshotOne’s full-page screenshot guide.
Choose a full-page capture method
Start with the provider’s normal full-page option. If the result clips content or has layout problems—especially on animated or complex pages—try its alternate section-by-section method when available. That method scrolls through and combines sections; a fast scroll can still miss content that needs time to appear. Adjust the scroll step and per-step delay against the page’s behavior. These are vendor-specific controls, not shared parameters.
3. Runnable browser automation example with Playwright
When you need direct control over page interactions and readiness, browser automation lets you wait at the page level. This Node.js example navigates to a page, waits for a content selector to become visible, and writes a full-page PNG. Replace the URL and selector with values for the target site.
import { chromium } from 'playwright';
const url = 'https://example.com';
const contentSelector = 'main article';
const browser = await chromium.launch({ headless: true });
try {
const page = await browser.newPage({ viewport: { width: 1440, height: 1000 } });
await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 30_000 });
await page.locator(contentSelector).waitFor({ state: 'visible', timeout: 20_000 });
// Use fullPage only when the whole document is required.
await page.screenshot({ path: 'capture.png', fullPage: true });
} finally {
await browser.close();
}Install Playwright and its browser in the project before running the script: npm install playwright followed by npx playwright install chromium. Playwright notes that most locator actions auto-wait; a fixed sleep should not be the default substitute for a meaningful readiness condition. Its Page API documentation describes navigation, waits, and screenshots.
This example waits for visibility, but visibility alone may not mean the page has finished populating data. If the application replaces or updates content after first display, wait for an application-specific state as well. For lazy-loaded content, use a scroll-through step before capture or a provider’s scrolling full-page method; a plain full-page screenshot does not guarantee that every page’s deferred content was triggered.
4. Troubleshoot incomplete captures
| Symptom | Likely cause | What to check or change |
|---|---|---|
| Target content is missing | Capture began before the application rendered it, or the selector is wrong. | Confirm the selector on the rendered page. Wait for the content-specific element or state, then inspect whether it is visible and populated. |
| Selector wait succeeds, but the screenshot is blank or incomplete | The element exists in the DOM but is hidden, empty, covered, or still rendering. | Use a visibility or content condition where available. Check whether the page updates after the selector first appears. |
| Images are absent lower on the page | Images are lazy-loaded when scrolled into view. | Enable scrolling or section-by-section capture. Reduce the scroll step or increase the delay between steps. |
| Full-page capture clips or distorts sections | The page’s layout, animation, or capture algorithm does not work well with the chosen mode. | Try the provider’s alternate section capture method, if offered, and tune scroll pace. |
| Capture times out | Navigation or a page-specific wait exceeds the configured timeout, or the target never appears. | Check the URL and selector, distinguish navigation timeout from total capture timeout where supported, and set a limit appropriate to the target page. |
| Content differs from the expected layout | The viewport changes responsive behavior or content placement. | Set the intended viewport and inspect the resulting capture at that size. |
| One run succeeds and another misses content | The page’s load and scroll behavior varies, or the readiness signal is too broad. | Use a more specific signal, allow for the page’s observed variability, and retain failed or incomplete outputs for diagnosis where your workflow permits. |
These checks follow the documented controls and caveats in the official provider documentation. They are practical troubleshooting guidance, not a claim that a particular setting works for every site.
5. Performance, reliability, and cost
- Wait only for what you need. A broad “wait until everything is idle” condition can be unsuitable for pages with continuing background requests. A specific content signal can avoid waiting for unrelated activity, but it must represent the desired content.
- Use the smallest capture scope that answers the task. A viewport or element capture may involve less page work than capturing a long document, depending on the provider and page.
- Balance scroll pace and completeness. Faster scrolling may finish sooner but can fail to trigger or render deferred content. Smaller steps and longer per-step delays may help, at the cost of a longer capture.
- Keep timeouts bounded. A timeout prevents a page that never meets its readiness condition from waiting indefinitely. Handle timeout and missing-selector outcomes in the calling workflow.
- Validate representative pages. Pages differ in their rendering, lazy-loading, and layout behavior; tune configuration for the page types you actually capture.
- Compare operating models. A managed API exposes a capture request and provider-specific readiness controls. Browser automation provides direct page-level control, while your workflow must manage the browser and its execution.
For documented alternatives, Browserless provides a REST screenshot endpoint with selector, full-page, scrolling, and continue-on-error controls; Playwright provides page-level browser automation. The right choice depends on the readiness controls, lazy-load handling, capture scope, failure behavior, and operational control your workflow needs. See the Browserless API reference and Playwright Page API.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. Its capture options include full-page capture with lazy images loaded, element capture, waits for a selector, delay, or network idle, and custom JavaScript. One GET request returns an image or PDF. For setup and available parameters, see the ScreenshotNeo documentation.
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,
)
r.raise_for_status()
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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);ScreenshotNeo removes known cookie and consent banners, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.
Sign up for 1,000 free screenshots a month—no card required.
Frequently asked questions
Does waiting for a selector guarantee the screenshot is complete?
No. It can show that an element exists in the DOM without proving that it is visible, populated, or finished rendering. Check the captured result and use a condition tied to the content’s completed state when possible.
Should I always wait for network idle?
No single wait condition fits every page. Choose a page-specific signal where possible; pages that continue background requests may not reach network idle in a useful way.
Why does a full-page screenshot miss lazy-loaded images?
The images may not load until their region enters the viewport. Use a scrolling or section-based capture method and give each step time to trigger and render the content.
When should I use browser automation instead of a screenshot API?
Use browser automation when you need direct control over page interactions or a custom readiness workflow. A managed API is useful when you want to submit capture requests without managing the browser workflow yourself.
