TTS API Latency: Why This Site Publishes No Benchmark
Only one vendor in the 2026 run states a latency figure. Why a cross-vendor benchmark misleads, what each API discloses, and how to measure time to first audio yourself.
The short answer
There is no honest cross-vendor latency ranking in this run. One vendor, Respeecher, states a figure on its product page: voice streaming in less than 200 ms (Respeecher). The other nine document streaming, buffering, or optimisation controls but publish no numeric target. Comparing a stated claim with an unstated one produces a ranking of marketing copy, not of speed.
What each API discloses
The table records the disclosure, not a measurement. “No target” means the page reviewed describes a control or a mode but does not promise a time.
| API | What is published | Numeric target |
|---|---|---|
| Respeecher | less than 200 ms streaming claim | yes, vendor claim |
| ElevenLabs | latency-optimisation level 0–4 (reference) | no |
| Cartesia | buffer delay up to 5,000 ms, flush, context continuation (reference) | no |
| Deepgram | streaming response, TTFB measurement example (guide) | no |
| Google Cloud TTS | streaming synthesis APIs (docs) | no |
| Amazon Polly | streaming synthesis (docs) | no |
| OpenAI | streaming audio, tts-1 positioned as lower latency than tts-1-hd (guide) | no |
| WellSaid | streaming endpoint and a real-time claim (API page) | no |
| Typecast | real-time voice claim (product page) | no |
| Uberduck | no latency claim on the docs reviewed (docs) | no |
Why the claims are not comparable
A latency figure can mean at least four different things. It can be the time to the first audio byte, the time to the first word, the time to a complete sentence, or the time to a finished file. A vendor that says “less than 200 ms” is usually describing the first audio chunk on a short input in a favourable region. A vendor that says nothing may still be fast, or may be slow; the page does not tell you.
The payload matters too. A short greeting and a 500-word article are different workloads, and a streaming API can return the first chunk quickly while taking much longer to finish. Concurrency matters as well: a service that is fast with one request may queue under ten. A single test at one concurrency level is not a capacity result.
Finally, the network path matters. A request from Frankfurt to a US endpoint and a request from Virginia to the same endpoint will not produce the same number. Without a stated region and payload, a latency table is a story about the tester’s laptop.
How to measure it yourself
Fix the variables. Pick one region close to your users, one voice, one output format, and one payload size. Use the same text for every vendor, including a number, a name, and a long sentence.
Measure two numbers. Time to first byte tells you how soon a listener hears something. Time to completion tells you how long a file takes. Report both; a single number hides the difference between a streaming service and a fast file service.
Run at production concurrency. Start with one request, then repeat at the concurrency you expect at peak. A service that holds one stream may behave differently at twenty. Record errors and retries, not just successful requests.
Report a distribution. A median and a 95th percentile are more useful than an average, because the slow tail is what users remember. Keep the raw samples so the test can be repeated after a model update.
Date the result. Vendors change models and infrastructure. A benchmark without a date is a claim about the past presented as a claim about today.
What the disclosure scores mean
This site’s latency dimension gives points for disclosure: a numeric target or a documented optimisation ladder scores highest, a streaming endpoint without a target scores next, and a marketing claim without a protocol-level control scores lower. That is why ElevenLabs and Respeecher score at the top of the dimension, while Typecast and Uberduck score lower.
The score is not a speed verdict. A vendor can publish nothing and still be fast; a vendor can publish a target and miss it under load. The only defensible use of the score is to shortlist vendors whose documentation gives you something to test against.
Who should care
Real-time products — voice agents, live captions, interactive characters — should care most. For those, time to first audio is the product. Start with the vendors that document a streaming mode and a concurrency model, then run the test above at your expected concurrency.
Batch products — audiobook rendering, e-learning export, nightly narration — should care about time to completion and cost per million characters, not first-byte latency. A file-based API with a queue can be a better fit than a streaming API you do not need.
Prototypes should care least. A vendor that is easy to call and cheap to test will teach you more in a day than a latency table will in a week.
The takeaway
The absence of a benchmark is a finding, not a gap in coverage. The market does not publish comparable latency data, so this desk does not manufacture a comparison. Use the disclosure table to shortlist, then measure time to first byte and time to completion in your own region, at your own concurrency, and keep the raw numbers.
FAQ
Which TTS API has the lowest latency?
This site does not publish a lowest-latency winner. Only Respeecher states a figure on the page reviewed, describing voice streaming in less than 200 ms. The other nine vendors document streaming or optimisation controls without a numeric target, so a cross-vendor ranking would compare a marketing claim against silence.
Why not run a simple benchmark and publish the results?
A latency number depends on the region, the payload, the concurrency level, the output format, and whether the measurement stops at the first audio chunk or at the last. A single test from one machine would produce a number that looks precise and does not transfer to another deployment. We would rather publish the method than a misleading decimal.
What should I measure in my own test?
Measure time to first audio byte and time to completion separately, at the concurrency you expect in production, from the region where your users are. Run enough requests to report a median and a 95th percentile, and keep the payload and voice settings fixed across vendors.
Does streaming always beat a file response?
Streaming lowers the time until a listener hears something, but it does not necessarily lower the time until the full audio is available. If your pipeline writes a file before playback, streaming may not help. If your product plays audio as it arrives, streaming is the relevant mode.