On this page
Mitigate the impact of slow network in your search application.
You can mitigate the impact of slow network on your search experience by managing the user’s expectations. One way of letting them know that the network is suboptimal is by displaying a progress indicator, which will avoid them being frustrated by the network delays and blaming your application for lack of responsiveness.
We provide such a mechanism in our
SearchView: see the section on its Progress indicator.
Optimize build size
Number of requests made
The Searcher keeps track of all requests made by incrementing its
lastRequestId. You can get it by subscribing to
ErrorEvent streams and checking their
requestSeqNumber to get the latest request count.
Enabling the Search cache
Index is able to cache the search request’s response to avoid duplicate queries (for example when the user types
o, then deletes
o; it would directly display the results it got for
To enable the search cache for a given index, you can either use the default parameters or specify your own requirements:
1 2 3 4 5 // Cache up to 64 requests for 2 minutes each index.enableSearchCache(); // Cache up to 10 requests for 60 seconds each index.enableSearchCache(60, 10);
Queries Per Second (QPS)
Every time you press a key in InstantSearch using the SearchBox, we count one operation. Then, depending on the widgets you will be adding to your search interface, you may have more operations being counted on each keystroke. For example, if you have a search made out of a SearchBox, a Menu, and a RefinementList, then every keystroke will trigger one operation. But as soon as a user refines the Menu or RefinementList, it will trigger a second operation on each keystroke.
A good rule to keep in mind is that most search interfaces using InstantSearch will trigger one operation per keystroke. Then every refined widget (clicked widget) will add one more operation to the total count.
In case you have issue with the QPS you can consider implement a debounced