Introduction

At work the last couple of weeks, I’ve been looking at how an Azure Public CDN (Content Delivery Network) and the newly-released SharePoint Online CDN can improve performance for geographically dispersed users in Office 365. There are a few important factors to consider, but generally I think these are great options for organisations with users experiencing latency in Office 365 due to their location.

What is a CDN?

A CDN takes static web content used by web pages on SharePoint, web sites, and other custom web applications (such as images, fonts, JavaScript and Style Sheets) and stores it at strategically placed locations around the world. In an Office 365 set-up without a CDN, this content gets served to the client/user from the base location of the Office 365 tenant, be that North America, Western Europe, or wherever Office 365 was originally set-up. This results in terrible network latency for geographically dispersed users thanks to the large distances involved. But after a CDN is implemented, this content can be served to the user from their nearest data centre, as opposed to the primary tenant location. This provides much better performance and a much improved experience for users, regardless of their location.

What options are available?

Azure provides two ‘flavours’ of CDN: the Public CDN, and the Private CDN. The Private CDN (also known as the SharePoint Online CDN) can only cache assets stored in SharePoint libraries, and checks the user’s access to the original location of the asset before serving it to them from the CDN. The Public CDN allows broader access to assets cached in the CDN, meaning it can be used for all manner of web applications, and cache files hosted outside of SharePoint.

So in other words, the new SharePoint CDN can be used to serve assets from SharePoint Online to other SharePoint Online pages, while the Public CDN can be used for everything else and isn’t purely for SharePoint.

Further constraints around the types of files that can be cached by the SharePoint CDN drives how you should architect your CDN(s) for Office 365. The SharePoint CDN can only cache files of the type .gif, .ico, .jpeg, .jpg, .js, and .png, while the Public CDN can cache files of the type .css, .eot, .gif, .ico, .jpeg, .jpg, .js, .map, .png, .svg, .ttf, and .woff. The key gap for the SharePoint CDN is style sheets and fonts, which means it should be used primarily for ‘author’ content, such as images (e.g. News Article pictures in a publishing intranet scenario). The Public CDN should be used for design assets such as fonts and CSS, as well as assets originated from or served to non-SharePoint applications.

SharePoint CDN

At a high-level, the SharePoint CDN works as per the below diagram:

There are a few things worth explaining from this diagram:

Origin Libraries

These are the SharePoint Libraries set-up via PowerShell as the sources of files to serve via the SharePoint CDN. It is possible for the CDN to cache content from all libraries under a specified path by using a relative URL meaning that, for example, the Style Library within each site collection can be specified as a source, provided it exists under the same path in each site collection.

An important note about the SharePoint CDN is that it relies on a published major version of a file before that asset will be cached. Just something to keep in mind, depending on the type of version control applied to a library configured as an origin.

Referring Pages

In this context, referring pages are any pages on SharePoint Online that reference assets cached by the SharePoint CDN.

For the SharePoint CDN to work, the referring page must be a SharePoint Online page. This means that pages hosted outside of SharePoint Online (such as custom Azure Web Apps) cannot utilise the SharePoint CDN. However, provider hosted add-ins embedded on a SharePoint Online page will be able to make use of the SharePoint CDN.

URLs for SharePoint CDN content are dynamically generated and automatically rewritten so that the asset is retrieved from the nearest point of presence server location, rather than the main Office 365 tenant server location. URLs are automatically rewritten for the following elements in SharePoint Online:

• Classic Publishing Pages will rewrite IMG and LINK URLs.
• Content By Search web parts will rewrite display template JavaScript files and thumbnail images provided in query results.
• Image Renditions.
• Hyperlink fields on lists and libraries.
• Picture Library slideshow web parts.
• Image fields served back to the user via the SPList REST API.

So in theory, you shouldn’t have to rewrite much of your existing functionality if you opt to use the SharePoint CDN for your Office 365 environment, though of course, it would be a good idea to check.

One major gap at the time of writing is that SPFx client side web parts cannot utilise the SharePoint CDN. This is due to the way these web parts have to reference static URLs (and – as noted above – the URLs generated for cached SharePoint CDN content are not static). But this functionality is coming soon to SPFx.

Authentication/Authorisation

When a browser requests assets stored on the SharePoint CDN, user access to these assets is considered. In other words, the user must have at least Read access to the Origin Library the asset is stored in, or the image/script will not load on the page. Though, to be fair, this is the case regardless of whether the CDN is being used to serve content to the user, so not much should change here in terms of permissions you need to grant to origin libraries.

Public CDN

The diagram below summarises the components of the Public CDN and the relationship between them:

Origin Libraries

Any location can be set as the origin for a Public CDN, including external SaaS services, Azure Web Apps, and SharePoint Server on-premises libraries (and SharePoint Online libraries).

Referring Pages

Referring pages can use the Public CDN URLs to retrieve assets from the CDN location closest to the user. These pages can be from any application, including SharePoint and an Azure Web App.

Authentication/Authorisation

