Search autocomplete with static and remote data

Question

I am implementing an Autocomplete search field on a website I am working on, this will be the only form field that is shown on the homepage (along with the title and some explainer text). It will also be part of the header navigation on every other page.

The user should be able to search for either a city or country in that search field and then click on one of the results in the autocomplete field to get to the respective city/country page.

The list of countries is relatively small, therefore I was thinking for it to be performant to include that list in my frontend code, so there is no lag from fetching country autocomplete results from the server, while the city autocomplete results will have to be fetched from the server, as the dataset in the frontend would otherwise just be too large.

At the same time, this also causes some UX concerns, as now the UI would be updated 2 times after any keystroke. The first UI update would include the country results + a "fetching cities" message and after cities are loaded, the second UI update would include the complete result-set. I expect a lag of ~100-150ms from my server to fetch those city results.

What is the best UX in this case?

1) Use the solution I just described with the 2 UI updates?

2) Add artificial lag or fetch everything server-side, so that the UI will only update once per keystroke.

3) Another solution not mentioned here.

Answer 1

A lag of 100-150ms is perfectly acceptable and may also help your application to be maintained more easily.

Per the respected UX research group, Nielsen Norman Group:

The 3 response-time limits are the same today as when I wrote about them in 1993 (based on 40-year-old research by human factors pioneers):

• 0.1 seconds gives the feeling of instantaneous response — that is, the outcome feels like it was caused by the user, not the computer. This level of responsiveness is essential to support the feeling of direct manipulation...

• 1 second keeps the user's flow of thought seamless. Users can sense a delay, and thus know the computer is generating the outcome, but they still feel in control of the overall experience and that they're moving freely rather than waiting on the computer. This degree of responsiveness is needed for good navigation.

• 10 seconds keeps the user's attention. From 1–10 seconds, users definitely feel at the mercy of the computer and wish it was faster, but they can handle it. After 10 seconds, they start thinking about other things, making it harder to get their brains back on track once the computer finally does respond.

The short 0.1–0.15 second delay for a city-and-country query will still appear to be nearly instantaneous to the user.

An additional benefit is that if a city or country in your list changes its official name (which does happen on occasion) it should not require a change of your application's code in order to display correctly, but merely update your database and the application should be current.

Answer 2

I figured out that in my case I can (through some common compression techniques) make the dataset of countries and cities so small, that it's more performant to load all of it when my website loads without having to compromise too much on site speed. My autocomplete will now be instantaneous and there is no need to wait on a server to get your autocomplete suggestions on every keystroke.

I thought to mention my solution here, it might help others in the future stumbling over a similar problem, although I'll mark @maxathousand 's answer here as the correct one, as that's what you want to follow in most cases.