← All posts

Browser Tasks: How to Scrape JavaScript-Heavy Sites

Over 70% of modern websites need JavaScript to render their content. Here's how FourA browser tasks get you the full page when HTTP requests return empty.

Over 70% of modern websites rely on JavaScript to render their content. A standard HTTP request only sees the initial HTML shell. The actual data loads after JavaScript executes, which is why traditional scraping tools return empty pages.

FourA browser tasks solve this by running a real headless Chrome instance for every request.

How It Works

When you send a task with type: "browser", FourA:

  1. Launches a headless Chrome browser
  2. Navigates to the target URL
  3. Waits for JavaScript to execute and the DOM to stabilize
  4. Optionally waits for a specific CSS selector to appear
  5. Returns the fully rendered HTML

The entire process happens on FourA's infrastructure. You get clean HTML back with no browser to install, no Puppeteer to configure, and no Chrome updates to manage.

When to Use Browser Tasks

Use browser tasks when:

  • Single-page applications (React, Vue, Angular)
  • Pages with lazy-loaded content (infinite scroll, "load more" buttons)
  • Sites that require cookie consent or initial JS setup
  • Content behind client-side authentication flows

Stick with single tasks when:

  • Server-rendered HTML pages (news sites, blogs, wikis)
  • REST APIs that return JSON directly
  • Speed is the priority (browser tasks take 2-10 seconds vs. under 1 second for single tasks)

Example: Scraping a React App

curl -X POST https://eu.api.foura.ai/api/v1/tasks \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/dashboard",
    "type": "browser",
    "options": {
      "waitFor": ".dashboard-content",
      "timeout": 15000
    }
  }'

The waitFor selector tells FourA to wait until .dashboard-content appears in the DOM before capturing the page. This ensures all async data has loaded.

Performance Tips

  • Always use waitFor with a specific selector instead of relying on timeouts. It's both faster and more reliable.
  • Set a reasonable timeout. 15 seconds covers most SPAs. Only increase for truly slow backends.
  • Use single as your default and only switch to browser when content is missing from the response.

What's Next

We're working on additional browser capabilities including screenshot capture, PDF generation, and multi-step navigation (click, scroll, fill forms). But even without those extras, browser tasks already handle the most common pain point: getting the actual content from JavaScript-rendered pages instead of an empty shell.

Check the documentation for the full task type comparison.