By the fastCRW team · Search benchmark verified 2026-05-18 from a single 100-query run (triple-bench.ts, 2026) · fastCRW launch pricing expires 2026-06-01 · Verify independently before buying.
Disclosure: We build fastCRW. This is a vendor-authored comparison, so weight it accordingly — but the numbers below come from one the fastCRW fact sheet, and we report the row where Firecrawl beats us (P95) as plainly as the rows where we win.
Firecrawl vs Tavily vs fastCRW search latency, head-to-head
If you are wiring a search API into an agent loop or a RAG retrieval step, latency is not a vanity metric — it is reasoning-time delay your model pays on every turn. This post compares Firecrawl, Tavily, and fastCRW search latency on a single, concrete dataset: 100 queries across 10 categories, run concurrently against all three providers (triple-bench.ts, single point-in-time measurement). No speed multiples, no rounded marketing claims — just the median, the tail, and the win count, including where each tool loses.
The triple-bench setup: 100 queries, three providers, concurrent
The benchmark fires the same 100 queries at Firecrawl, Tavily, and fastCRW concurrently and records per-query latency for each. Because all three see identical queries at the same moment, the win count is a fair head-to-head: for each query, whichever provider returns first scores the win. All three providers returned a 100% success rate on this run, so no result is skewed by one tool silently failing. This is a search-latency benchmark only — it does not measure scrape accuracy. For scrape accuracy we publish a separate three-way benchmark with its own honest tail disclosure.
fastCRW 880 ms avg vs Firecrawl 954 ms vs Tavily 2,000 ms
On average latency over the 100 queries:
| Metric | fastCRW | Firecrawl | Tavily |
|---|---|---|---|
| Average latency | 880 ms | 954 ms | 2,000 ms |
| Median latency | 785 ms | 932 ms | 1,724 ms |
| P95 latency | 1,433 ms | 1,343 ms | 3,534 ms |
| Latency wins (of 100) | 73 | 25 | 2 |
| Success rate | 100% | 100% | 100% |
fastCRW averaged 880 ms, ahead of Firecrawl's 954 ms and roughly half of Tavily's 2,000 ms (triple-bench.ts, 100 queries, single run). The gap to Firecrawl on the average is modest — about 74 ms — while the gap to Tavily is large. We will not translate that into a speed multiple, because a single benchmark on one query mix does not earn a clean ratio; the raw numbers are what you should plan against.
73 of 100 latency wins, honestly counted
The win count tells you more than the average about typical-case behaviour. fastCRW returned first on 73 of 100 queries, Firecrawl on 25, Tavily on 2 (triple-bench.ts, 100 queries). That means on a clear majority of individual queries you would have gotten your fastCRW result back first — not just on aggregate, but query by query. It also means Firecrawl won 25 queries outright: this is not a shutout, and on your specific query distribution the split could shift.
Why median latency matters more than one average
A single average hides the shape of the distribution. A few slow queries can drag the mean up even when most requests are fast — or, less commonly, a couple of very fast responses can flatter it. For an agent that fires search on every reasoning step, what you feel is the typical request, which is the median, plus the occasional bad tail.
Median 785 ms vs Firecrawl 932 ms / Tavily 1,724 ms
On the median, fastCRW returned in 785 ms versus Firecrawl's 932 ms and Tavily's 1,724 ms (triple-bench.ts, 100 queries). The median is the line where half your requests are quicker and half slower, so 785 ms is closer to "what a user will usually experience" than the 880 ms average is. The median also widens fastCRW's lead over Firecrawl relative to the average (147 ms vs 74 ms), which is consistent with fastCRW having a tighter cluster of typical responses and a slightly heavier tail — see the P95 row below.
Reading P95 (1,433 ms) without overclaiming
Here is the row we want to call out, not bury: at the 95th percentile, Firecrawl has the lower P95 latency. fastCRW's P95 was 1,433 ms; Firecrawl's was 1,343 ms (triple-bench.ts, 100 queries). So one query in twenty, fastCRW's worst-case slow responses run about 90 ms behind Firecrawl's, even though fastCRW wins the median and the average. If your agent's user-facing SLA is governed by tail latency — the slowest 5% — Firecrawl's tighter tail is a real, measured advantage on this run. Tavily's P95 (3,534 ms) is well behind both. The honest read: fastCRW wins typical-case latency; Firecrawl wins the very top of the tail by a small margin.
One benchmark, one point in time — disclosed
Everything above is a single point-in-time measurement from one run. Search latency moves with network conditions, provider load, geography, and query mix. Treat these as a directional signal, not a guarantee, and reproduce them on your own queries before you commit. We publish the methodology and keep the numbers in one place at /benchmarks so you can see exactly what was measured.
What you get back at that latency
Latency is only half the question. The other half is what arrives when the request returns, because two APIs that both answer in under a second can hand back very different payloads.
Tavily summaries vs fastCRW full-page content per result
Tavily is summary-first: it leans toward concise, answer-shaped output well suited to narrow RAG. fastCRW's /v1/search runs a SearXNG sidecar and can optionally scrape the actual result pages, returning full-page content per result rather than only a snippet. That is a different job: Tavily optimises for a short answer; fastCRW optimises for handing your model the underlying page so it can read and cite. Firecrawl's search likewise can return scraped content per result, sitting closer to fastCRW than to Tavily on this axis.
The cost of full content in milliseconds
Returning full-page content is not free — fetching and parsing result pages adds work the latency numbers above already include where content scraping was on. That is part of why a tighter tail matters: the slow 5% are often the queries where a result page was heavy or slow to fetch. If you only need a snippet, you can skip content scraping and the latency profile shifts toward the lighter end. Match the output mode to what your loop actually consumes.
When summary-first is actually lower-latency for your loop
If your agent only needs a one-line answer to decide its next step, a summary-first API can be the lower-latency end-to-end choice even when its raw search latency is higher, because you skip a separate read step. The benchmark measures the search call, not your whole loop. If, on the other hand, your model needs to read and quote the source, fetching full content inline (fastCRW or Firecrawl) saves you the round trip of searching and then scraping separately.
Per-query cost behind the latency
Once latency is acceptable, the deciding factor is usually cost predictability — especially for an agent that searches thousands of times a day.
Flat 1-credit search vs endpoint-weighted credits
fastCRW charges a flat 1 credit per search query; optional content scraping is billed per page like any scrape. That makes per-query cost easy to forecast: queries × 1, plus scrapes if you turn content on. There is no per-query model-token surprise on a plain search. (Managed LLM answer synthesis via answer: true is a separate, opt-in path metered in credits based on usage with a per-request cap; a plain search does not touch it.) For exact tiers and credit allowances, see /pricing rather than any number quoted here.
Where Tavily's Research endpoint cost balloons
Tavily's basic search is cheap, but its Research endpoint is depth-scaled: per-request cost rises with how deep the call digs, so it grows super-linearly with agent volume rather than staying flat. That is the kind of usage-based pricing that is hard to forecast: a research-heavy loop that fires thousands of deep calls can over-run a budget in a way a flat per-query meter never does. (We do not quote a Tavily credit range here — check the current figures on Tavily's own pricing page.) fastCRW deliberately has no managed deep-research endpoint — you compose a research loop yourself over flat-credit search and scrape primitives — which trades turnkey convenience for forecastable cost. We cover that build-vs-buy trade-off in depth elsewhere; here the point is narrow: a flat per-query search is the predictable floor.
Choosing the lowest-latency search layer for your agent
When raw latency is the deciding factor
If you are optimising reasoning-time delay and you mostly care about the typical request, fastCRW's 785 ms median and 73-of-100 win rate make it the strong default on this benchmark, and it hands back full-page content at that speed. If your SLA is governed by the slowest 5% of requests, weigh Firecrawl's tighter P95 (1,343 ms vs 1,433 ms) — it is a genuine, if small, tail advantage. If you only need short summaries and do not need to read source pages, Tavily's summary-first shape can still win end-to-end despite higher raw search latency. None of the three failed a query on this run, so reliability did not separate them.
Where this fits in the wider three-way search picture
This page is a pure latency head-to-head. For the broader search-API landscape — neural discovery, answer synthesis, and how these tools differ beyond speed — see our companion pieces. They form a hub with this one rather than repeating it: start with the latency numbers here, then read the others for the feature and cost trade-offs that latency alone does not capture.
Sources
- fastCRW search benchmark —
triple-bench.ts, 100 queries across 10 categories, run concurrently, single point-in-time (2026): published methodology at /benchmarks - fastCRW
/v1/search(SearXNG sidecar, optional content scraping) and credit costs — /pricing · github.com/us/crw - Tavily search and Research endpoint pricing: tavily.com (we quote no Tavily credit figures here — check the current rates on the vendor pricing page)
- Firecrawl search/docs: docs.firecrawl.dev (verified 2026-05-18)
Related: Exa vs Tavily vs Firecrawl search API · fastCRW vs Tavily/Exa/Perplexity · fastCRW vs Tavily search benchmark · Tavily vs fastCRW