Want the book? Go get it!This is episode ten in the series “SharePoint Search Queries Explained - The Series”. See the intro post for links to all episodes.
This post covers two main objectives. Firstly how to configure search for any page to make it manageable in the long run, and secondly how to configure search for that same page to make the page show as fast as possible to the end-user.
The main tool used to accomplish this is Result Block Routing in a Query Rule. If you haven’t read about it before, now is certainly the time.
When designing intranet’s in SharePoint Online/2013 the front page is often driven by a lot of Content Search Web Parts, and you quickly end up with 4+ parts on your page.
A typical layout could look something like the image below with seven sections, all driven by search.
If you look at the layout I have highlighted in blue what is above the fold, meaning what is visible before a user have to start scrolling. In the design there are four web parts visible right away, and three which are not visible.
Every search query executed will consume server time, and will impact how quickly data is brought back to the browser. If you load up more data than needed, your end-user get’s penalized and have to wait longer until the page is displayed.
Ideally I would configure the page the following way:
- Nine Result Sources
- one for each section
- one for triggering the visible content
- one for triggering the hidden content
- Seven Content Search Web Parts
- the ones visible will have synchronous loading
- the ones not visible will have asynchronous loading
- Two Query Rules
- one for the visible content
- one for the hidden content
- A Result Type with a matching Display Template for each rendering format
Any change to what you want to show on the page is achieved by either editing the Result Sources or the Query Rules. See S15E04: Result Sources – Scope it out out! for more information and the importance of using Result Sources.
As a sample I will use the Contoso demo site which I set up using https://www.microsoftofficedemos.com. The red squares highlights the search web parts, and as you can see, there is only one search area which is visible upon first loading of the page. So I will leave this web part as is, and orchestrate the last four with a query rule.
The following steps are required for the optimization/orchestration:
- Create an empty result source with no query in it, which will act as the trigger source for your orchestrating query rule
- Create a query rule triggered by the above result source
- I will hard code the queries in the rule and not create separate result sources for this demo
- Add four result blocks to the rule, and give each one a routing name
- Configure the four content search web parts at the bottom of the page to be asynchronous and consume the routed content
The Empty Result SourceCreate a new Result Source named Lazy Loader, and remove the query transformation.
The Query RuleI’ve created a rule named Below The Fold, with four result blocks. Each block has been configured with the amount of results I want back. 10 for video’s which is the max in a block, two for events, five for documents and one for BI.
Web Part ConfigurationFirst, edit the video carousel web part, and click Change Query. When you pick Lazy Loader as the source, the preview to the right shows items grouped per the routing names.
Go over to the Settings tab, and make the web part load results asynchronously.
Save your query settings, expand the Settings section for the web part properties, and pick Video Carousel from the list in Result Tables. RelevantResults is the default table which usually carries your results, and RefinementResults has any refiners configured, in case you’ve skipped this configuration part when you have previously used the CSWP.
For the other search web parts set the asynchronous setting from the Query Builder, ignore the source location, expand the properties for the web part, select results to be provided by the Video Carousel web part, and choose the appropriate routing table for your web part. Now you’re seeing where we are going with the whole routing part. One web part retrieves all the result and passes them on to the other web parts.
In page edit mode you can see information stating the web part is consuming results from another web part.
Default vs. Optimized/OrchestratedNow that you’ve been jumping through hoops and following my direction, it’s time to see the impact of the changes. I used the network monitor in Chrome for my measurements.
- Page Size
- Unoptimized: 186.262 bytes
- Optimized: 135.218 + 41.515 = 176.733 bytes (saving roughly 10k)
- Time to DOM Content Loaded event (10 samples – not scientific)
- Unoptimized: 2 seconds
- Optized: 1.5 seconds
In my opinion the biggest benefit is for me as a search orchestrator, with a potential added benefit for the end-user regarding response time for the page.