Filterable Columns Based on Office 365 Shared Term Store Are Very Slow…

We have a folder in our intranet for all our sales pursuit documents.  This document library contains all our pitches, presentations, proposals, etc. that we use to pitch work to our prospects and clients.  We added some columns using SharePoint Managed Metadata Term Sets so that we could tag these files and we created a view that allows for filtering against these columns. 

Here is an example of our Industry column:

image

We love the idea of using these columns to filter a master list of documents.  In general, the interface works well and you can click on any of the terms and it will filter your list view down to those documents tagged to that term.

Unfortunately, we were finding the rendering of the page was very slow – e.g about 15-20 seconds to load a single page.  After spending some time adjusting the view by adding and subtracting some columns, our tests provided some interesting results:

  • Columns based on standard columns are very faster to render. 
  • Columns based on term sets that are stored locally to the site collection are reasonably fast to render. 
  • Columns based on term sets that are stored centrally in the Managed Metadata Service are very slow to render.

image

We have removed this term set from our view for the moment to speed up the page rendering and we’re investigating…

  • Thanks for this post. I just fixed an extreme example of the issue; 5-10 minute O365 response time. Here’s a work around. Create a new field to use as a surrogate/copy or mirror. Using a workflow initialize the surrogate field; e.g. if the Term is “Client” create a surrogate called something like Client_For_Use_In_Views. Use the surrogate in all views instead of the Term. The penalty is storage. The benefits are rendering performance (response time) and Search. 11/19/2014 ~B