Headless Browser vs HTTP Requests: When to Use What

Published July 24, 2026 · 5 min read

The wrong scraping approach costs you either speed or data. Use HTTP requests on a JavaScript-rendered site and you get empty divs. Use a headless browser on a server-rendered blog and you waste 10x the resources. Here's how to pick the right tool for each job.

The Tradeoff at a Glance

When HTTP Requests Win

Use plain HTTP requests when:

• The site is server-rendered (WordPress, most blogs, documentation sites)
• You need raw HTML parsing speed at scale (thousands of pages)
• The data you want is in the initial HTML, not injected by JavaScript
• You're scraping an API directly (JSON endpoints, RSS feeds)

// Fast: 50ms, 10MB RAM — perfect for server-rendered content
const res = await fetch('https://example.com/blog/post');
const html = await res.text();
const title = html.match(/<h1>(.+?)<\/h1>/)[1];
console.log(title); // Got it, no browser needed

When You Need a Headless Browser

Switch to a headless browser when:

• The site is a Single Page App (React, Vue, Angular, Svelte)
• Content loads dynamically after the initial HTML (infinite scroll, lazy loading)
• You need to interact with the page (click, scroll, fill forms) to reveal data
• The site has basic anti-bot JS checks that require execution context
• You're extracting structured data from JSON-LD in the rendered DOM

// Slow but necessary: 3-8 seconds, 300MB RAM — but actually gets the data
const res = await fetch('https://extractapi.app/v1/extract', {
  method: 'POST',
  headers: { 'Authorization': 'Bearer ***', 'Content-Type': 'application/json' },
  body: JSON.stringify({
    url: 'https://react-ecommerce.com/products/widget',
    javascript: true,
    waitFor: '.product-details-loaded'
  })
});
const data = await res.json();
console.log(data.data.title); // Got it — would be empty with HTTP-only

The Hybrid Approach

The smart strategy for any scraping project: try HTTP first, fall back to browser rendering only when necessary.

async function smartExtract(url) {
  // Try 1: Check if data is in the static HTML
  const httpRes = await fetch(url);
  const html = await httpRes.text();

  // Heuristic: if the body is mostly an empty div, it's an SPA
  const textRatio = html.replace(/<[^>]+>/g, '').trim().length / html.length;
  if (textRatio > 0.1) {
    // Likely server-rendered — parse and return
    return parseFromHtml(html);
  }

  // Try 2: SPA detected — use browser rendering
  const apiRes = await fetch('https://extractapi.app/v1/extract', {
    method: 'POST',
    headers: { 'Authorization': 'Bearer ***', 'Content-Type': 'application/json' },
    body: JSON.stringify({ url, javascript: true })
  });

  const data = await apiRes.json();
  return data.data;
}

Real Numbers: Cost Comparison

The gap is massive: running your own headless browser pool costs 8-40x more than an API that handles it for you — and that's before accounting for maintenance time.

The Bottom Line

• Static sites, APIs, RSS: Use HTTP requests. Fast, cheap, reliable.
• SPAs, React apps, dynamic content: Use a browser rendering API. Don't build your own pool.
• Mixed workloads: Use the hybrid approach — HTTP-first with browser fallback for SPAs.