That gap — the silence between a caller's last word and the agent's first sound — is the single biggest lever on whether a call feels like talking to a person or talking to a machine. Too long, and callers start talking over the agent, repeat themselves, or just hang up.
Most articles about "TTFB" you'll find online (from web.dev, Cloudflare, MDN) are about webpage loading, not speech. That distinction matters more than it sounds. A "good" TTFB for a website and a "good" TTFB for a voice agent are separated by an order of magnitude. This article resets the definition specifically for text-to-speech (TTS), then compares how the leading providers actually perform.
TL;DR
- TTS TTFB: time from TTS request to first playable audio byte (not the same as HTML TTFB).
- Web TTFB is "good" under 0.8s; voice agents need ~200ms or less to feel natural.
- Cartesia, Deepgram Aura, ElevenLabs Flash, Rime, and PlayHT lead voice-agent TTFB benchmarks—results swing with measurement method.
- Raw TTS speed is only one input; STT, LLM, orchestration, and network hops decide what callers hear.
Overview of TTFB in TTS and Voice Agent Pipelines
TTS TTFB is the time between sending text to a speech engine and receiving the first playable audio byte back: not the first HTTP header, and not the finished audio file.
Rime describes this as the audio equivalent of First Contentful Paint. The goal isn't a technically "complete" response; it's the first moment something is listenable.
That single number, though, is just one segment of a much longer chain. A typical voice agent turn looks like this:
- Speech-to-text (STT) transcribes what the caller just said
- LLM inference generates a response
- TTS TTFB produces the first audio byte of that response
- Network round trips carry audio back to the phone
Each hop adds delay. Daily's engineering team has published a rough P50 breakdown for hosted voice pipelines:
- Network: ~200ms
- Turn detection and transcription: ~400ms
- LLM: ~500ms
- TTS: ~200ms
Add those up and you're already past a second before the caller hears anything. That's a median, not a worst case.
Why Streaming Changes the Math
Non-streaming TTS waits for the entire audio file to generate before sending anything back. Streaming TTS returns audio in chunks as it's synthesized, so the caller starts hearing the response while the rest is still being generated.
This is why streaming support is a non-negotiable baseline for any fair TTFB comparison. A provider with a slower model but native streaming can easily feel faster than one with a faster model stuck on batch generation. With that framing in place, here's how the major providers actually stack up.
Top TTS Providers Compared by TTFB for Voice Agents
Providers made this list based on:
- Published or independently tested TTFB figures
- Native streaming support
- Production reliability at real call volume
- Genuine adoption inside voice AI developer stacks
Cartesia
Cartesia built its Sonic model specifically for ultra-low-latency streaming TTS, aimed squarely at real-time voice agents rather than audiobook narration or dubbing.
Its edge is architectural. Cartesia uses a state-space model rather than a traditional transformer, which the company says delivers sub-100ms inference without the quality tradeoff common in speed-first models.
| Category | Details |
|---|---|
| Latency / TTFB Benchmark | Sonic 3.5 claimed first-byte ~90ms (product page: sub-90ms). No public test conditions or percentiles disclosed. |
| Streaming & Voice Quality | WebSocket API accepts incremental text via push(), generating audio continuously. Voice cloning from 10 seconds of audio, localized across 42 languages. |
| Pricing Model | Free tier: 20K credits (~27 minutes). Pro: $5/month (100K credits). Startup: $49/month (1.25M credits). Scale: $299/month (8M credits). Roughly 1 credit per character. |
Deepgram (Aura)
Deepgram made its name in fast speech-to-text, then extended that same latency obsession into TTS with Aura and Aura-2.
Competitor Rime’s head-to-heads often place it among the fastest TTFB options. Deepgram’s engineering team reported cutting Aura-2 TTFB from under 200ms to about 90ms under optimized, steady-state conditions.
| Category | Details |
|---|---|
| Latency / TTFB Benchmark | Sub-200ms baseline; ~90ms optimized figure from Deepgram engineering. |
| Streaming & Voice Quality | WebSocket streaming converts text to audio in real time. Voice prioritizes clarity and consistency over maximum expressiveness — a deliberate tradeoff at this speed tier. |
| Pricing Model | Aura-2: $0.030 per 1K characters (pay-as-you-go) or $0.027/1K on Growth. Aura-1: $0.015/1K or $0.0135/1K. New accounts get $200 in credit. |
ElevenLabs (Flash)
ElevenLabs earned its reputation on voice quality and cloning fidelity first, then built the Flash model line specifically to compete on latency for real-time conversational use cases.
Flash trades some nuance from ElevenLabs’ flagship models for speed, while still using the company’s cloning stack.
| Category | Details |
|---|---|
| Latency / TTFB Benchmark | Flash v2.5 advertised ~75ms across 32 languages — excludes network and app latency, so not end-to-end. |
| Streaming & Voice Quality | Instant Voice Cloning works from short samples; Professional Voice Cloning trains a dedicated model for higher fidelity. Flash sacrifices some lifelike quality that Multilingual v2 and Eleven v3 offer. |
| Pricing Model | Starter $6/month, Creator $22/month (first month $11), Pro $99/month, Scale $299/month, Business $990/month. API generation runs $0.05 per 1K characters. |
Rime
Rime is built exclusively for conversational, low-latency voice — phone calls and voice agents, not narration or media production.
Rime publishes its testing method: 100 varied utterances run against multiple vendors, measuring first-audio-byte time instead of leaning only on marketing claims.
| Category | Details |
|---|---|
| Latency / TTFB Benchmark | Self-reported ~175ms TTFB; sub-100ms for enterprise. Vendor figures, not a third-party audit. |
| Streaming & Voice Quality | Supports both HTTP and persistent WebSocket streaming, recommending WebSockets for the tightest conversational loop. Its Coda model is trained on full-duplex human conversation recordings. |
| Pricing Model | Mist starts at $0.03 per 1K characters; Coda at $0.05 per 1K. New accounts get 3,000 free minutes. Enterprise pricing is custom. |
PlayHT
PlayHT (Play.ht) has broad reach across voice agent and IVR platforms, largely thanks to its wide voice and language library.
It publishes a general latency figure — not explicitly labeled TTFB — of around 100ms, but notes that hitting it typically requires the on-premises deployment option rather than the standard cloud API.
| Category | Details |
|---|---|
| Latency / TTFB Benchmark | Docs cite ~100ms generic “latency” (not TTFB); best via on-prem near PlayHT’s US AWS regions. |
| Streaming & Voice Quality | Real-time HTTP streaming endpoint; recommends Play3.0-mini for lower-latency use cases. Broad voice library, though an exact voice or language count isn't published. |
| Pricing Model | No detailed public pricing tiers or usage limits are currently listed on PlayHT's official pricing page. |
How TTFB Benchmarks Are Measured (and Common Pitfalls)
The most common mistake in comparing vendors is trusting marketing copy over a standardized test. Rime's own methodology runs 100 varied utterances, from single words to multi-sentence inputs with numbers and symbols, against each vendor and measures the time to first audio byte for every one.
That's the right instinct, but it also shows why cross-vendor numbers rarely line up cleanly. For a genuinely fair comparison, these variables all need to be held constant:
- Network region: testing from a US client against a US-hosted endpoint isn't the same as cross-region testing
- Streaming vs. non-streaming mode: mixing the two invalidates the comparison entirely
- Cold vs. warm start: connection setup and SSL handshake time can dwarf model inference time on a cold request
- Utterance length and complexity: a two-word greeting and a three-sentence disclosure don't behave the same way
Those controls matter because raw TTFB is only a proxy for what businesses actually care about: caller drop-off and interruption rates. A provider that's 20ms faster on paper but spikes unpredictably under load will hurt call quality more than a slightly slower, consistently reliable one.
Beyond TTS TTFB: What Actually Determines Voice Agent Responsiveness
TTS TTFB gets most of the attention because it's the easiest number to benchmark. But it's only one slice of the total conversational latency budget, which also includes STT transcription time and LLM inference. A 90ms TTS engine bolted onto a slow LLM still produces a slow-feeling agent.
Speech-to-Speech Collapses the Chain
Speech-to-Speech (S2S) architectures skip the separate STT → LLM → TTS handoff entirely. They process audio input and generate audio output in a single model pass.
Dograh AI's S2S orchestration, built on models like Gemini Flash Live and GPT-Realtime, removes the standalone TTS TTFB bottleneck by collapsing that pipeline. End-to-end latency drops by roughly half versus a traditional sequential stack.
Hybrid Voice Removes the Wait Entirely
For frequent, predictable responses (greetings, disclosures, common objections), there's no reason to generate audio live every time. Dograh AI's hybrid pre-recorded and TTS feature blends real human voice clips with a TTS fallback in the same cloned voice, so common utterances play instantly.
That approach has cut costs up to 3x and improved outbound conversion 2x by removing latency on the responses callers hear most often.
Other factors worth weighing:
- Self-hosted or local models (such as Kokoro): shorter network hop in exchange for peak vendor model speed—best when data sovereignty or deployment latency matter most
- API concurrency limits: real-world TTFB can spike under call volume; rotating keys across providers keeps latency steady when one key hits its ceiling
Conclusion
There's no single "best" TTS provider by TTFB alone. Cartesia, Deepgram, ElevenLabs, Rime, and PlayHT each make different tradeoffs between raw speed, voice quality, and cost, and the right pick depends entirely on how it fits your surrounding architecture.
Benchmark TTS options inside your own production pipeline and real call flows, not just against vendor-published numbers. Score latency, voice quality, and cost together so one metric does not quietly tank the others.
Dograh AI's open-source, self-hostable voice agent platform lets teams plug in and swap any TTS provider (or a local model) and measure real-world latency before locking in a vendor.
Frequently Asked Questions
What does "Time to First Byte" (TTFB) mean?
TTFB refers to how long a server takes to send the first byte of a response after a request. For TTS and voice agents specifically, it means the time until the first playable audio byte arrives, not an HTTP header.
What is a good Time to First Byte (TTFB)?
For websites, under 0.8 seconds is considered good. Voice agents need far tighter latency, typically well under 200ms for streaming TTS, to avoid feeling robotic. Non-streaming TTS almost never hits that bar.
How do I calculate the Time to First Byte (TTFB)?
For TTS APIs, TTFB is measured from the moment a request is sent to the moment the first audio chunk is received. This is typically done through API response timestamps or client-side stopwatch testing.
What is the difference between TTFB and Time to Last Byte (TTLB)?
TTLB is the time until the entire audio file finishes streaming, while TTFB only covers the first chunk. TTFB matters more for perceived responsiveness because callers react to when speech starts, not when it finishes.
Why does TTFB matter more for voice agents than for websites?
Conversational turn-taking has almost zero tolerance for silence — a pause that feels normal on a webpage load feels like dead air on a phone call. This makes TTS TTFB a direct driver of perceived call quality and caller patience.
How can I reduce TTFB in a voice agent stack?
Practical ways to cut TTFB:
- Use streaming-capable TTS so audio can start before full synthesis finishes
- Collapse the pipeline with Speech-to-Speech orchestration where it fits
- Mix hybrid pre-recorded clips with TTS for common responses
- Prefer closer regions or self-hosted models to shrink network round-trips
