Nimble slow by default - switch search depth to lite, limit max-results, and render only dynamic pages

TL;DR

Nimble is slow by default because the default search depth is deep. For quick lookups use --search-depth lite - it returns titles and URLs at 1 credit per call - and save deep for when you need full content.

Nimble is slow by default because the default search depth is deep. For quick lookups use --search-depth lite - it returns titles and URLs at 1 credit per call - and save deep for when you need full content. Keep max-results small (5 to 10) and skip --render unless the page is actually dynamic, since rendering adds 3 to 5 seconds per call. When you do need rendering on a bot-guarded page, pair render true with the vx10 stealth driver - that is what the Nimble cookbook uses to get past detection on dynamic React apps. And remember search_depth fast exists but is Enterprise-only; if your code requests it on a lower plan, expect a failure, not a speedup.

Context: Nimble's own error-handling reference (slow responses): the default search depth is deep and is the slowest - add --search-depth lite or fast for speed. Too many results slows things too, so start with max-results 5 to 10. Rendering JS with --render adds 3 to 5 seconds, so only use it when the content is actually dynamic. Related cookbook material (nimbleway/cookbook hotel-rate-intelligence): search_depth lite returns titles plus URLs only at 1 credit per call, and the extract API needs render true with the vx10 stealth driver to get past bot detection on dynamic pages like Booking.com.

Matched source

Source: Source: https://github.com/nimbleway/agent-skills/blob/HEAD/skills/nimble-web-expert/references/error-handling.md Original query: "Nimble slow by default - switch search depth to lite, limit max-results, and render only dynamic pages" Key terms: default, depth, dynamic, limit, lite, nimble, only, pages, render, results, search, slow

When to use

• You hit this exact issue.
• The symptom matches: Nimble slow by default - switch search depth to lite, limit max-results, and render only dynamic pages.

When NOT to use

• A different error or symptom; the cause here is specific to this one.

Compatibility

Per the linked source.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Source

https://github.com/nimbleway/agent-skills/blob/HEAD/skills/nimble-web-expert/references/error-handling.md

Source: Nimble's own error-handling reference (slow responses): the default search depth is deep and is the slowest - add --search-depth lite or fast for speed. Too many results slows things too, so start with max-results 5 to 10. Rendering JS with --render adds 3 to 5 seconds, so only use it when the content is actually dynamic. Related cookbook material (nimbleway/cookbook hotel-rate-intelligence): search_depth lite returns titles plus URLs only at 1 credit per call, and the extract API needs render true with the vx10 stealth driver to get past bot detection on dynamic pages like Booking.com.

Verified resolution: Nimble is slow by default because the default search depth is deep. For quick lookups use --search-depth lite - it returns titles and URLs at 1 credit per call - and save deep for when you need full content. Keep max-results small (5 to 10) and skip --render unless the page is actually dynamic, since rendering adds 3 to 5 seconds per call. When you do need rendering on a bot-guarded page, pair render true with the vx10 stealth driver - that is what the Nimble cookbook uses to get past detection on dynamic React apps. And remember search_depth fast exists but is Enterprise-only; if your code requests it on a lower plan, expect a failure, not a speedup.

Source URL: https://github.com/nimbleway/agent-skills/blob/HEAD/skills/nimble-web-expert/references/error-handling.md