Caching, retries and performance

Make renders faster and cheaper with the cache, the right wait strategy, sensible timeouts and retries.

Use the cache for repeated requests#

{ "url": "https://example.com", "cache": true, "cache_ttl": 86400 }

Identical requests within cache_ttl seconds return the stored result with X-Cache: HIT. "Identical" means the same endpoint and the same options. A cache hit still counts as a render, but comes back without loading the page again.

Wait only as long as you need#

• load (the default) is right for most pages.
• networkidle helps pages that fetch data after load, but adds up to 5 seconds. Avoid it on pages that never go quiet, such as live tickers or chat widgets.
• wait_for_selector is the most precise: it waits for the element you need and no longer.
• Use delay only as a last resort.

Block what you don't need#

block_ads: true stops ad and tracker requests, so most pages load faster and the capture is cleaner.

Timeouts#

The default timeout is 20 seconds, the maximum 30. Set your HTTP client's own timeout higher than that, for example 60 seconds, because a busy queue adds waiting time on top of the render.

Send work in parallel, within your rate limit#

Requests are processed in parallel. Keep the number you send per minute under your plan's limit (see Limits and quotas) and retry 429 after Retry-After. See Errors for a retry helper.

Render once, serve many times#

For invoices, social cards and thumbnails, render when the content changes and store the file. Don't render on every page view.

Stuck? Write to [email protected] with the request you sent and the error code you got back.