The perceived latency starts from keydown, not keyup. Redefining latency to start at keyup reduces measured latency, not perceived latency, and delaying the visual display to keyup makes perceived latency strictly worse, not better. Even sticking with the keyup definition, just displaying the result as soon as it is available gives the possibility of negative (defined) latency.
I think you don't fully understand. They aren't just doing a search based on the key being pressed down. They already did a search based on the previous characters that returned results for all possible next characters. So by the time you type a second character it just checks results locally from the search that had likely already been returned from when you had typed the previous character.
There are a large number of edge cases where rendering it on key down would not be desirable (user types Ctrl+v, how accented characters are enetered, how some Asian languages get handled, backspace/delete, user holds a key down, etc). This is getting into the point of optimization where it simply does not matter and can actually harm things
Holding a key would indeed require both on key down and up. I'd still argue that handling rerender on key down (or to fully match whatever OS/browser semantics, oninput) makes more sense than key up. Pressing Ctrl+V for example produces feedback as soon as "V" is pressed, not when Ctrl and/or V is released.
Interestingly Ctrl+V on OP's website does update immediately when Ctrl+V is pressed.
What autocompletes are you testing? I set my repeat delay to be very long so it doesn't interfere with the test, and then went to google and held down some keys for half a second. It types the letter and autocompletes long before I let go.
Every UI I can find types the letter on keydown, and I don't know why you'd want typing and autocomplete to use different timings.
Waiting for release is for mice and touch, not keyboards. And that's only because they have to deal with dragging.
Comments
Clever but that’s not how we measure latency.
When it comes to UX, perceived latency is king.
The perceived latency starts from keydown, not keyup. Redefining latency to start at keyup reduces measured latency, not perceived latency, and delaying the visual display to keyup makes perceived latency strictly worse, not better. Even sticking with the keyup definition, just displaying the result as soon as it is available gives the possibility of negative (defined) latency.
I think you don't fully understand. They aren't just doing a search based on the key being pressed down. They already did a search based on the previous characters that returned results for all possible next characters. So by the time you type a second character it just checks results locally from the search that had likely already been returned from when you had typed the previous character.
They do that, yet proceed to kneecap the perceived latency by delaying the render.
There are a large number of edge cases where rendering it on key down would not be desirable (user types Ctrl+v, how accented characters are enetered, how some Asian languages get handled, backspace/delete, user holds a key down, etc). This is getting into the point of optimization where it simply does not matter and can actually harm things
Holding a key would indeed require both on key down and up. I'd still argue that handling rerender on key down (or to fully match whatever OS/browser semantics, oninput) makes more sense than key up. Pressing Ctrl+V for example produces feedback as soon as "V" is pressed, not when Ctrl and/or V is released.
Interestingly Ctrl+V on OP's website does update immediately when Ctrl+V is pressed.
Why would you argue that makes more sense? That is not how any autocomplete works that I know of, it's not like this is a new pattern.
What autocompletes are you testing? I set my repeat delay to be very long so it doesn't interfere with the test, and then went to google and held down some keys for half a second. It types the letter and autocompletes long before I let go.
Every UI I can find types the letter on keydown, and I don't know why you'd want typing and autocomplete to use different timings.
Waiting for release is for mice and touch, not keyboards. And that's only because they have to deal with dragging.
Your test is flawed, it's triggering keyup if it's showing in the input.
I go to the text box in HN and hold down a key.
The letter appears instantly, then after a moment a lot more copies of the same letter start showing up rapid-fire.
What are you calling flawed about my test?
This happens on both Windows 10 and Linux Mint, in Firefox.
Overall the correct event to listen to would be the input even not the keydown event since it handles the edge cases I mentioned earlier
I never meant to infer that the keyup event is specifically what should be listened to
What you said might be true and yet what OPs AI agent did wasn't measure latency of the service nor calculated a p99 for it.