My company was working on a project with a SharePoint Online implementation. While developing the site it was noticed that the performance wasn’t up to the required level.
My colleagues and I done some investigation and the results seem to indicate the slow load times were down to the response coming from the server.
We al tried different approaches to try and track down which elements were causing the poor performance by changing the master pages and adding/removing components.
The main issue seemed to related to the navigation options on the site. Our initial setup was to create the site using the structural navigation as this is easy to use and is security trimmed.
When the top navigation was removed we noticed significantly better page load times. After it was identified the top navigation was having an impact it was changed from structural to managed metadata and while this did help it doesn’t doesn’t security trim the navigation and requires the term set to be updated when new sites are added.
After much searching I finally found an MSDN article which backed up the top navigation potentially being a performance problem. The article suggested the managed metadata as an alternative but we had already ruled this out. It did provide a third approach which I had not previously considered and this was to use a search driven approach.
I decided to implement this approach and then compare the page load times with the structural and search driven navigation to see if there was any significant difference. Reading the article I though this will be a 5 minute change but in the end it took me half the morning. Hopefully this blog will provide a more detailed set of steps for anyone looking to implement this approach.
Steps 1 to 4 are simply supplying instructions on how to download a copy of one of the existing master page files. Steps 5 and 6 provide details on how to update the downloaded master page and re-upload it to SharePoint under a different name.
“object doesn’t support property or method “byhierarchy””
I then spent a while debugging through all the code to see if I could indentify what was happening and it seemed to be in the ‘buildHierarchy’ function where it was calling ‘ByHierarchy’ on the collection of navigation items. I checked and there were items being passed to the function.
I looked around and tried the JQuery Linq JS version which comes as part of the download, jquery.linq.min.js, but this didn’t work either. I then had a Google for the error and I found the Source Control where the “ByHierarchy” functionality was added to linq.js. The download provides a Visual Studio project so I opened this and searched for “ByHierarchy” and I found references in “jquery.linq.js” and “linq.js”. It took me a minute to trigger but I was using the minified versions to increase performance but it looks like the new function wasn’t added to the minified version. I double checked this by opening the minified version I upload to SharePoint and searched for “ByHierarchy” but nothing was returned.
After checking the values available the parent site URL seemed to be stored in index 20 so I updated my version of the code, see figure 6
When I then tested the site the navigation started working. I was very relieved at this point but I wanted to make sure everything was functioning as expected so I attached a break point in IE and started to step through the code and this is where I found my final error. In the sample supplied in the MSDN article the “NavigationViewModel” function is used to get the data from either the localStorage cache or it executes the search API query, however in the sample code the checked implemented is always false so never retrieves from the local storage see line 2 in figure 7 below.
I updated this test to check the value of the fromStorage variable, see figure 8, and done some testing and the code starting pulling the results from my local storage instead of doing the query every time.
The final issue with this was noticed by one of my colleagues Tal Peer. Our development environment was a basic site collection with some team sites, however when this was deployed to the production site collections Tal noticed the top navigation was returning additional items. It turns out that the search query will also return app webs which are installed as part of adding apps to the site. Obviously these webs are generally hidden from the end user so they shouldn’t appear in the top navigation. Tal was able to add an additional part to the search query to exclude these app webs by adding “-WebTemplate:APP”, the full query can be seen in figure 9
Hopefully this helps any other people who were trying to implement this functionality. It’s a very good idea to load the navigation from the search index and the basis of the code is there but I just found these additional steps/issues to be very frustrating.
Happy SharePointing 🙂