Latency Budgets for Browser-Based Voice Previews

A voice preview that takes too long feels broken even when the audio is perfect. The fix is usually not a faster model; it is a clearer latency budget.

Split the wait into three parts:

1. Time to first byte: show an explicit queued state immediately, not a spinner with no label.
2. Time to first audio chunk: stream partial audio instead of waiting for the whole render.
3. Time to usable result: let the user replay and re-word without re-uploading the sample.

The trap is caching everything. A cached sample is fine, but caching a generated line means a typo in the script forces a full re-record. Cache the voice identity, not the sentence.

Short samples cannot reproduce every speaking style. If a script needs heavy emphasis or code-switching, say so in the UI instead of letting the preview fail quietly.

Keep a per-stage timing log. It tells you whether to optimize inference, transport, or the interface, and it stops you spending a week speeding up the wrong stage. The numbers will be different on every stack; the three-way split will not.