How to Add a Delay Before a GrabzIt Website Screenshot
Set GrabzIt’s delay in milliseconds to capture pages after dynamic content loads. Learn when to use a fixed delay or wait for a visible element.
Set GrabzIt’s delay option to the number of milliseconds to wait before capture. For example, 3000 waits three seconds. The REST API documents a default of 0 and a maximum of 30000 milliseconds. If you know which dynamic element signals readiness, a CSS-selector wait can be more precise than choosing a long fixed delay. GrabzIt REST API documentation · GrabzIt delay and element-wait guide.
What the delay does
GrabzIt detects when a page loads, but JavaScript-driven content, AJAX requests, animations, and other late updates can appear afterward. A fixed delay tells the capture process to wait a specified duration before taking the screenshot. It is elapsed time, not a guarantee that a particular API request or element has completed.
There are 1,000 milliseconds in one second: 1000 is one second, 3000 is three seconds, and 10000 is ten seconds. GrabzIt’s support examples use 3,000 milliseconds. The REST parameter’s documented default is zero, and its maximum is 30,000 milliseconds. These are GrabzIt product limits, not recommended wait times for every site.
Set a fixed delay with GrabzIt’s REST API
The REST endpoint is https://api.grabz.it/convert. A URL capture uses your application key, the target URL, a format, and optional parameters such as delay. URL-encode parameter values, especially the target URL. Save the binary response to a file rather than printing it in a terminal.
cURL
curl -G 'https://api.grabz.it/convert' \
--data-urlencode 'key=YOUR_APPLICATION_KEY' \
--data-urlencode 'format=jpg' \
--data-urlencode 'delay=3000' \
--data-urlencode 'url=https://example.com' \
--output screenshot.jpgReplace the key and target URL. Choose a format supported by your account and capture workflow. The REST API also accepts the application key as a Bearer token in the Authorization header; consult its documentation for the exact request parameters available to your capture type.
Python
This example uses requests. Install it with python -m pip install requests. It checks for an HTTP error before writing the returned bytes.
import requests
response = requests.get(
"https://api.grabz.it/convert",
params={
"key": "YOUR_APPLICATION_KEY",
"format": "jpg",
"delay": 3000,
"url": "https://example.com",
},
timeout=90,
)
response.raise_for_status()
with open("screenshot.jpg", "wb") as output:
output.write(response.content)Node.js
Node.js 18 or newer provides a global fetch. This uses the REST endpoint and URLSearchParams to encode the query.
import { writeFile } from 'node:fs/promises';
const params = new URLSearchParams({
key: 'YOUR_APPLICATION_KEY',
format: 'jpg',
delay: '3000',
url: 'https://example.com',
});
const response = await fetch(`https://api.grabz.it/convert?${params}`);
if (!response.ok) {
throw new Error(`GrabzIt returned HTTP ${response.status}`);
}
await writeFile('screenshot.jpg', Buffer.from(await response.arrayBuffer()));Use the GrabzIt Node.js client
If your project already uses GrabzIt’s Node.js client, set the delay option in milliseconds. The client’s documented flow can save asynchronously through a callback URL or synchronously with save_to; that affects retrieval of the completed capture, not the meaning of the delay.
const grabzit = require('grabzit');
const client = new grabzit(
process.env.GRABZIT_APPLICATION_KEY,
process.env.GRABZIT_APPLICATION_SECRET
);
client.url_to_image('https://example.com', {
delay: '3000',
});
client.save_to('screenshot.jpg', (error, id) => {
if (error) {
console.error(error);
process.exitCode = 1;
return;
}
console.log(`Capture saved; id: ${id}`);
});Install and configure the GrabzIt package according to its Node.js documentation. Keep the application key and secret on the server. Do not put REST credentials into browser-side JavaScript: GrabzIt warns that doing so exposes the application key. For client-side use, use its JavaScript API and follow its domain authorization guidance.
Choose a fixed delay or wait for an element
| Approach | Trigger | Documented maximum | Good fit |
|---|---|---|---|
delay |
Specified time has elapsed | 30 seconds | Content appears after a known, reasonably consistent interval, or no reliable ready element exists |
waitfor |
A matching CSS element becomes visible | 25 seconds for the REST parameter | A page exposes a dependable element when the content you need is ready |
The element option can avoid waiting out an unnecessarily long timer when the element appears promptly. That is a practical consequence of the different trigger conditions, not a performance guarantee. REST calls name the selector parameter waitfor; SDK option names can vary, such as WaitForElement or waitForElement.
REST request waiting for a selector
curl -G 'https://api.grabz.it/convert' \
--data-urlencode 'key=YOUR_APPLICATION_KEY' \
--data-urlencode 'format=jpg' \
--data-urlencode 'waitfor=#main-content' \
--data-urlencode 'url=https://example.com' \
--output screenshot.jpgUse browser developer tools to identify a selector that appears when the relevant content is ready. The selector must match the rendered page. GrabzIt says it proceeds when a matching element is visible; if multiple elements match, a visible match can trigger the capture. A selector that exists from the initial render may not tell you that its contents have finished updating.
Combine the element wait and a short delay
GrabzIt supports combining an element wait with a further delay. This is useful when the element appears first and then needs a brief settling interval for images, transitions, or related content. Keep the additional delay as small as the page allows.
curl -G 'https://api.grabz.it/convert' \
--data-urlencode 'key=YOUR_APPLICATION_KEY' \
--data-urlencode 'format=jpg' \
--data-urlencode 'waitfor=#main-content' \
--data-urlencode 'delay=500' \
--data-urlencode 'url=https://example.com' \
--output screenshot.jpgHow to choose the value
- Identify what is missing in the current screenshot: an element, an image, data loaded by JavaScript, or an animation state.
- If a stable visible selector marks readiness, try
waitforfirst. If the page has no reliable marker, start with a short fixed delay such as1000or3000milliseconds. - Inspect captures across representative page loads. Increase the delay only if the needed content is still absent; reduce it if the same content appears reliably sooner.
- For content that loads in stages, wait for the most useful readiness marker and add only a brief extra delay if necessary.
- Keep a ceiling in mind: REST
delayis capped at 30,000 ms and RESTwaitforat 25 seconds. A page that is still not ready may need a different selector or investigation of its loading behavior.
A fixed timer cannot know whether a network request succeeded. It can expire while a slow page is still loading, or keep waiting after a fast page is already ready. Also, GrabzIt documents accelerated delay: for supported capture formats, its browser can simulate elapsed time so scripts or animations run without consuming the full wait as real time. Do not assume the duration maps one-for-one to wall-clock processing time. Its support guide says this optimization does not apply to MP4 or DOCX captures.
Troubleshooting
| Symptom | Likely cause | What to try |
|---|---|---|
| The screenshot still misses dynamic content | The delay is shorter than the content’s actual loading time, or the page updates later in stages. | Use a visible readiness selector with waitfor, or increase the delay in small increments. Confirm the selector matches the rendered DOM. |
| The screenshot waits too long | The fixed delay is longer than needed. | Reduce it or switch to an element wait that tracks the content you need. |
| The element wait does not trigger as expected | The CSS selector is invalid, absent, or never becomes visible; it may match a placeholder present before the content is ready. | Test the selector in the browser’s developer tools. Choose an element whose visibility corresponds to readiness and remember the REST maximum wait is 25 seconds. |
| The capture returns an error or no image file | Credentials, URL encoding, format, network access, or the capture request may be wrong. | Check the HTTP status and response, confirm the application key and URL, encode query parameters, and review GrabzIt’s REST documentation for capture options and account requirements. |
| The capture finishes sooner than the configured delay | Accelerated Delay may simulate time for supported formats. | Do not use wall-clock processing duration as proof that the option was ignored. GrabzIt documents real-time exceptions for MP4 and DOCX. |
| Captures slow down when the service is busy | Long waits can reduce capture priority when requests are queued. | Use the shortest reliable delay or a selector wait. GrabzIt specifically cautions against unnecessarily large delays. |
| Credentials appear in browser code | The REST request is being made from an untrusted client. | Move the REST call to a server you control, or use GrabzIt’s JavaScript API as documented for client-side use. |
Performance, reliability, and cost considerations
- Latency: A longer delay can extend capture processing, though accelerated delay means it need not add the same amount of real elapsed time for supported formats. Avoid assuming a fixed timing relationship.
- Queue priority: GrabzIt warns that large delays may reduce priority if captures are queued.
- Reliability: Fixed waits are easy to configure but depend on a timing guess. Selector waits are tied to visible page state, but only help when the selector is stable and represents the content you need. Neither proves every page request succeeded.
- Limits: REST delay defaults to zero and tops out at 30 seconds; REST selector waiting is limited to 25 seconds. These are separate documented limits.
- Cost: The supplied GrabzIt documentation establishes the delay behavior and limits, but not current plan prices or per-capture charges. Check GrabzIt’s current plan details for your account before estimating cost. For ScreenshotNeo, the supplied product pricing is 1,000 shots per month free with no card; paid plans start at $5 for 3,000 shots.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server for developers. Make one GET request to capture a URL; the response is an image or PDF. Its documented options include waiting for a selector, a delay, or network idle, alongside custom headers, cookies, viewport settings, and more. 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.webpimport 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, popups, and chat widgets are removed before the shot.
- Bot checks, blank pages, and failed loads are never billed.
- An MCP server lets AI agents take screenshots.
- 1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000.
Sign up free and capture up to 1,000 screenshots a month with no card.
FAQ
Is the delay measured in seconds?
No. It is measured in milliseconds: use 3000 for three seconds.
Does a delay mean the page has fully loaded?
No. It waits for a duration after page loading behavior recognized by GrabzIt; asynchronous page content can still need a selector wait or additional time.
Can I set a delay longer than 30 seconds?
The REST API documents a maximum delay of 30,000 milliseconds. Its separate waitfor option documents a maximum of 25 seconds.
Why use a selector instead of waiting three seconds?
A selector wait is tied to a visible element that signals readiness, so it can proceed based on page state rather than always consuming a guessed interval.
