This autocomplete suggests domains that don't exist. You can just type garbage and it will suggest something, but then if you go there, there are no records.
It seems like one purpose of an autocomplete box is help you avoid typos, so that makes it less useful.
If you’d like to reduce the network latency further you can store each trie node as a file, naming it conveniently the prefix path to that node. Then dump the few hundred million files onto R2.
Now the traversal can be done completely via CDN lookups!
Unfortunately this approach doesn't feel that great down here in Australia, definitely a function of latency.
I think you could get a lot closer by framing this as an optimization problem, where you use the full alphabet dictionary, but add a residual prediction which aims to cover as much of the remaining domain name tree as possible weighted by popularity. This tree could then be pre-baked and stored with the same system. This would probably get you p99 0ms even in Australia.
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.
On a technical level yes but once you factor in monitor refresh rates then you can get to levels of optimization where it simply doesn't matter because you are constrained by waiting for the refresh rate anyways.
This autocomplete suggests domains that don't exist. You can just type garbage and it will suggest something, but then if you go there, there are no records.
It seems like one purpose of an autocomplete box is help you avoid typos, so that makes it less useful.
If you’d like to reduce the network latency further you can store each trie node as a file, naming it conveniently the prefix path to that node. Then dump the few hundred million files onto R2.
Now the traversal can be done completely via CDN lookups!
Unfortunately this approach doesn't feel that great down here in Australia, definitely a function of latency.
I think you could get a lot closer by framing this as an optimization problem, where you use the full alphabet dictionary, but add a residual prediction which aims to cover as much of the remaining domain name tree as possible weighted by popularity. This tree could then be pre-baked and stored with the same system. This would probably get you p99 0ms even in Australia.
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.
> And on keyUp (the user releases the key), we render the suggestions.
Autocomplete aside, this is a pretty nifty tool.
Pretty sure we mean < 1ms rather than actually instantaneous.
On a technical level yes but once you factor in monitor refresh rates then you can get to levels of optimization where it simply doesn't matter because you are constrained by waiting for the refresh rate anyways.
Its like tic tacs saying they are 0 calories because they got the per serving size down low enough to round to 0.
Looks more like 500ms?
its pretty clever but what happns when someone pastes a domain or uses IME or voice input? the api being that fast is still impressive.
KeyDown events don’t work great for mobile, though.