Writing High Performance SharePoint Applications: A Case Study

Do you need to learn how to write fast, efficient, high performance SharePoint applications? Here’s a great case study on a recent client success. With a little ingenuity – and a LOT of experience – we were able to satisfy a company with very particular demands for their SharePoint-based site.

This client recently tasked us to write a SharePoint application with a strict requirement of sub-two second page loads. While two seconds is plenty of time for simple pages, some of these contained up to ten distinct sets of data – almost like dashboards linking to multiple sources of information. The client’s user interface was completely customized, as well, containing no traces of SharePoint from the end user perspective.

To make matters more difficult, they requested that all of their data be served up via server-side code. Plenty of experts told us this wouldn’t be possible without some serious data caching or lots of client-side code, neither of which were allowable.

We immediately decided that we could:

1. Use a custom master page based on a minimal master page template.
2. NOT use web parts, which are slow and cumbersome to position precisely.

The data we were consuming lived inside SharePoint and externally in an SQL database. We wanted to write modular code, similar to writing visual web parts, but we didn’t need all of the end user customization that a web part offers. We considered using External Lists to bring the data into SharePoint, but we decided that strategy wouldn’t offer the fastest possible performance.

Our solution:

1. Use custom pay layouts.
2. Use a custom minimal master page.
3. Embed custom user controls within these page layouts. To reduce the amount of code, we also created multiple views within each control, as well as control parameters to dictate how each control should render its data.
4. Use the Entity Framework to access data living in the SQL server. We created custom views in the database to make it easier to consume that external data.
5. LINQ to SharePoint. We automated the entity model creation by adding the SPMetal call directly from Visual Studio with a custom-input XML that limited class creation.
6. Use client-side code for external services we didn’t control: Facebook, Instagram, SmugMug, etc.
7. Set daily syncing to bring data over from the external systems into the SQL server, where data latency wouldn’t be an issue.

Because we were so concerned with performance, we tested immediately with large data sets. Our tests results were even better than expected, and on our most demanding page, the load time was less than one second. Data below the fold took longer to load, but even that bit of latency was unnoticeable to the end user.

Moreover, our LINQ-heavy code was modular and easy to maintain. All of the data queries used similar patterns, and there was no need to write complicated CAML queries. Our code also made some of the more complicated filters very easy. For instance, the site is completely customized to the specific user following login.

Ultimately, our client was amazed with the speed of the end product – a fully responsive website built on a SharePoint 2013 farm that delivers a wide variety of content.

Are you interested in learning more about building high performance SharePoint applications? Or are you looking for a team of dedicated experts to do the heavy lifting on your behalf? Either way, read more about our Professional SharePoint Consulting and Development services today!

HubSpot Call-to-Action Code end HubSpot Call-to-Action Code