ScreenshotNeo

BlogHow-to

How to Capture a Webpage After JavaScript Finishes Loading with Screenshotlayer

Screenshotlayer can wait a fixed number of seconds before capture. Here’s how to use that delay—and what it does not prove about JavaScript completion.

By the ScreenshotNeo team4 October 20268 min read

Short answer: Screenshotlayer documents a delay parameter that waits a specified number of seconds before taking a screenshot. You can use it to give JavaScript-rendered content more time to appear, but it is a fixed wait—not proof that JavaScript has finished. The provider documentation retrieved for this guide does not establish a selector wait, JavaScript-ready event, or network-idle condition. [Screenshotlayer FAQ]

This distinction matters: a page may still be making API requests or rendering components when a timer expires. Choose a delay based on the page you capture, then inspect the resulting image. For an application where completion must be tied to a specific event, use a browser automation workflow that waits for that event.

What the Screenshotlayer delay does

Screenshotlayer describes its delay option as a way to wait before capture so animations or effects can finish loading. Treat it as a time-based pause. It does not mean the service detects that all scripts, network requests, lazy images, or user-triggered interactions have completed.

The FAQ says its renderer can process Canvas, graphs, webfonts, and CSS3. That describes supported kinds of page content; it does not guarantee that a particular site’s scripts or data requests will finish within any chosen delay. [Screenshotlayer FAQ]

Need What the documented delay provides
Give client-rendered content more time A fixed wait, specified in seconds
Know that a particular selector appeared Not established by the retrieved Screenshotlayer documentation
Know that the network became idle Not established by the retrieved Screenshotlayer documentation
Know every script completed Not established; a timer cannot prove this

Set up a delayed Screenshotlayer capture

  1. Register or sign in and obtain an access key. Screenshotlayer requires an access key on API requests; keep it private. [Screenshotlayer FAQ]
  2. Open the provider’s interactive API documentation and confirm the current request URL and exact parameter syntax for your account.
  3. Add the documented delay parameter with a number of seconds appropriate for the page. The retrieved FAQ confirms the parameter and unit, but not its exact bounds or a universal recommended value.
  4. Save the returned image and check whether the dynamic content is present. If not, increase the wait in a controlled way and investigate whether the site requires a user action or has a failed API request.

Request construction template

The provider’s FAQ gives an example API base URL and confirms the access_key credential, but the documentation page’s parameter reference was not available in the research used for this article. The exact delay bounds, complete current endpoint syntax, and response behavior therefore cannot be verified here. Use the interactive documentation to fill in the marked fields rather than copying an unverified endpoint or guessing a parameter spelling.

# Template only: replace the URL and endpoint using Screenshotlayer's current API docs.
# Add the documented delay parameter in seconds.
SCREENSHOTLAYER_CAPTURE_URL='<current capture endpoint from provider docs>'
ACCESS_KEY='<your private access key>'
TARGET_URL='https://example.com/page-with-dynamic-content'
DELAY_SECONDS='<seconds, within the provider-documented range>'

# Build the request using the exact parameter names shown in the interactive docs.
# Do not expose ACCESS_KEY in browser-side code or public logs.

Screenshotlayer’s FAQ says PNG is the default output and lists JPEG and GIF formats. It also documents viewport sizing, full-height capture, and thumbnail width in its product material. Confirm their exact parameter names and allowed values in the live API documentation before combining them with the delay. [FAQ, API documentation]

Choose a delay that fits the page

There is no universal wait duration in the retrieved provider material. A simple page that fills in one small component may settle quickly; a page that fetches personalized data, waits on several services, or animates content may take longer. Establish a practical value with representative URLs and check the actual output.

  • Start with the page’s behavior: identify when the content becomes visible in a normal browser and whether it depends on a slow API, animation, or lazy loading.
  • Use a repeatable sample: capture the same page several times under realistic conditions. A single successful image does not show that the chosen delay is reliable.
  • Increase the wait only when needed: longer waits add latency to every capture and still cannot guarantee completion if the page is stuck.
  • Inspect the failure mode: if the expected content never appears in a normal browser, a longer screenshot delay will not fix the underlying site or authentication issue.
  • Keep expectations narrow: a delay gives rendering more time; it is not a page-readiness signal.

For this task, the relevant documented timing control is the fixed delay. Other Screenshotlayer controls may help shape the result, but check current syntax and compatibility in the provider’s interactive documentation before adding them.

