This is the first of a three-part post with my take on what is happening behind the scenes when you view a page in SharePoint Online. Whilst the title describes the focus to be SharePoint Online, I do stray into other areas of Office 365 like Yammer and Exchange. The posts are based upon a similar summary that I produced for our network analysts to help them put their analytics in context and help them focus on the elements that we could influence. I’m not a network specialist so I’ve pitched this at a level that I’m comfortable with and one that hopefully makes the subject a little more accessible for all.
Anatomy of a SharePoint page
When you view a page in Office 365 the elements are coming from across the globe and are assembled in your browser to create the page. This is best illustrated by an example using a fictional Tenant based in Western Europe and assuming your Tenant is based Microsoft’s Dublin datacentre:
Imagine if you where based in Glasgow and viewing a News Article in your Intranet. The article contains a Yammer feed. Then:
- The Suite Bar, at the top of the page, is being served to you from London (which is your nearest Content Delivery Network point of presence – more about this later). A short hop of 345 miles using IP by Avian Carrier.
- The notifications that appear under the bell icon in the Suite Bar are being served from Dublin as this is where your email lives. (247 miles)
- The code that powers the SharePoint page is coming from London.
- The content of the News Article is coming from Dublin as this is where your content lives.
- The Yammer feed is being served from Chicago (Yes, that’s right, from over 3,665 miles away!)
If we extended the scenario, and you are now viewing the same page from an office in Adelaide, you can substitute London with Melbourne (a mere 452 miles away). However, the Dublin content will still come from Dublin and Yammer will still come from Chicago. That’s 10,317 miles to Dublin and 9,913 miles to Chicago!
My example is a vast over simplification so it’s worth saying at this point that associated with each element there are a number of transactions like checking your permissions to view the content, making sure you have a valid access token for Office 365 etc. Completing these transactions add to the time it takes the overall page to load.
Office 365 is architected in such a way that common, frequently used elements, like the Suite Bar, are distributed to points around the world for local collection. ‘One-off’ elements like the image in the page are not distributed as it is more efficient to serve them on-demand. Yammer and Sway are exceptions and they only live in one location. In the case of Yammer, the application is very complex and so, at the moment, it only resides in Chicago. Yammer might look basic in terms of functions and features but under the hood there are complex algorithms running that help tailor it you to etc. and this makes it a complex application to replicate in other data centres. You can find out where your data lives using ‘Where’s my data’.
“Ye cannae change the laws of physics”
Clearly, geography has a significant impact upon performance. All Office 365 content is securely transmitted via the Internet and the path it takes is often not the most direct. If your network has a hub and spoke arrangement, then additional distances are added to and from the hub. Undersea cables that carry the vast proportion of all internet traffic, snake their way around the world joining countries and continents and adding miles to the routing. Whilst light travels at over 186,000 miles per second, Scotty often reminded Captain Kirk “Ye cannae change the laws of physics” and so there will always be a time premium the further away you are from the data. Microsoft overcome this to a degree by serving common, frequently used elements via a Content Delivery Network (CDN) for local collection. Items like page content including image renditions are not served via a CDN as it is more efficient to serve them on demand. However, for the Content Delivery Network to be effective the content should be served from a point that is closest to you. If your internet traffic is routed via your company’s regional data centre, say in a hub and spoke model, then sometimes the CDN content is served from a location that is close to the datacentre rather than the CDN end point that is closest to you. Elements like DNS geolocation can affect your email experience as it connects you via a Microsoft data centre that is close to where you actually are and then retrieves your email from your tenant datacentre utilising a fast datacentre to datacentre connection. This subject is covered in more detail in a Microsoft case study entitled ‘Optimizing network performance for Microsoft Office 365’. In the case study they highlight techniques like ‘split tunnelling’ and ‘on-sites edges’ as methods for improving performance. The case study also highlights the need to use the appropriate type of search web part and consider the site navigation methodology.
“Ah but it’s the size of the page…”
Returning to the example at the start it is possible to classify the elements in a typical Intranet page and detail the page payload sizes for the first (with the cached cleared) and subsequent visits (using cached content). It is also possible to identify the elements that you can influence (highlighted in bold) and the ones that you cannot. The figures in the table are real as I’ve taken them from the home page of our Intranet and they include the additional load generated by our analytics solutions Web Tuna and Google Analytics.
[ Source of reference for the CDN details ]
Our contribution to the overall payload is:
- First visit: 1161.94Kb or 15% of total for visit
- [1395.75Kb less the Microsoft files of 260.42Kb]
- Second and subsequent visits 156.729Kb or 79% of total for visit
Of all of the files that make up the Home page it is worth noting that ‘O365ShellG2Plus.js’ is the largest single file at 862Kb and it is produced by Microsoft. This file is one of the key building blocks used by SharePoint. The largest single file created by us is a minified JavaScript file which is 174Kb in size. This is not the largest element of the page content as this is the underlying SharePoint theme file at 260.42Kb which is produced by Microsoft.
Stay tuned!
In the second and third part I focus upon the processes that make significant contributions to the performance of a SharePoint page.
buildbod.com 