Just because you can, should you use the Office 365 CDN

Office 365 CDN is a compelling option for hosting your static assets, but how good is it actually?

CDN for the masses

A while back already Microsoft released the Office 365 CDN: a convenient way to have your static assets delivered as quickly as possible. Using Microsoft's existing global infrastructure, the Office 365 CDN allows you to easily publish your files directly from SharePoint document libraries to servers across the globe. If your organization is spread over different geographies, you will likely benefit of using the Office 365 CDN as it significantly lowers the download times of static assets. But there is even more.

SharePoint - the new file storage platform

In one of the recent versions of the SharePoint Framework, Microsoft introduced the ability to include asset files inside the solution package. When such package is deployed to SharePoint, asset files are unpacked and deployed to a specific document library in SharePoint. That library also happens to be configured as an origin for the Office 365 Public CDN. So if you chose to use the Office 365 Public CDN in your organization, by default, all SharePoint Framework assets will be served from it. But just because you use the Office 365 CDN, doesn't mean your assets are delivered to your users in the best way possible.

What's important for delivering static assets

SharePoint Framework solutions consist of two main pieces: a manifest with the solution metadata and a number of script files containing the solutions code. Depending on which JavaScript libraries you use, and how you choose to bundle your client-side components, these script files could be even a few MBs. So how efficiently users can download them, determines for a big part how fast these solutions will load on pages.

Network and distance

One of the first things that impacts how fast users can download assets is the network quality and the physical distance between the user and the server hosting the assets. Because CDNs use a globally distributed network, you can safely assume that both are acceptable.


Another thing that impacts how fast files are downloaded, is the protocol used to serve them. In the past, most servers used the HTTP 1.1 protocol which couldn't deal all that great with many requests. This is why in the past we used to use techniques such as image sprites and combining multiple script files into one to download few bigger files instead of many smaller ones. Nowadays, servers using HTTP/2 can significantly better serve small files which makes combining files unnecessary.


When serving static assets, a common way to lower the amount of data sent over the wires, is by compressing them. Web browsers support loading compressed assets natively with virtually no performance impact. Because scripts are text files, compressing their contents can decrease their size significantly. Some servers are capable of compressing asset files dynamically, which is very convenient for users who don't need to worry about it themselves.


After downloading files, web browser can store them in its cache. On subsequent requests, the browser will first check its cache, and if the files are still valid, it won't download them again. As you can imagine, loading files from the local browser cache is incomparably faster than downloading them over the network. For how long files can be cached, if at all, is determined by the response headers set by the server hosting the files.

Allow caching by proxies

Many organizations use proxy servers in their network to control and manage the network traffic. Proxy servers, depending on their configuration, are also capable of caching files requested by users inside the network. Allowing static assets to be cached by proxy servers can lead to a great increase in the perceived performance of SharePoint Framework solutions: if one user loads a solution, it will be cached both on the proxy server and in the local browser cache. If another person in the same network requests the same file, it will be served from the proxy server without having to leave the organizational network.

Now that you know what impacts the performance of SharePoint Framework solutions, how good does Office 365 CDN implement these settings?

Free but at what price

Office 365 CDN is very convenient to use. You can enable it with a single command and start using it directly in your organization. But if you look at its configuration, there's room for improvement.

Assets served by the Office 365 CDN are automatically compressed. This is good news, since downloading compressed assets is faster and doesn't add unnecessary load to your network. But your users will be downloading these assets a lot, because all files served from the Office 365 CDN expire within an hour. There is no way you would be updating your SharePoint Framework solutions that often, and yet, every hour users will have to redownload the assets. What adds to that is the fact, that if you're using proxy servers, they won't be able to cache assets served from the Office 365 CDN.

So while it comes with no additional costs, ask yourself: do you really want to use the Office 365 CDN? Because if your organization is not distributed over the globe, you could get better results from a dedicated server at very little additional cost. Cost, that could easily outweight the cost of users waiting for your portal to load.


comments powered by Disqus