The Public CDN, by definition, allows anonymous access to cached assets and does not check a user’s authorisation against the origin library. Basically, any person out on the internet who can guess the URL of your content will see it if it is cached by the Public CDN. This has obvious security implications, though there are ways of mitigating this (see later in this blog post).

The Underlying CDN Technology

Microsoft haven’t really built a CDN themselves, and instead use third parties to deliver the capability that can be managed and configured under the Azure umbrella. Microsoft offers three alternatives for its CDN capability:

• Akamai (Standard)
• Verizon (Standard)
• Verizon (Premium)

Feature Comparison

The table below compares the functionality provided by each CDN supplier. For brevity, the comparison table only includes items where the capabilities differ between suppliers. The full list of capabilities, including ones where all three provide comparable services, are available here and here.

Feature	Description	Standard Akamai	Standard Verizon	Premium Verizon
Points of Presence	Number of edge locations geographically dispersed around the world.	~2200	80+	80+
Custom domain HTTPS	Enables the delivery of secure content via SSL to improve the security of data in transit.		✓	✓
Asset pre-loading	Pre-loads assets so that there is no delay the first time they are requested by a user.		✓	✓
Core analytics	Shows usage patterns for the CDN, including bandwidth, hits, and data transferred.		✓	✓
Advanced HTTP reports	Generates detailed data about the CDN, including map-based geography reports on usage.			✓
Real-time stats	Provides data on bandwidth, connections, cache statuses etc. in real-time.			✓
Real-time alerts	Provides notifications about the performance of CDN end points in real-time.			✓
Rules engine	Customise how HTTP requests are handled, change the behaviour of the cache, set rules for mobile devices and implement URL redirects.			✓
Token authentication	Only requests with certain criteria in the URL will be served, e.g. only requests from certain hosts will be served.			✓
Origin Shield	Provides an extra caching layer between CDN edge servers and the origin to improve security.		✓	✓
Support	The support processes and models in place to handle incidents and queries.	Phone and Email support, Community Forum	24/7/365 Phone and Email support	24/7/365 Phone and Email support

 

Price Comparison

The costs for the CDNs are based on outbound data transfers in GB per month, and differ by region. There is also a sliding scale of cost whereby data becomes less expensive the more you use.

Akamai (Standard) and Verizon (Standard) are identically priced as below:

Outbound Data Transfers	NA + EMEA	Asia Pac	South America	Australia	India
First 10 TB/month	£0.0649 per GB	£0.1029 per GB	£0.1864 per GB	£0.1044 per GB	£0.1268 per GB
Next 40 TB (10-50 TB)/month	£0.0597 per GB	£0.0969 per GB	£0.1491 per GB	£0.1007 per GB	£0.0969 per GB
Next 100 TB (50-150 TB)/month	£0.0448 per GB	£0.0895 per GB	£0.1342 per GB	£0.0895 per GB	£0.082 per GB
Next 350 TB (150-500 TB)/month	£0.0299 per GB	£0.0746 per GB	£0.1193 per GB	£0.0746 per GB	£0.0746 per GB
Next 524 TB (500-1,024 TB)/month	£0.0224 per GB	£0.0597 per GB	£0.1044 per GB	£0.0709 per GB	Contact MSFT
Next 4,096 TB (1,024-5,120 TB)/month	£0.0187 per GB	£0.0522 per GB	£0.0969 per GB	£0.0671 per GB	Contact MSFT
Over 5,120 TB/month	Contact MSFT	Contact MSFT	Contact MSFT	Contact MSFT	Contact MSFT

 

While the Verizon (Premium) offering is a little under twice the price of the standard services:

Outbound Data Transfers	NA + EMEA	Asia Pac	South America	Australia	India
First 10 TB/month	£0.1268 per GB	£0.1864 per GB	£0.3727 per GB	£0.2087 per GB	£0.2535 per GB
Next 40 TB (10-50 TB)/month	£0.1118 per GB	£0.164 per GB	£0.3168 per GB	£0.1789 per GB	£0.2162 per GB
Next 100 TB (50-150 TB)/month	£0.0969 per GB	£0.1417 per GB	£0.2684 per GB	£0.1491 per GB	£0.1827 per GB
Next 350 TB (150-500 TB)/month	£0.082 per GB	£0.1193 per GB	£0.2236 per GB	£0.1268 per GB	£0.1566 per GB
Next 524 TB (500-1,024 TB)/month	£0.0746 per GB	£0.1044 per GB	£0.1938 per GB	£0.1081 per GB	Contact MSFT
Next 4,096 TB (1,024-5,120 TB)/month	£0.0671 per GB	£0.0895 per GB	£0.1677 per GB	£0.0932 per GB	Contact MSFT
Over 5,120 TB/month	Contact MSFT	Contact MSFT	Contact MSFT	Contact MSFT	Contact MSFT

 

If you work out the costs of this based on your current trends of data use, it soon becomes clear that the SharePoint CDN costs are negligible and almost a no-brainer to implement. Similar for the Public CDN, at least in the internal/enterprise space as opposed to publically accessible web sites.

Performance

Performance between the three options is very similar, though I would suggest you conduct your own performance tests to see how it would work in your environment.

Non-Functionals

