> To be honest, I have no way of knowing or testing, because ~180 ms is already faster than I can see or react to.
As an avid video game player, 180ms is roughly the visual reaction time of good players. "Sound" to be maybe 150ms or faster however.
However, trained players consistently can "time" and percieve fast events. The throw-break window in Guilty Gear is 3-frames, or 50 milliseconds. Players still hit throw-breaks.
There's also the 1-frame jump, which improves jumping speeds by 1-frame (17 milliseconds), but requiring 1-frame precision.
--------
Street Fighter players have a variety of combos requiring "1-frame links", a window of only 17 milliseconds where the combo would work.
Humans may not "react" to 17 millisecond events, but they absolutely perceive them and can work with them. I've run calculations on musicians (ex: Flight of the Bumblebee), and "proper timing" of songs is also to a precision of less than 100ms.
EDIT: Case in point: a 16th note at 144 bpm (Flight of the Bumblebee speeds) is active for ~104 milliseconds, and probably needs to be "precisely" played at a quarter of that time period. (if you are 25 milliseconds off, a good musician probably will notice)
Humans are way more perceptive of sound than vision. So maybe its not "fair" to study music or musician perception.
You can interact with it immediately. You can hit the X to cancel the page load, you can close the tab, you can quit the browser or use another tab. Browser devs already adhere notoriously and fiercely to the ideas in the manifesto.
Whether the app/site you requested can be interacted with depends on whether the app/site devs care about interaction latency.
Talking about network response times is irrelevant to the point here. Clients can, and do, make changes on-screen before the network response.
For me, neither Google nor 64.ms complete the SSL handshake by 64 ms, so I'm not sure which content I'm supposed to be interacting with, assuming my body is physically capable of doing so by that time.
And really, even offline interactive apps have no chance of reacting this fast.
Try opening TextEdit or Mail - they don't even draw the window frame in 64 ms.
Performance is important but normal users only care about it when it's getting in the way of functionality. If we chose our preferences by performance alone, Windows Phone and webOS phones would still be here and Android would be gone, Microsoft Office would be the least popular office suite, and Steam would be the least popular PC game store.
> And really, even offline interactive apps have no chance of reacting this fast.
What do you mean? Lots of games run at 60Hz, and lots of games are considered unplayable if they render frames slower than 64ms. You might consider your terminal broken if it took more than 64ms to respond by displaying your input. https://danluu.com/term-latency/
> Try opening TextEdit or Mail - they don't even draw the window frame in 64 ms.
The OS shows you the app is loading. This seems like you're intentionally trying to prove some point and not listen, rather than being open to understanding. Arguing that an app doesn't respond quickly when the app isn't running seems obtuse.
> If we chose our preferences by performance alone,
Nobody said that, so this is another straw man. The post is suggesting that UI & frontend devs use generally accepted interaction principles, and nothing more.
To be honest, I have no way of knowing or testing, because ~180 ms is already faster than I can see or react to.
64.ms itself takes 3 ms for DNS lookup, 39 ms for the initial connection, and 29 ms for the SSL - total of 71 ms before any content download happens.
Then my browser waits for 250ms (slower than Google).