"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.

"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.

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.

Thats interesting. But its sound vs vision.

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.

This is a great article, and all the mobile web performance tips are spot on. But please, don't take this advice and use it to try to make your mobile web app try to be like a native app. Don't emulate android or iOS elements in HTML. emulate native performance, not native UI. there's no easier way to make your app feel wrong. You'll never be able to perfectly emulate a native android or iOS control using html and js, so stop trying. build your own UI that isn't trying to be something its not, so that your users can't tell when you miss.

Thanks for the read, notatoad. You make a great point. This article isn't about looking native — it's about feeling native. The best part about the web is that it's platform agnostic. Most of the gestures and actions that feel natural to us are cross-platform so it's great that we can rely on those to get us where we need to go.

As a companion to the OP's animation section, this year's I/O had a really good Chrome performance talk[1].

Lots of good stuff in that talk, especially about repaints, layers and memory usage. For those that don't even know where to start, this is a great source of how to profile your site for performance.

[1] https://developers.google.com/events/io/sessions/325933151

It's nice that momentum scrolling for overflow is now native both in iOS and Android. It was a pain in the butt to simulate it in JS. It's just so weird how it wasn't there from the start.

Yeah, definitely. It's still too bad that I have to tell iOS when I want to use it — and it comes with that status bar bug. But at least it's there to use.