JS testcases rely on floating point correctness, meaning you gotta be real precise with the code used or you'll get a rounding error.
Either use more testcases to force performance requirements, or upgrade this kata to use precise integer types like BigInt in JS.

This is math, not programming.

This is math, not programming.

This is math, not programming.

Honestly missed that note since I'm rushing through katas, but it's still pretty rubbish.

y is a vowel.

This is math, not programming.

This is math, not programming.

In JS, -3 * 0 = -0, NOT 0.
Oddly enough, after I added the check for division by zero, this test magically fixed itself despite the code path for this test not having been changed.

The number of tests causes runtime to come pretty close to the time limit, sometimes leaving the ability to submit up to how busy the codewars server is.
I've even had an empty function submission (ie submit the starting template) result in a timeout.
Depending on the solution, the performance difference between different inputs can also be pretty big and decides between timeout or not (ie it can be much less consistent than '99%').
It might be useful to either make the timer a bit more lenient, or limit the variance between inputs more; specifically to use set input lengths even for the random tests if this isn't done yet.