Improve Performance
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.
See our Loading widget to implement this pattern.
Optimize build size
) and checking their requestSeqNumber to get the latest request count.
Enabling the Search cache
Any Index is able to cache the search request’s response to avoid duplicate queries (for example when the user types f, o, o, then deletes o; it would directly display the results it got for fo).
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);
</section> –>
%>
Queries Per Second (QPS)
Search operations are limited by the maximum QPS (the allowed number of queries performed per second) of the plan.
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 HierarchicalMenu, and a RefinementList, then every keystroke will trigger one operation. But as soon as a user refines the HierarchicalMenu 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 SearchBox.
