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 the user know that the network is suboptimal is by displaying a progress indicator, which will avoid them being frustrated by your application and lets them know the network delays are to blame.
We provide such a mechanism with
InstantSearch: see the section on Loading indicator.
Optimize build size
In some cases, you might not need to use our widget system, and just want to use the core parts of InstantSearch. In that case, you can decide to download only specific parts of the library.
1 2 3 4 pod 'InstantSearch', '~> 5.0' # pod 'InstantSearch/UI' for access to everything # pod 'InstantSearch/Core' for access to everything except the UI controllers # pod 'InstantSearch/Client' for access only to the API Client
1 2 3 github "algolia/instantsearch-ios" ~> 5.0 # for access to everything # github "algolia/instantsearch-core-swift" ~> 6.0 # for access to everything except the UI widgets # github "algolia/algoliasearch-client-swift" ~> 7.0 # for access only to the API Client
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 add 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
HierarchicalMenu, and a
RefinementList, then each keystroke will trigger one operation. But as soon as a user refines the
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