Fast Answers First, Slower Hotels a Moment Later
A search box cannot wait, and it should not come back empty-handed either.
Typing a destination returns city suggestions quickly, but matching hotels across a seller’s whole imported list takes much longer. The first beat now waits only 150 milliseconds and returns cities plus any hotels already found; the rest keep searching in the background for up to three seconds and arrive as a complete replacement list.
Type a few letters into the search box and the dropdown should offer cities and hotels. City suggestions are usually quick. Hotel suggestions are harder, especially keyword matching across a seller’s own imported hotel list, where a query with nothing cached can take several seconds. The goal we set for the box is a first set of suggestions within half a second.
The old approach gave hotel suggestions a fixed limit of 400 milliseconds. That limit pleased nobody. For a large list it was too short: the query almost always timed out and the dropdown showed no hotels at all. Make it longer, and the cities had to wait too. A request could answer only once, so it had to choose between fast and complete.
Suggestions are now split into two beats. The original request cuts its hotel limit to 150 milliseconds so cities come first. A new streamed request sends cities plus any hotels ready within 150 milliseconds, marked as still looking for hotels. A background hotel search continues for up to three seconds, then pushes the merged, sorted list, and a closing signal always follows. Every push carries the complete list, so the page simply replaces what it shows.
If the streamed request fails, or ends before its first beat, the page falls back to the original request: cities still appear, and hotel suggestions are limited to what that request finds within 150 milliseconds. Normally, cities show up almost at once and hotels join the same dropdown a moment later.