This year Microsoft introduced General Availability for Office 365 CDNs. After spending some time working with them and figuring out how they work, I wanted to give my first impressions on the pros and cons of using them.
First things first, what the heck is a CDN?
How CDN's work?
When you are navigating sites on the internet, many of them are using CDNs to host their files such as the JQuery library. When you hit a web page and it serves up this file, the CDN will redirect the request to the nearest geographical server to serve up cached content to the you. The major advantages of CDNs are lower latency and faster delivery of content to user, regardless of where they are geologically.
So, what are Office 365 CDNs?
Well, April 2017 we saw the introduction to the Office365 Public Content Delivery Network (CDN). Essentially, every Office365 tenancy now has the capabilities to create CDNs within their tenancy. Microsoft introduced this concept of public and private CDNs, which allow you to serve content publically, or for publishing features, you could host your static content like images into a private CDN. You can easily set one up and start storing your static files in these CDNs. A tutorial on how to do this can be found here. Below is a quick explanation of the types of files you'd be storing in either a private or public cdn.
Public CDNs can host
- Basically any type of asset you want to store in CDN
Private CDNs can host
- IMG/LINK/CSS urls in classic publishing pages
- Content Search Webpart Display Templates + Images from Query Results
- Picture Library Slideshow Webpart URLs
- Image Fields from REST API calls
- SharePoint Image Renditions
At first, I was really excited! In our Accelerated Intranet Product, we re-use alot of generic icons and images for things such as document types, content type icons, and images from search results and much more. I naively thought, the new CDNs would be great for us. However, the more I dug into the private and public CDNs I realized...
One other scenario that turned me off a bit was using CDNs to host my SharePoint Framework (SPFx) webparts. In order to serve SPFx webparts from a CDN, I HAVE to choose the public option. This is because the private CDN url is dynamically generated by SharePoint and that URL changes periodically. This means that when I am setting up the baseCDNUrl inside the manifests file of my SPFx webpart, there is no possible way to set a private CDN url which is always changing. Now, this isn't the end of the world, I can still host my webparts in the CDN and expect some performance gains for my clients who are using SPFx webparts from my tenancy's CDN. One thing to be aware of, because you are using the public CDN, you are opening up your codebase to the world for that webpart or extension, so be cautious of any proprietary information you may have in your client side solutions.
But all is not lost. While I may not be able to get the performance gains I want by inability to caching response headers, I still get performance benefits when serving content. The main data point for this, is Time To First Byte (TTFB). TTFB is essentially the time it takes for a webserver to respond to a request. During my testing, I have found that the CDN clearly has the lowest TTFB as compared to document libraries...however, it would still be nice to control response headers to cache the content, rather than requesting the content from the CDN on every request. But do not fear, Office365 is baked with alot of great caching features for you. When you request images as you navigate the site, a lot of that content is actually storing cached information for your assets to help retrieve them faster. So while Office365 CDNs do not provide us with all the control we may desire... it is likely better than storing files in document libraries (especially if you are distributing these assets to other tenancies).
If you've played around with Office365's CDNs and have more input, I'd love to hear from you! Let me know if you have any further questions on Office 365 CDNS!