Autoplay Audio is slow

WaniKani Bugs & Errors
22

Will this take more time than the previous version? There are times where I’ve submitted my answers and it’s been a minute but nothing’s played back yet :frowning:

I’ve even tried and left it for an hour and nothing was played back. And my internet connection’s pretty solid, latency of 6ms on average and consistently faster than any countries I’ve been to so far.

23

For me I’m at the stage where Im trying to get the pronunciation right. Like I don’t want to end up mispronouncing my 端 and 箸 and 橋 :joy:

thanks for your input though. I just cleared 100 items and only one of it had audio feedback. Sigh

2 Likes
24

Is it possible to get the old behavior of pre-loading everything reverted?

The CDN doesn’t really work in speeding things up. It only works sometimes, but sometimes results in long delay (in the range of 1s)

Personally, this issue is taking away from the good experience that I previously had - I just want the audio to play immediately after I answer.

The way that it was done in the past was working great.

3 Likes
25

Here’s additional evidence that there’s something wrong with the CDN.

Sometimes, it takes me 882ms to load the audio, which is why the audio feels delayed.
(I’ve seen cases where it took > 1s, but didn’t manage to capture it)

image
image2477×498 61.4 KB

image
image945×939 25.9 KB

Pinging the CDN yields 3ms response, so this shouldn’t be a network issue.
Instead, the CDN is just slow to respond.

Pinging 18.155.68.83 with 32 bytes of data:
Reply from 18.155.68.83: bytes=32 time=3ms TTL=248
Reply from 18.155.68.83: bytes=32 time=3ms TTL=248
Reply from 18.155.68.83: bytes=32 time=3ms TTL=248
Reply from 18.155.68.83: bytes=32 time=3ms TTL=248

I think we need to have either:

  • A method to cache the audio files locally in the user’s browser. (Maybe some kind of Cache-Control: public, max-age=XXX header in the response? I have no idea if this will work.)
  • Pre-load all the audio files when the user hits the page.
3 Likes
26

Thank you for the extra info. I see that the request was a RefreshHit from cloudfront which means it has gone back to s3 and that seems to be far away from your edge location hence the longer response time.

I went and investigated this and I found that we weren’t setting the cache control headers in the response from the origin server so the CDN (cloudfront in this instance) was using the default TTL of 24 hours. I have updated the origin server to return a far future expiration (1 year), so hopefully that will resolve the issue.

I did not invalidate the CDN cache as I thought it was better that it can use whatever cache it has to keep serving quickly and the RefreshHits would sort themselves out after 24 hours.

I have also not discounted preloading the audio, but it is not as straight forward as some might believe, so it will take some time and caution as I don’t want to introduce the same bugs that I got rid of by simplifying the code. I am still investigating this. In the meantime if this cache control change does improve the situation please do let me know.

2 Likes