The effect of using Managed Navigation instead of Structural on SharePoint Online


 Have you ever noticed that your SharePoint site just gets slower and slower? That’s probably because the performance of Structural Navigation is absolutely horrible, especially vs. Managed Navigation. This blog post includes our findings about the issue, and I also include some explanation of the reasons behind the difference and a simple comparison to Search-based navigation.

Structural Navigation

  • By far the most customizable and tweakable option
  • Easy to edit for editors/admins
  • Good performance on-premises, as long as WFEs are powerful, site structure isn’t changed periodically, caching is used and master page hasn’t been modified to include riculous amount of levels
  • Abysmal performance on O365, if there are over 10 items in the navigation
  • Security trimming is automatic

Managed Navigation

  • Security trimming not available
    • Exception: For SP2013 it’s available for term-driven page links
  • Editing experience is more confusing, but at least it’s using the standard termset editor
  • Not updated automatically (unless you’re using solution like Valo)
  • Performance
    • on-premises: good
    • O365: fine (beats structural anytime there’s over 10 links)

Search-based Navigation

  • (Kind of) the recommended solution by Microsoft
  • Performance is good both on-premises and O365
  • Security trimming available
  • Confusing editor experience
  • Bad customizability 

Performance comparison

Performance difference (measured in SPRequestDuration) between structural navigation and managed navigation
  Structural Managed
Test number Dozens of sites Inheritance cut, limited amount of​​ sites Full-blown navigation
1 5,77 3,23 1,62
2 3,43 3,13 1,29
3 6,23 2,48 1,65
4 5,25 2,55 0,92
Average 5,17 2,8475 1,37

(Numbers are from a customer’s production environment – thanks for the anonymous contributor!)

So, why is Structural Navigation so slow on SharePoint Online?

The difference comes from Structural Navigation being awfully slow in SharePoint Online. That might strike some readers as weird, since its performance in on-premises environments is typically decent.

The issue is caused by the in-memory navigation node cache solution Structural Navigation is based on. This cache is located on WFE servers – and in an on-premises environment, you typically have only a few servers that you might land on. With any luck, those servers already have your navigation nodes cached, as you’ve probably visited them before. In SharePoint Online there are thousands of WFE servers that serve any given tenant, and you might end up on any of them. That means, that the server probably doesn’t have your navigation nodes cached, and it’ll have to rebuild the cache for each request. Understandably, this causes huge load times.

Sean McDonough has an awesome article with an equally awesome graphic about this – you might want to check them out, if the topic interests you!

Sources and references

  • This data is from Valo deployments.
The following two tabs change content below.
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.

Leave a Reply

Your email address will not be published. Required fields are marked *