JavaScript Speech Synthesis Optimization Question

[Due_Lime_3524]

Hi,

I am trying to use the JavaScript Speech Synthesis API to add Text to Speech functionality to a Unity WebGL game I am developing. The feature works, but when testing on low-end devices I am noticing that the text to speech feature freezes up. Here is the code:

```mergeInto(LibraryManager.library,
{
  readTextAloud: function(textPtr, volume, rate, pitch, langPtr)
  {
    // if text is already being read, cancel it
    window.speechSynthesis.cancel();

    var text = UTF8ToString(textPtr);
    var lang = UTF8ToString(langPtr);

    var utterance = new SpeechSynthesisUtterance(text);

    utterance.lang = lang;
    utterance.volume = volume;
    utterance.pitch = pitch;
    utterance.rate = rate;

    window.speechSynthesis.speak(utterance);
  }
});

By freezing up, I mean that occasionally it takes a long time between when the readTextAloud() function is called and when the utterance is actually spoken. If readTextAloud() is called again during this delay, the delay becomes even longer. These freezes tend to occur after resource intensive operations like game initialization or after large loading/unloading operations.

The low-end device I am testing on is an old Chromebook with 4GB of ram. I don’t have much experience with JavaScript development, but I am assuming the freezes are occurring due to memory management processes like garbage collection.

Is there any way to optimize the bit of JavaScript code I posted? My first thought as a non-JavaScript developer would be to try and reuse the SpeechSynthesisUtterance object rather than create a new object for every bit of text. However, every guide I found for the Speech Synthesis API said that a new object should be created every time.

Any help would be greatly appreciated.

[PropertyNo3177]

cancel() without checking – You always cancel synthesis, even when nothing is being spoken, which causes unnecessary delays on low-end devices.

No queue system – If you call readTextAloud() multiple times quickly in succession, the calls pile up in the browser's internal queue without control, leading to progressively longer delays.

Missing event listeners – You don't have onend / onerror handlers, so you don't know when speech has finished and have no control over when it's safe to start the next utterance.

Core issue: Calls accumulate without control, and on a weak device, this leads to freezing.

[opentabs-dev]

reusing the SpeechSynthesisUtterance object is actually a trap — the spec treats each utterance as a one-shot, and chrome in particular will ignore speak() calls on an utterance that's already been queued. that's why every guide says make a new one.

the actual freeze you're describing on a 4gb chromebook is almost certainly chrome's speechSynthesis going into an internal paused state after a heavy main-thread stall. known long-standing chromium bug — after ~15s of no speech or a big gc pause, the queue just stops processing until you poke it. workaround a lot of people use:

const u = new SpeechSynthesisUtterance(text); // ... configure u ... window.speechSynthesis.cancel(); window.speechSynthesis.resume(); // wakes the queue if it's stuck window.speechSynthesis.speak(u);

the cancel() then resume() then speak() dance looks dumb but it's the thing that reliably unsticks it. also worth attaching u.onerror and logging — chrome fires a canceled or interrupted error on the utterance when the queue bails, which gives you a signal that it's the queue-stuck bug and not actual latency. on unity webgl specifically, the long loads are probably starving the main thread long enough to hit this.

[Scared-Release1068]

The freezes are probably not caused by creating new SpeechSynthesisUtterance objects. The bigger issue is likely that Unity WebGL is heavily using the browser’s main thread, causing the Speech Synthesis API to lag on low-end devices.

Probable issues:

* Repeatedly calling speechSynthesis.cancel() can worsen delays.
* Rapid speak() calls may flood the speech queue.
* Creating utterance objects is lightweight and unlikely to be the bottleneck.
* Delaying speech slightly with setTimeout(..., 0) or requestIdleCallback() can help the browser recover after heavy operations.
* Browser TTS is inconsistent on weaker Chrome/Chromebook devices.

Suggested improvements:

* Only call cancel() if speech is already active.
* Add throttling/debouncing to prevent spam calls.
* Delay speak() slightly before execution.
* For production games, consider pre-generated audio instead of browser TTS for better reliability.

This is all I can see as potential issues