When should I use WebGPU vs WASM?

Use the runtime available to your browser and device, then measure it with your actual text and model. WebGPU availability alone does not establish a speed advantage.

How do I compare browser TTS runtimes?

Use the same device, browser, model, voice, text, and settings. Report cold start, warm generation, output quality, and failures separately.

Why is the first run different from later runs?

A first run may include model download, cache access, and runtime initialization. Measure those separately from synthesis after the model is ready.

WebGPU vs WebAssembly for Browser TTS: A Practical Guide

Kokoro Web checks whether its worker can obtain a WebGPU adapter; if one is available, it selects WebGPU, otherwise it selects WebAssembly. That capability check is not a benchmark. The current runtime also uses different model data types on the two paths, so any speed or output comparison must record both the device and the runtime settings.

1) Start with availability, then measure

WebGPU: A browser API for GPU computation. The browser, operating system, driver, and device must expose a usable adapter.
WebAssembly: The alternate runtime used by this app when the worker cannot obtain a WebGPU adapter.
Decision: Check the runtime indicator, then test the actual workload on the devices you support. A GPU path is not automatically faster for every model or device.

WebGPU is available only in secure contexts and is not supported by every browser. Review the WebGPU API documentation and compatibility notes before treating it as a guaranteed deployment path.

2) The two paths are not a controlled A/B test

In the current worker configuration, the WebGPU path selects the FP32 model file while the WASM path selects the quantized Q8 model file. That means an observed difference can come from both the execution backend and the model representation. Do not describe the result as a pure GPU-versus-CPU speed ratio unless the model, precision, text, voice, browser, and device are controlled.

Separate model download and initialization from synthesis. Measure the first audio chunk and the complete output, and repeat the same sample on the same machine. Report raw observations, the median, and the spread; retain failures as part of the record. The browser TTS benchmark guide includes a fuller measurement checklist.

3) Check compatibility on managed devices

Verify that the production site is served from HTTPS and that the target browser exposes WebGPU.
Test the browser profile and device policy your organization actually deploys; GPU access can be disabled by configuration.
Keep a tested WASM route for browsers where WebGPU is unavailable, and show a useful error if model initialization fails.

4) Keep scripts manageable

There is no universal number of seconds that makes a TTS segment safe or fast. Split by sentence or thought when separate files help with review, re-recording, or recovery. Keep the same text boundaries during a runtime comparison, and listen for pauses or words cut at the join.

For long jobs, save completed output at natural editing boundaries so one failed segment does not require repeating the whole script.
Monitor whether the browser reports an error, loses the worker, or stops returning audio; do not infer a fixed memory limit from one machine.
Review the final joined file for timing gaps, duplicated punctuation, and abrupt transitions.

5) Read startup time separately from generation

The first visit can include downloading model files. A later visit may reuse cached weights, but the runtime still has to initialize. Record whether the model was cached and whether network time was included. A warm run is useful for repeated editing; a cold run better represents a first-time visitor. Neither number alone describes the whole experience.

6) Keep the privacy boundary clear

Inference runs in a browser worker on the visitor's device, while the model files must first be downloaded from the configured model host. Explain that distinction to users: local text processing avoids sending the script to a cloud TTS service, but it does not mean the initial page and model load use no network. Tell users where model files come from and how browser caching affects later visits.

7) A practical decision process

Check which runtime the tool selected and note the model/runtime configuration.
Try a short, representative line to check pronunciation and first-audio delay.
Try a longer representative script to check completion, output quality, and recovery behavior.
Choose defaults based on measured results from the devices your audience uses, then retain a clear path for unsupported devices.

Takeaway

WebGPU and WebAssembly are runtime options, not universal speed labels. Browser support, model precision, device drivers, cache state, and the text itself all affect the result. For this app, the runtime indicator tells you which path was selected; a repeatable measurement on your deployment devices tells you whether that path is the right choice.

Author: Kokoro Web Team • Last updated 2026-10-15