The "Test your click speed" button is fun to play with. Times 50-100 ms for mobile and 150-300 ms for desktop are reasonable long for performing some pre-loading.
[1] https://instant.page/ [2] https://github.com/GoogleChromeLabs/quicklink
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).
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.
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.
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.
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.
I assume the intention isn't speed alone, but part of the user experience. When you interact with an application, you should be able to tell immediately that it's recognized your input and something is happening.
Full screen of content within 64 ms.
Sure, I definitely expect a checkbox to do something in < 100ms. Show that its state changed and at the very least show me some kind of loading icon so I know something is happening.
But a full screen of content in 64 ms? Unreasonable, and really a completely undefined unit of measure (what is/how big is a "screen" and how much content can fit within? How do you measure audio or video content? What happens when I'm working with vector graphics that can't possibly render in 64 ms?)
There were plenty of applications in the 80s that could not render a full screen in that timeframe. That did not stop those applications from being useful.
(And I honestly think a DOS directory listing can take longer than 64ms to fill the screen)
My web browser is an interactive software application and it doesn't even start up and put an about:blank page on my screen in 64 ms. Repeat this statement for literally any GUI application, the containing window don't even appear in 64 ms.
And anyway, how big is a "screen?" What is the measurement of a screen of content? Do I have to fill up a 320x480 screen or a 3840x2160 screen? How many characters is a "screen? Pictures? Video frames?"
If you make some kind of transform in Illustrator or Photoshop, why would it be reasonable to give up the quality of the end result just to hit that arbitrary 64 ms goal? Can Illustrator even load/render a simple design like a company logo in 64 ms? A lot of interactive software combines batch processes with live interaction, too, so why would it be reasonable to be unwilling to wait more than 64ms for calculation, rendering, or transformation procedures? Of what use would the unfinished content be if it were shown to me within 64ms?
Essentially no application follows this guideline and never will.
This website is more of an exercise in snark and elitism than anything else.
This is a straw-man. You didn't ask your web browser to open, you asked your OS. Your OS shows you the response to your request to load an app or web browser, and it shows that response immediately. The launch icon blinks, your cursor changes, and a blank frame appears all within the span of a few frames.
> And anyway, how big is a "screen?"
You get to decide. I don't think the post was meant to be taken as so extremely literal as that.
> Essentially no application follows this guideline and never will
Browsers and games already do follow this guideline. I think you're mis-reading what's here, and what's here is already generally accepted and very much used broadly. The audience for this post may be devs unfamiliar with interaction best practices, new web developers who don't think to show changes on screen before a network response, or don't want to do extra work when it seems like a .then() is completely sufficient.
> This website is more of an exercise in snark and elitism than anything else.
Why do you feel it's snarky or elitist? Is it possible you're mis-interpreting this post, or just in a bad mood? As someone who's worked in games and interactive apps, I interpret the post to mean that for user interactions, please keep performance-as-a-feature in mind. There have been many threads on HN on this over the years, and that's just a drop in the bucket compared to all the talk of how to keep interaction from being frustrating to the user.
Well, it should! Why does it take more than 100 million cycles to put up a window? Because it's not a priority, not because it's particularly hard.
> Illustrator or Photoshop
It can render in the background, but it should remain responsive the entire time and anything that doesn't need batch processing should be instant.
> Essentially no application follows this guideline and never will.
Most applications could follow it with only a medium amount of discipline.
A search for "hacker news" took 186 ms, with 111 ms spent waiting.
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.
I'm on 802.11 AC WiFi seated about 5 feet from my router.
Apparently, users are quite willing to wait longer than 64 milliseconds.
I'm no web developer, so I don't claim to have expertise, but it really does seem like an unreasonable expectation. As soon as you have any sort of complex functionality the idea falls apart:
"Wait for the credit card payment to process"
"Download a high resolution image" (that counts as a page of content right?)
"Start watching this 4K video"
"Download a CSV of your 100,000 row data set"