This is the final part of a three-part post where I present my take on what is happening behind the scenes when you view a page in SharePoint Online. In the first part I discussed the components that are needed to assemble a SharePoint page and how geography has effect. In the second post, I focussed upon the processes that make significant contributions to the performance of a SharePoint page. In this post I’ll continue the focus from part 2 and in particular highlight a feature that will affect choices made in the design of solutions like Intranets in Office 365.
Search powered pages
A common design pattern, especially in Intranets, is to use search parts to render content, for example to serve content that is relevant to the user viewing the page. The calls made by search add a premium to the page load time with the premium divided into two major elements: time to fetch the results and time to render them. Our Intranet home page makes extensive use of search parts and so it has been designed to make a single search call with the results then rendered in different parts in the page. This reduces the time to fetch the results with the process to render them optimised in code. In other areas of the Intranet the pages can contain multiple search parts which in turn will make multiple calls but the performance hit is mitigated as the remainder of the page content is relatively light and simple and therefore the page load times are not unduly impacted.
Works great on premises, fails you in the cloud
The design of our Intranet takes advantage of the SharePoint Rendition Engine to serve images. Renditions work by serving up different versions of images based on pre-defined image dimensions. This is especially useful in areas of the Intranet such as the Home page where a single image could be repeated twice within the page: as a carousel image and as a thumbnail in the carousel. This avoids situations where the full resolution image is downloaded, potentially multiple times, for resizing through JavaScript or CSS. An image rendition is created by SharePoint the first time someone visits the page holding the image. Subsequent requests for the same image, say when another person browses to the page, are much faster as SharePoint simply serves the stored rendition rather than creating and serving it. The SharePoint server responsible for the creation and storage of the rendition is the ‘Web Front End’.
When comparing performance between SharePoint 2013 and SharePoint Online there is a significant difference in the number of ‘Web Front Ends’. The result is that for SharePoint Online there is a delay in the serving of the image rendition. In a SharePoint 2013 environment there is a limited number of ‘Web Front Ends’ and so, in a relatively short period of time, they would have been visited by a large number of people with the result that the caches on each server will hold a complete set of renditions. In SharePoint Online there are many ‘Web Front Ends’, in fact probably too many to be visited a sufficient number of times and so each one will only hold a partial set of renditions. Additionally, for SharePoint Online, Microsoft have had to make some performance choices that result in the caches in each ‘Web Front End’ being very small (so cannot hold many renditions) and they are regularly cleared. This results in a high number of ‘cache misses’ when a rendition is requested in SharePoint Online i.e. it looks for the rendition but one is not available. A ‘cache miss’ forces the ‘Web Front End’ to create and serve a new rendition as if the server was being visited for the first time. This adds a minimum premium of 3 to 4 seconds of page load time. This post by Chris O’Brien goes into more detail and in a follow up post he offers a potential solution (which incidentally we are considering implementing) .
Wrap up
I hope you have found this mini-series useful. To recap:
My summary from the first post was that we can only influence the Page Content as the reminder is controlled by Microsoft. However, we can make improvements through understanding where the content is served from. These improvements should optimise access to and transmission of content from the local touch points of the Microsoft Content Delivery Network as well as from the datacentre that is hosting the tenant.
In the second post I focussed on the consumer vs corporate user experience as well differences between web browsers. Each one has a major influence on performance or the expectations around performance.
In the final part I focussed upon design choices used in SharePoint Online and in particular SharePoint Renditions which makes a significant negative contribution to the performance of a SharePoint page. The impact of its contribution may affect your design choices say when creating an Intranet in Office 365. I strongly recommend reading the posts by Chris O’Brien for more detail [Posts #1 and #2].
buildbod.com 