Choosing an Effort Level

Every /extract and /generate request accepts an optional effort parameter. It controls the tradeoff between speed and capability; specifically, how hard Tabstack works to render and process the target page before extracting data.

---

The three levels

Level	Speed	What it does
min	1–5s	Fetches raw HTML. No JavaScript execution. Use for static, server-rendered pages.
standard	3–15s	Fetches with enhanced reliability and light JS handling. Default for all requests.
max	15–60s	Full headless browser rendering. Executes JavaScript, waits for dynamic content to load.

Default is standard when the parameter is omitted.

---

When to use each level

min: Fastest, static pages only

Use when:

• The page is server-rendered HTML (blogs, news sites, documentation)
• Speed matters and the content doesn’t require JavaScript to appear
• You’re running high-volume extractions and want lowest latency

Don’t use when:

• The page uses a JavaScript framework (React, Vue, Next.js, Angular)
• Content is loaded asynchronously after the initial HTML response
• You see empty fields or missing data with standard

TypeScript

const result = await client.extract.json({
  url: 'https://news.ycombinator.com', // Static HTML — min works fine
  effort: 'min',
  json_schema: { /* ... */ }
})

standard: The default, works for most pages

Use when:

• You’re not sure what the page renders like
• You want reliable results without committing to full browser rendering time
• The page may have some JavaScript but its primary content is in the initial HTML

This is the right starting point. If results feel incomplete, move to max.

TypeScript

const result = await client.extract.json({
  url: 'https://example.com/products',
  // effort: 'standard' is the default — can be omitted
  json_schema: { /* ... */ }
})

max: Full rendering, JS-heavy sites

Use when:

• The page is a Single Page Application (React, Vue, Angular, Next.js client-side)
• Content loads lazily or after user interaction
• Pricing tables, product listings, or data grids are rendered by JavaScript
• You’re getting empty fields with standard
• The page is behind a login with JS-rendered content after auth

TypeScript

const result = await client.extract.json({
  url: 'https://app.example.com/dashboard',
  effort: 'max', // Wait for JS to fully render
  json_schema: { /* ... */ }
})

Python

result = client.extract.json(
    url='https://example.com',
    json_schema={...},
    effort='max'
)

---

Decision flow

Is the page server-rendered HTML with no JavaScript?
  └─ Yes → try 'min'
  └─ No or unsure → use 'standard' (default)

Are you getting empty fields or incomplete data?
  └─ Yes → upgrade to 'max'

Is the page a React/Vue/Angular SPA or loads content dynamically?
  └─ Yes → use 'max' from the start

---

Cost and timeout notes

max uses full headless browser rendering. It consumes more compute than min or standard. If your target page consistently needs max, factor this into your per-request cost expectations.

Default request timeout is 60 seconds. max requests on complex SPAs can approach this limit on very slow pages. If you’re hitting timeouts, consider whether the page can be targeted more specifically with a starting URL or nocache.