Algolia returns the total number of hits and facet values with every set of results. Sometimes, to limit the impact of this heavy operation on search performance, these values aren’t exhaustive.
For the most part, non-exhaustivity isn’t a critical problem. When hit and facet counts reach such a large amount that this becomes a problem, users aren’t looking for exact numbers, but for a general idea (e.g., 1,000 rather than 1,042).
There are ways to limit the effects of non-exhaustive facet counts.
Non-exhaustivity is a performance optimization issue, shared by all search engines.
First, let’s look at what’s going on when you get approximate hit and facet counts. When you type a query into Algolia, we compute a list of results that you can paginate. Then, based on this list of all possible results, we start computing hit and facet value counts one by one. We try to compute everything in advance, but this is not always possible, like when the count entirely depends on the user’s query. At a certain point the Algolia engine will stop counting and makes approximations on the rest of the dataset to keep your searches fast.
In most cases, this isn’t an issue. You might show rounded counts, like ~200, or hide the count altogether. However, we understand that this isn’t ideal for every use case.
There’s currently no way to bypass this behaviour. Ultimately, working on the performance of your index is the best option, because a high performing index means there’s more time for the engine to compute the correct facet counts.
Here are a few suggestions to improve the performance of your queries, and therefore limit the cases where approximations are used:
- Reduce the index size as much as possible.
- Remove unnecessary records, and attributes that aren’t useful for the search experience.
- Keep the list of searchable attributes as small as possible. Instead of having all attributes searchable (the default behavior), manually define a list of
searchableAttributesto only search in relevant attributes. Also remember that the longer the attribute, the costlier it is to search into it.
- Make sure that facet attributes that you only use for filtering are set as
filterOnlywhen declaring your
- Make sure
hitsPerPageis set to a reasonable number.
- Reduce the number of attributes for faceting. We recommend keeping this list as small as possible, with only the strict minimum required for your search UI.
- The response when performing a
exhaustiveobject which contains the
nbHitsfields. You can use them to manage non-exhaustivity on the front end, indicating to the user that the values are approximations.
- Reduce the number of filters or precompute some filters in your records when possible.
- Reduce the usage of CPU-intensive features (facets, many filters, geo, grouping, or
optionalFilters) as much as possible.
- Explicitly set
attributesToSnippet(if applicable). You can even set some of them at query time.
- Consider entirely removing attributes with massive content (such as descriptions) from