Text-to-speech latency is the gap between sending text and hearing the first audio. In a voice agent or a live caption, that gap is the product. The Speechify API gives you several levers to shrink it. This post covers nine of them, from model choice to connection reuse.
For the granular engineering detail behind each lever, the speechify.ai changelog posts go deeper. Start with the streaming TTS explainer at speechify.ai/streaming-tts.
How do I pick the fastest TTS model?
Use Simba 3.2 for English workloads. It is the recommended model and is built for streaming, so its time to first byte is the lowest in the lineup. For multilingual text, Simba 3.0 adds a language parameter while staying fast. Legacy models exist for backward compatibility but cost more latency.
Match the model to the job. A low-latency voice agent wants Simba 3.2. A batch audiobook can use any model because it does not need real-time response.
Should I stream instead of waiting for the full file?
Yes, when the user is listening live. Call POST /v1/audio/stream and play audio as it arrives instead of blocking on a complete file. The streaming endpoint returns audio in chunks, so the first sound reaches the user in a fraction of the time: https://docs.speechify.ai/build/api-reference/v1/audio/stream
If you require timestamps or wordmarks with your stream, you can also use the POST /v1/audio/stream/with-timestampsendpoint: https://docs.speechify.ai/build/api-reference/v1/audio/stream/with-timestamps
Does edge deployment help?
It can cut a round trip. A one-file edge function that calls the API and streams audio back lives close to your users. Ultimately the latency is the trim to our API server and back, whether it is from the user, from the app, or from the edge.
Which output format is fastest?
Pick a format the client can play without transcoding. For phone systems, ulaw_8000 matches Twilio's native format. For browsers, PCM or the format your player handles directly avoids a decode step.
Fewer transforms between the API and the speaker means fewer milliseconds.
How does concurrency lower perceived latency?
Run synthesis in parallel when you have many short segments. Generating ten captions at once beats generating them one after another. The API handles concurrent requests, so batch where the workload allows.
Why reuse connections?
Open one HTTP connection and keep it alive. TLS handshakes and connection setup add up across thousands of requests. Connection reuse removes that cost from every call.
What about caching repeated text?
Cache audio for text you say often. Keys, greetings, and fixed UI strings repeat constantly. Store the generated clip keyed by input text, voice, and model, then reuse it. The cache cut TTS cost post covers this pattern in full.
How do I trim the input?
Shorter text is faster to synthesize. Strip boilerplate, reduce preamble, and send only what the user needs to hear. Less text in means less audio out and a quicker first chunk.
Can word-level timing hide latency?
Yes. Stream with POST /v1/audio/stream/with-timestamps to get word marks as audio arrives. Render captions word by word so the user sees progress while the rest streams. The experience feels faster even when the total audio length is unchanged.
FAQ
What is a good TTS latency target?
For voice agents, aim for first audio under a few hundred milliseconds. Streaming gets you there. Batch jobs care about total time, not time to first byte.
Does streaming cost more?
No. You pay per character synthesized. Streaming changes delivery, not pricing.
Which model is fastest on Speechify?
Simba 3.2. It is the recommended, streaming-native model with the lowest time to first byte for English.
Should I cache TTS audio?
Yes, for repeated text. Cache by input, voice, and model, then reuse the clip instead of regenerating.
