There were several high-level requirements that we wanted to meet when we started thinking about the product's architecture. Among the requirement list we found two of them that were especially important: flexibility and performance. We noticed that these two negatively impacted each other: increasing flexibility reduced performance and vice versa. The system should be as flexible as possible from a look & feel and customization perspective. At the same time it needs to perform as fast as the underlying infrastructure allows. So the aim was to add the minimum amount of workload possible to the SharePoint servers.

From a development perspective, talking about look & feel and customization is basically talking about style sheets and JavaScript. In order to make the system as flexible as possible we needed to publish all our files to the SharePoint Style Library. This way, every site collection on the same farm had the possibility to be different from the others. In addition, it allowed our partners and customers to brand their deployments by using standard tools such as SharePoint Designer without the need to change any file on the server side.

Unfortunately, this decision has an impact on performance. Files on the SharePoint Style Library do not perform as well as when they are deployed directly to the SharePoint Root. In addition, adding files to the list of elements to be downloaded by browsers (especially the old ones) heavily impacted page rendering performance.

We decided to minimize the amount and the size of files the browser needs to download from the Style Library. This way the impact on performance is reduced and at the same time it keeps the customization possibilities unchanged. In order to do so, we created scripts that merge and minimize:

a)      all style sheets in one file and

b)      all JavaScript files in another file

These scripts were included in our Application Lifecycle Management processes. As a result the development team doesn’t have to worry about this issue anymore with every new release. All new and changed JavaScript and style sheets are automatically merged and minimized.

In order to keep the customization possibilities intact, we added two empty files: one style sheet and one JavaScript file. These empty files can be filled by partners and customers with their own customizations overriding any details they need. We finally implemented server components to ensure that these customization files are always rendered in the correct place: just after the Beezy default files. This allows easy overrides. These server components, named as the Beezy Context Helper, are included in the Master Page. They can be used in any SharePoint Master Page to make Beezy work properly with your custom look & feel.

So, flexibility or performance? Both! It is all about finding the right balance between the two of them. We made a great effort in optimizing the amount and size of files while maintaining the customization possibilities intact.

Just request a trial if you want to test for yourself if we succeeded in building a flexible and fast performing social tool for SharePoint.