By the fastCRW team · Benchmark and pricing figures verified 2026-05-18 · Verify independently before buying.
Disclosure: We build fastCRW. This is a vendor-authored article, so weight it accordingly. The whole point below is that we publish the full latency distribution next to the wins, not a single flattering average.
An honest web data API comparison starts by admitting the format is rigged
Almost every "honest web data api comparison" you find online is a two-vendor cage match with a predetermined winner. The author has usually already chosen a side — sometimes because they sell one of the two tools, sometimes because an affiliate link pays out on one of them. The table is built to make that side look inevitable. This article is the meta view: how to read those pages, what an honest benchmark actually contains, and where a third, open-core option fits when you have stopped trusting the tables.
Two paid vendors, one predetermined winner
The classic structure is "Vendor A vs Vendor B." Both are closed, hosted, metered services. The comparison feels balanced because it names two competitors, but the frame quietly excludes a whole category: tools you can run yourself. When the only two options on the page both bill per request, "which is cheaper" is the wrong question — the honest question is "do I need to pay per request at all?"
Hidden costs the tables leave out
Comparison tables love a single headline price per tier. What they leave out is where the meter actually spins: JavaScript-render surcharges, premium-proxy multipliers, separate token subscriptions for AI extraction, and per-request research endpoints that can swing an order of magnitude on a single call. A row that says "$X/mo, 100k credits" tells you almost nothing if one extraction request quietly costs five credits and one research call costs two hundred and fifty.
Benchmarks that report only an average
The most common benchmark sin is the single number. "Tool A is faster" usually means "Tool A had a lower mean on the author's URL sample on one afternoon." A mean hides the tail completely. A scraper can post a great average and still time out on one request in ten — which is exactly the request your production pipeline will hit at 3am. If a benchmark cannot show you the distribution, it is marketing, not measurement.
What an honest web data benchmark looks like
The fix is not complicated. An honest benchmark publishes the full latency distribution, measures accuracy against a labeled public dataset, and discloses its own worst results as plainly as its best. Here is what that looks like with real numbers, including the one that does not flatter us.
Publishing p50 and p90 across modes, not one number
On Firecrawl's own public scrape-content dataset — 1,000 URLs, run through diagnose_3way.py on 2026-05-08, three providers, 3,000 total requests, zero thrown errors — fastCRW's p50 was 1914 ms, beating Firecrawl's 2305 ms and effectively tied with Crawl4AI's 1916 ms. In fast mode, fastCRW's p90 is 4348 ms — the lowest of the three (Crawl4AI 4754 ms, Firecrawl 6937 ms). A mean would have buried the tail entirely; a full distribution lets you pick the mode that fits your latency budget.
Truth-recall on a labeled public dataset
Speed without accuracy is a stopwatch on a tool that returns the wrong page. Of the 819 labeled URLs in that dataset, fastCRW recovered the correct content on 63.74% of them (522 of 819) — the highest truth-recall of the three, ahead of Crawl4AI at 59.95% and Firecrawl at 56.04%. fastCRW also recovers 34 URLs the other two tools miss entirely — 70% more unique recoveries than crawl4ai (10) and Firecrawl (10) combined. Scrape-success was 91.8% of reachable URLs, with 0 thrown errors across 3,000 requests. We pair those numbers deliberately: "0 errors" alone would overstate the result, because a clean error count says nothing about whether the content was correct.
Choosing the right mode for your latency budget
fastCRW's recall mode does more work to recover hard pages — that is why truth-recall is highest. In fast mode, the p90 drops to 4348 ms — the lowest of the three (Crawl4AI 4754 ms, Firecrawl 6937 ms). The mode you choose determines the accuracy/latency trade-off; we publish the full distribution so you can make that call with real numbers rather than a marketing average.
The third option: open-core and self-hostable
The reason a two-vendor table is structurally incomplete is that both vendors are hosted-only. The third category is open-core: the engine is open source, you can run it yourself for free, and a managed cloud exists if you would rather not. That changes the economics in a way no closed-vs-closed comparison can represent.
Run the same engine for $0 under AGPL-3.0
fastCRW's engine is AGPL-3.0 and self-hostable. Self-hosting costs $0 per 1,000 scrapes — you pay only for your own server. For contrast, Firecrawl's hosted service runs roughly $0.83–5.33 per 1,000 scrapes across its tiers (source: marketing/competitor-prices.lock.md, verified 2026-05-18). The point is not that hosted is bad; it is that a self-host floor gives you a hard worst-case cost ceiling that a metered-only model structurally cannot. See self-host vs managed scraping for the full trade-off.
Drop-in Firecrawl-compatible REST
The engine speaks a Firecrawl-compatible REST surface — /v1/scrape, /v1/crawl, /v1/map, /v1/search. The official Firecrawl SDK works against it after a single base-URL swap. That matters for an honest comparison because it makes the choice reversible: you are not betting your codebase on the third option, you are pointing an existing client at a different endpoint. If it does not work out, you point it back. (Field names and error envelopes diverge slightly — validate the short known list before cutover.)
Single ~8 MB binary, 1 container
Operationally the engine is a single statically-linked Rust binary: roughly an 8 MB Docker image in one container (plus an optional sidecar). The README frames this as a structural fact, not a benchmark claim, and so do we. By contrast a self-hosted Firecrawl stack is in the ~2–3 GB range across five containers. That is the difference between "self-host is a platform-team project" and "self-host is one docker run on a $5 VPS."
What the third option actually includes
An honest third option states its capabilities plainly rather than leaving them to be discovered in production. Here is the plain list.
Screenshots, PDF parsing, anti-bot, and JS rendering are built in
fastCRW produces screenshots — a request for formats: ["screenshot"] returns a base64 PNG via CDP. PDF URLs are auto-detected and parsed server-side. The open core ships built-in anti-bot (12-signal block detection, user-agent rotation, stealth fingerprints, residential-proxy rotation via the proxy field) and an automatic JS-rendering escalation ladder (HTTP → LightPanda → Chrome → proxied Chrome) that recovers thin or blocked pages without extra configuration.
Research and multi-URL extract
The managed /v1/extract endpoint accepts multiple URLs in one request, up to 50 at a time, and a research endpoint (/v2/search/research/papers) fans out across Google, OpenAlex, Semantic Scholar, and arXiv. There is no agentic /v1/agent endpoint, and fastCRW is stateless per request — there is no persistent session between calls.
LLM extraction is a paid managed feature
LLM-based JSON extraction is a managed feature available on paid plans, as is the managed /v1/search answer mode; both run on a managed LLM, metered in credits based on usage and capped per request. The FREE plan has no LLM features.
How to choose for your own workload
The meta-skill this whole article is arguing for is simple: match the tool to the job, not to whichever logo the comparison author was paid to favor.
Match the tool to the job, not the hype
Write down your top three constraints before you read anyone's table. If the binding constraint is "data cannot leave our infrastructure," that one row decides it and self-host wins regardless of every other column. If it is "we extract structured JSON on most pages," billing model matters more than headline tier price. The right tool falls out of your constraints, not out of a star rating. Our own best web scraping API in 2026 roundup and the Firecrawl vs Crawl4AI vs fastCRW honest benchmark are written to that test, not to a predetermined winner.
When the third option is the right call
The open-core third option is the right call when you want a hard cost ceiling, when data residency is a requirement rather than a preference, when you value highest-recall extraction and can tolerate a long-tail latency profile, and when you want the choice to stay reversible via a compatible API. Run the numbers on your own traffic and consult the public methodology at /benchmarks before quoting any figure internally.
The differentiator, in the end, is not a single metric. It is that an open-core tool can publish its full distribution and hand you a free self-host escape hatch — two things a closed two-way comparison page is structurally unable to offer, no matter which of its two vendors you pick.
Sources
- fastCRW canonical fact sheet (benchmark, pricing, footprint): github.com/us/crw · fastcrw.com
- 3-way scrape benchmark of record —
diagnose_3way.py, Firecrawl public scrape-content dataset (819 labeled URLs of 1,000), single run 2026-05-08 - Self-host vs hosted cost ($0 vs $0.83–5.33 per 1,000 scrapes):
marketing/competitor-prices.lock.md, verified 2026-05-18 - Firecrawl pricing/docs for context: firecrawl.dev/pricing · docs.firecrawl.dev (verified 2026-05-18)
Related: Best web scraping API in 2026 · Firecrawl vs Crawl4AI vs fastCRW: The Honest Benchmark · Self-host vs managed scraping · Benchmarks