Sitecore Search: Should we use Where or Filter in our search query?

Sitecore Search: Should we use Where or Filter in our search query?

default avatar
Thought byRosen Petrov
November 20, 2019
Sitecore Where Filter Blog Header

The FFW team works with more than just Drupal and WordPress. We've built some award-winning Sitecore solutions as well, and in this Sitecore blog series, we'll be sharing our insights on refining Sitecore's search functionality to enhance the user experience.

Where vs Filter

If we take a look at the IQuertiable extension in Linq to Sitecore we’ll see Filter there. But what’s the difference between using Filter and Where? To understand that, we should go a bit deeper into Solr Query (q) vs Filter-Query (fq) usage.

Using Filter-Query parameter in search is very useful to maximize the performance, it defines a query that can be used to restrict the superset of documents that can be returned, without influencing score, it caches the query independently. Filter-Query can be very useful for speeding up complex queries since the queries specified with fq are cached independently of the main query. When a later query uses the same filter, there’s a cache hit, and filter results are returned quickly from the cache. Another difference is that Filter-Query only stores document IDs. This makes it very fast to apply the filter to include/exclude documents. A normal query can perform the exact same function, but it has a very complex scoring system to determine "relevance".

So, criteria specified in Filter-Query do not affect the ranking. Thus a query can be made faster by converting some of its criteria into a filter-query parameter. On the other hand, fq criteria count towards the filter-cache and can increase the size of filter-cache. So one should try to balance these two factors to get the best of both the worlds.

Note that when q and fq are both present, it is efficient to apply the fq filters first. Each fq parameter would yield a bit-vector of document-IDs (and this might come from the filter-cache, thus being very efficient). All bit-vectors are then intersected to get the document set on which q can operate. This is better than running q first on all the documents and then applying fq to the result set.

If you enjoyed this blog post, please don’t forget to check the Sitecore Search Series: Your Complete Guide to Performance Improvement blog series for more good tips! If you need help with a Sitecore site, let us know.