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

This post was most recently updated on August 31st, 2022.

3 min read.

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

Table of Contents

The first option would be structural navigation, which is more or less the traditional, easy solution. Without anything else done, this is enabled as the default option on classic SharePoint sites.

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

Managed Navigation

The second option would be managed navigation, which is widely used, and not horribly difficult, but does require extra configuration.

Security trimming not available
- Exception: For SP2013 it’s available for term-driven page links – although I haven’t really seen it work too well ever
Editing experience is more confusing, but at least it’s using the standard termset editor
Not updated automatically (unless you’re using a solution like Valo)
Performance
- On-Premises: Good
- O365: Fine (beats structural anytime there’s over 10 links)

Search-based Navigation

Third option is kind of obscure. Search-based navigation is really not used that much, and for a good reason.

(Kind of) the recommended solution by Microsoft
Security trimming available
Confusing editor experience. I don’t know anyone who likes it!
Bad customizability/extensibility/editability
Performance
- on-premises: Good (as long as search health is good!)
- O365: Good (mind the index refreshes)

Customized Navigation solution

The fourth option is kind of a catch-all: customization.

You see these every now and then, but when modifying Classic Master Pages fell out of fashion (that’s, what, 5 years ago now?), completely customized Navigation solutions seemed to become more scarce. I’m guessing, that with Modern SharePoint, they’ll experience a complete renaissance. For example, in Microsoft’s poster boy -case study Shire seems to use a completely custom-built navigation solution on Modern SharePoint. And can’t blame them – the results look pretty good, and the performance is great.

Not officially supported by Microsoft (and probably never will be)
On Classic, requires hacky changes. On Modern, probably a good compromise
Works exactly the way you want, but customization costs might be high unless you go with a prebuilt solution.

Performance comparison

See below for a real-world comparison between the two most used options – structural navigation and managed navigation!

Performance difference (measured in SPRequestDuration) between structural navigation and managed navigation

	Structural		Managed
Test number	Dozens of sites	Inheritance cut, limited amount of sites	Dozens of sites
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 recent customer case, shared anonymously – thanks!)

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

The difference in performance numbers above comes from Structural Navigation’s built-in issues in SharePoint Online. That might strike some readers as weird since its performance in on-premises environments is typically decent, or even superb.

There’s a good reason for these problems, though.

The issue is caused by the in-memory navigation node cache solution Structural Navigation is based. 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 your request might end up on any of them. In practice, that means, that the server probably doesn’t have your navigation nodes cached, and it’ll have to rebuild the cache for each request. As a result, 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!

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)