Microsoft offers a SLA-backed 99.9% uptime guarantee for the CDN (both SharePoint and Public). There are diagnostic logs and analytics to help troubleshoot CDN issues and analyse traffic and bandwidth usage. The big thing to focus on here though are the security implications:

Data Privacy and Compliance

Microsoft pretty much washes its hands of any data you choose to cache in the CDN. When you’re setting up your CDN in PowerShell it will display disclaimers similar to the following:

Both the SharePoint CDN and Public CDN are Azure features built on 3^rd party applications with privacy and compliance standards that differ from the commitments outlined by Microsoft in the Office 365 Trust Centre. Data cached by the local servers for both the Public and SharePoint CDNs does not conform to Microsoft Data Processing Terms and is outside the Microsoft Office 365 Trust Centre compliance boundaries.

In other words, your data is no longer under Microsoft’s jurisdiction once it enters the CDN, as the underlying capability is provided by third parties. I haven’t managed to find any info on the web about what standards Verizon and Akamai do offer around data privacy and compliance, but will update this post if I find some.

Given the content cached in the CDN is likely just JavaScript, images, fonts, and style sheets, it is unlikely there is anything sensitive in there, but it’s still something to consider before switching on the CDN.

Anonymous Access to the Public CDN

As noted in the previous section, the Public CDN allows any referrer to access its cached content anonymously. Again, due to the nature of the content stored in the CDN, this is unlikely to be a problem (particularly given you can restrict who has access to upload assets to the origin library). However, if you need to provide an extra security wrapper around the Public CDN, you are only really left with one choice: the Verizon (Premium) offering, which supports Token Authentication.

Token Authentication can be used to check things like the referrer of specific requests (so you can, for example, limit it to just your SharePoint Online/on-prem estate), country, and a myriad of other things.

Constraints

Here are a few of the constraints associated with the Azure Public CDN and SharePoint CDN technology:

Files such as aspx pages or Master Pages cannot be delivered via the Azure CDN, only the static elements and client side code that is embedded on pages. This means Master Pages must still be deployed per site collection in SharePoint Online.

The SharePoint CDN can only cache files of the type .gif, .ico, .jpeg, .jpg, .js, and .png. This covers the most common image file formats and icon files, plus JavaScript files (which are called in order to run custom client side code on some SharePoint Online pages). The most crucial file type that the SharePoint CDN cannot cache is .css, which will be used on every single page of a publishing portal and in many collaboration scenarios in SharePoint online too.

The Public CDN can cache files of the type .css (Style Sheets used to change the look and feel of a site), .eot, .woff and .ttf (fonts), .map (image maps), and .svg (scalable images/vectors) in addition to the file types outlined for the SharePoint CDN.

All files of type GIF, ICO, JPEG, JPG, JS and PNG stored in origin locations will be cached by the SharePoint CDN. If a file of this type is placed in an origin library, it cannot be excluded from the SharePoint CDN at a granular level.

Using the SharePoint CDN means that the referring site must be a SharePoint Online site, and the user must have authorisation to view the location where the static files are stored.

The SharePoint CDN can only be used for SharePoint Online, not SharePoint Server on-premises, or the on-premises elements of a hybrid implementation of SharePoint.

URLs for content served via the SharePoint CDN are dynamically generated and can change on a regular basis. They therefore cannot be hardcoded into custom scripts, applications, or SharePoint Framework Client-side Web Parts (the newly recommended way of designing and building web part functionality in SharePoint).

My Recommendations

So that’s a whistle stop tour of the Azure Public CDN and the new SharePoint CDN capabilities. Here are my recommendations if you’re thinking about enabling either of these services in your organisation:

1. Make sure you (and your security team) are comfortable with the disclaimers Microsoft put around data privacy and compliance.
2. Plan around using the SharePoint CDN for ‘author content’ like images (plus JavaScript), and the Public CDN for everything else. You will likely need a blend of both CDNs to deliver a holistic solution.
3. Configure SharePoint CDN origin libraries with relative URLs so that any library located at the same place within a site collection (under a given path) can be cached. This has information architecture implications, as you do not want your asset libraries in different places within each site/site collection or you will have a massive admin overhead maintaining the CDN.
4. Use the Verizon (Premium) offering if you want to allow anything other than completely anonymous access to Public CDN content.
5. Keep in mind that SPFx web parts cannot – at the time of writing – utilise the SharePoint CDN.
6. Conduct some performance baselining before implementing the CDN so you can demonstrate how much improvement has been made post-implementation.
7. Ensure you put suitable cache expiration policies in place for CDN content.
8. Think about consolidating content to be cached by the Public CDN into a centralised library or Azure Web App. This will help you control who has access to update these assets, and ensure that multiple versions of the same content do not proliferate across the environment.

I would state that enabling the SharePoint CDN is a bit of a no-brainer for most organisations. It’s simple to do and offers massive performance benefits to any global company using Office 365. But I would also state that some form of planning/design is also required to ensure your company is comfortable with Microsoft’s disclaimers and whether or not you’re willing to allow anonymous access to your content in the Public CDN.

Thanks for reading.