When to reach for a real browser (and when not to)
A headless browser is the most expensive way to fetch a page. Here's a practical decision tree for picking the lightest engine that actually works on your target.
A headless browser is a marvel and a liability. It will render anything, run any script, click any button — and it costs you a process, a few hundred megabytes of RAM, and a second or two of startup, every single time. People reach for it by default because it always works, and "always works" is seductive when you're tired of debugging.
But "always works" at 50× the cost of the right tool is not a strategy. It's a bill. Here's how we think about picking an engine, in the order you should try them.
Start with the question: does the data need JavaScript?
This is the only question that matters first. Open the target in your browser, disable JavaScript, and reload. If the data you want is still in the HTML, you do not need a browser. Full stop. The page is server-rendered (or close enough), and an HTTP client will get you the same bytes far faster.
A surprising amount of the web is still in this category: most listing pages, a lot of e-commerce, server-rendered frameworks, anything that cares about its own SEO. Search engines don't run your JavaScript either, so sites that want to rank tend to put the important content in the initial HTML.
If the data vanishes without JavaScript, you're in browser territory — but even then, not all browsers are equal.
The three rungs of the ladder
We expose three engines, and the discipline is to climb only as high as the target forces you.
1. Light — HTTP with TLS impersonation (1 credit). No browser. Matched TLS/JA3 fingerprints so you're not blocked at the handshake (see our piece on TLS fingerprints). This is the floor, and it should be your default attempt. APIs, static HTML, server-rendered pages, high-volume crawls — all of it lives here. It's the cheapest and the fastest by a wide margin.
2. Standard — Playwright + Chromium (5 credits). A real headless Chromium that runs the page's JavaScript, and that you can drive: clicking through pagination, waiting on selectors, filling a form, walking a multi-step flow, capturing screenshots and HAR. Use it when the data needs scripts to run, or when you need to do something on the page — a single-page app, a dashboard, anything interactive or behind a login. You pay for the render; you don't pay for evasion you don't need.
3. Stealth — Camoufox (30 credits). Fingerprint-hardened browser automation for targets with serious anti-bot defenses (Cloudflare, Akamai, DataDome). This is the top rung, and it's the most expensive path by design. You reach for it when Standard gets blocked — and only then. Leading with Stealth "to be safe" is how you turn a cheap job into an expensive one for no benefit.
The cost gradient is real
The reason this ladder matters is that the cost between rungs isn't linear, it's brutal. An HTTP fetch is milliseconds of CPU and almost no memory. A browser render is a cold-started process, a full layout and paint, and seconds of wall-clock. Stealth adds fingerprint work on top of that. That's exactly why our pricing weights them the same way — Light is 1 credit, Standard 5, Stealth 30. At one request, who cares. At a million requests a month, the difference between rung 1 and rung 3 is the difference between a rounding error and your largest infrastructure line item.
A practical heuristic
Here's the rule we'd give a new engineer:
Try Light first. If you get the data, you're done. If the page is empty without JS, or you need to do something on it, go to Standard. If Standard gets blocked, go to Stealth — and open a ticket, because a target that beats Standard is worth understanding.
The anti-pattern is the inverse: starting at the top "so it always works," then never coming back down. Six months later you're rendering a full browser to scrape a static price that was sitting in the initial HTML the whole time.
On ScrapeNest, switching rungs is a one-word change in the job payload — "engine": "light" to "engine": "standard" — same API, same artifact format, same delivery. That's deliberate. The point is to make trying the cheap option first cost you nothing, so you actually do it.