I learned three thresholds over the years. Well, one of them decades ago and the others recently. Basically:

At 50ms, you notice.

At 400ms, you care.

At 2000ms, without output, you wonder if it crashed. (That was the old one.)

In the audio/synth world, the lower bound is 8ms, as in, anything above this can become bothersome to the musician. I've heard it stated that this is also the threshold for fighter pilot control systems providing feedback.

> At 2000ms, without output, you wonder if it crashed. (That was the old one.)

That must have been a really, really long time ago indeed, because there are very few websites now that take less than 2000ms to load. The linked site didn’t even come close on my phone (probably 3-4 seconds), and I most certainly didn’t wonder whether it had crashed.

The timing refers to feeling like the device acknowledged your request with some response.

Not seeing the final completion of the request.

Your phone probably showed something after you clicked the link but before the page rendered: Link highlight change, a progress bar, etc.

If your phone had crashed and the browser was non-responsive, you would have recognized it quickly. More quickly than the page load time.

Yes, exactly what I meant. (FWIW, the original context was J2ME mobile games. It was important to use as few classes as possible to keep JAR size down; but in my testing, everything put into the entry-point class had to be loaded before the program would get past an initial black screen.)

I dunno man, i am In China.. everything outside of it takes at least 2000-5000 ms to even start responding on a good day

That is your government trying to block you

maybe the site's debouncing logic on the buttons isn't working well

GitHub

Indeed. But there are also delays that cause good feelings.

I still remember the POS in my previous employers cafeteria. It had something like 100-200ms delay in processing a contactless payment card. It felt like an order of magnitude faster than any grocery store (exact same POS device). It was always very satisfying to pay for lunch. By the time you brought the card to the reader it felt like it was already printing the receipt.

I always wonder how it was so fast and if it was just some random dev optimising some obscure edge case.

In South Africa I notice this difference all the time where the big supermarket chains seem to be near instantaneous while small stores are 10+ seconds.

I'm certain it's because the big store's card machines have a wired network connection to a router with a fibre connection, while most smaller shops just use card machines with integrated GPRS wireless modems as they even show feedback about connecting as you tap your card.

A stall vendor who I use somewhat regularly warned me one time that her card machine was down (I guess some kind of maintenance as it was earlyish on a Sunday morning) so would only be able to accept cash. I helped her put the card machine on a nearby shop's free WiFi and not only did it work around the problem, but it made card transactions going forward significantly faster.

May be your cafeteria was doing offline processing, while other were doing it online?

But even offline there are huge differences, say Visa / Mastercard EMV and Suicia's Felica in Japan, where the whole transaction finish in 150ms.

There were previously some work where they try to get it down to 50ms, I don't know if they are still working on it or has abandoned it.

I was expecting the site it’s talking about to have faked an instant response. Ironically, sometimes it goes the other way and UIs have to fake a small delay otherwise the user won’t believe it’s actually done anything (although arguably the real issue there is lack of positive feedback, not response time.)

Users know to expect different things at different speeds, and have come to expect the actual "buy" button to be slow. 200ms is pretty fast for that, tbf