SharePoint 2013 encompasses a very fancy query configurator and "builder" in the search results web part. An admin can configure the query to filter down and/or scope the results the search web part will show. This is fantastic news as you no longer need to write SQL to provide a simple solution for client requirements like:
- "search results should only show images"
- "search results should display results from HR department sub site"
Why a result source?
The biggest issue I have with this solution, is that it is almost entirely based on the on the "Local SharePoint results" result source. Which means that the search results web part will load the complete index and then apply the query rules.
I wonder however, why do we put such a load on the system to show the full index and then tell it that we'll only need 2% of the results or just the *.PSD files. We can speed things up by configuring a result source, so the system will only get the results from e.g. only the *.PSD files. This will result in a performance increase because both the result source and the applied query have faster loading times. This is much appreciated considering we're applying more and more front-end design to display templates. Whenever we can save load time, we should always do so.
Another benefit is that if we do want to add extra filters - for example when we have a result source for one site but two search result pages (no.1 = all and no.2 = documents only) - the result source can be applied to both pages. This results in an even better performance on the 2nd page, because the performance increase is applied twice. The loaded index is smaller and the filter is applied to a smaller result set.
Besides all this, there are also functional benefits related to using result sources. First of all, result sources can be applied to all result web parts within the collection of creation. So, when a more experienced admin creates a result source within a site collection, other less experienced admins within that same site collection can apply the result source to result web parts.
A result source will also help with version control and updates. When you configure each search results web part within the web part itself completely, the code is fragmented and can't be updated from a single source or be reused. This is not the case with result sources. These can be updated from the source and the source could be a Site, a Site Collection or a Web application/Tenant.
So to conclude, result sources improve performance of search results web parts, they are scalable and manageable.
When to use result sources?
In theory, a result source can be used for all search result web parts. It'll be a mess however if you create a result source for all detailed searches. A simple guideline is "when a scope is smaller than a site collection, more than three site collections (including my site/search center) are present or a filter is applied". What does that mean exactly? A few examples:
- All results from site HR including sub sites.
- All video files from site collection "Video".
- All results.
- All results from a site collection (total no. of site collection is 3).
In the next post I'll share the details on how to configure a result source.
For now I would like to know if you use result source or why you disagree with using them.