Option What the retrieved material says Practical use
delay Wait a specified number of seconds before capture Allow more time for animations or dynamic content
Output format PNG by default; JPEG and GIF are listed Choose based on downstream image handling
Viewport and full-height capture Product material describes viewport sizing and full-height captures Match the capture to desktop/mobile layout or page length
Thumbnail width FAQ describes a width option for thumbnails Request a narrower output where appropriate
HTTP headers FAQ says custom User-Agent and Accept-Language headers can be requested Use only when the target page needs those headers; verify exact parameter syntax

Do not assume these options can be combined in any particular way or that a setting changes when the page is considered ready. The retrieved sources do not document a JavaScript completion event, selector-based wait, or network-idle setting.

Common problems and fixes

Symptom Likely cause What to do
Content is missing from the image The fixed delay expired before the client-rendered content appeared, or the page’s data request failed Check the page in a browser, then try a longer delay. If content remains absent, investigate the site’s API, authentication, or interaction requirements.
Some captures work and others do not Page load duration varies; a single fixed delay may be too short for slower runs Test across representative pages and times. Use a conservative delay that meets your latency needs, and monitor image output.
The capture request is rejected Missing/invalid access key or incorrect parameter syntax Check the account key and copy current parameter names and endpoint format from the interactive documentation.
The returned image is not the expected type Output format settings or defaults differ from the caller’s assumption FAQ documents PNG as default and JPEG/GIF as available. Verify the current format option and inspect the actual response before saving with a file extension.
A very long wait still shows a loading state The site may be waiting for user interaction, blocked data, authentication, or an error state Reproduce the page behavior outside the capture request. A timer cannot resolve a failed request or satisfy an interaction.
Captures take too long at scale Every request includes the configured pause, and rendering work adds further time Reduce the delay where sample captures show it is safe, avoid recapturing unchanged pages unnecessarily, and check current plan concurrency and caching terms.

Performance, reliability, and cost considerations

A fixed delay directly adds waiting time to the capture workflow. If you capture many URLs sequentially, even a modest pause accumulates; concurrent work can reduce wall-clock time only if your plan and integration support it. Screenshotlayer’s FAQ describes plan-specific dedicated workers and says each worker handles one screenshot at a time, but current plan limits and pricing should be checked on the provider site. [Screenshotlayer FAQ]

For a robust pipeline, set a client-side request timeout appropriate to your own job, distinguish a failed API request from a valid image, and validate that the response is actually an image before storing it. Retry transient transport failures sparingly with backoff. A retry cannot make an incomplete target page ready, and repeating requests can affect usage or billing under the provider’s current terms; verify those terms before production use.

Screenshotlayer’s FAQ discusses caching and an adjustable TTL, but cache behavior and its interaction with delayed captures should be checked in current documentation. If content changes frequently, make sure a cached image is not mistaken for a newly rendered result. Avoid embedding the access key in frontend JavaScript, public repositories, or logs.

When a fixed delay is the wrong readiness test

If your requirement is specifically “capture after this element appears” or “capture after this application signals ready,” a fixed timer is an approximation. A browser automation tool can wait for a selector or an application-defined condition before taking the image. That approach requires maintaining browser setup and handling browser lifecycle, fonts, viewport, and network variability yourself.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Its capture options include waiting for a selector, a delay, or network idle, so you can select the readiness condition that fits the page. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
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)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
  • Cookie banners are accepted and removed before capture, along with known newsletter popups and chat widgets; each cleanup step can be turned off.
  • Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed; response headers identify the page verdict and billing status.
  • An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs.
  • The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

Create a free ScreenshotNeo account to try 1,000 screenshots a month without a card.

FAQ

Does Screenshotlayer wait until JavaScript is finished?

The documented feature is a seconds-based delay. The available source does not say that Screenshotlayer detects JavaScript completion.

What is the right delay value?

The retrieved documentation gives no universal value or verified range. Choose it by checking real captures of the pages you need.

Does Screenshotlayer render Canvas and webfonts?

The FAQ says its engine can process Canvas, graphs, webfonts, and CSS3. That does not guarantee every page’s dynamic data will be ready at capture time.

Which image format should I expect?

The FAQ identifies PNG as the default and JPEG and GIF as alternatives. Confirm the response format and current request options in the API documentation.

Sources