Hacker News Reader

Comment by GrinningFool | Hacker News Reader

"Everything Else Should Respond in Under 100ms. That number is the mental barrier after which things feel slow. Anything under 100ms feels essentially instantaneous to the user."

Not really, no. Anything under about 25-50 will feel instantaneous. Between 50-100 you're looking at something that doesn't consciously register as 'slow', yet feels vaguely sluggish - especially when it comes to responding to taps on a screen.

Native apps[1] typically respond to taps in < 20 ms and gestures in < 75 if not sooner. If your web app does not respond very nearly as fast, it will feel slow to your users.[2]

The good news is that so many html5 apps fail at this, 100 ms is enough to make your web app look good in comparison -- just not in comparison to a native app.

[1] on bb10, where I've done this timing. may differ on othe rplatforms.

[2] anecdotal, I'm afraid, but I stand by it.

View on HN

"Not really, no. Anything under about 25-50 will feel instantaneous. Between 50-100 you're looking at something that doesn't consciously register as 'slow', yet feels vaguely sluggish - especially when it comes to responding to taps on a screen."

Not according to empirical findings: http://www.nngroup.com/articles/response-times-3-important-l...

Funny that you mention BB10; I used to work at RIM (a handful of years ago), and developer relations were disseminating documents that said application developers should make apps respond in less than 150ms to give the illusion of instantaneousness.

Mind you, I'm not saying YOU can't perceive the difference between 100ms and 25ms, but that in the general populace, the limit of perception is around 100ms.

Dunno about mobile and perception, but IME, most piano players can tell difference between 20ms and 10ms latency between pressing a key and hearing a sound from a software synth.

Thats interesting. But its sound vs vision.

and yet, just registering the keyboard press mechanically will give you a much wider range of varying latencies depending on how fast or slow you press. To recognize velocity, there is a switch at the top (near the hinge), and a switch at the bottom. The timing difference, which can amount to up to 200 ms, makes up the velocity. This has always confused me, on the one hand, you spend your time tweaking IO audio buffer to have the smallest latency possible, and then you would have this input device introducing "enormous" latencies, and have them varying too.

Are you certain that is how velocity is registered?

I mean, you could be right for all I know, but I own a number of devices (drum pads, specifically) which register velocity but which don't require that kind of latency to create the information; I don't see why or how that would be the case in most keyboard controllers.

Even 25–50ms is noticeable in certain situations. See http://www.youtube.com/watch?v=vOvQCPLkPt4 for an illustration of how things get noticeably better, even as you go below 10ms.

In situations like this it's definitely important to get that response lag down as much as possible — you're looking at direct 1:1 control with that though which is slightly different than a tap. Like you said, it all depends on the situation.

100ms is a really good upper limit for that 'instant' feel. Of course, if you can get it lower, you definitely should. Nielsen finds 100ms is sufficient to feel instant but isn't the only number, of course. And, like you said, compared to other web apps it'll definitely look better.

Reply on news.ycombinator.com