Inconvenient Office 365 CDN and the SharePoint Framework

4 min read

The Office 365 CDN can help you improve the performance of your SharePoint Framework solutions. Unless you configure it incorrectly in which case your solutions won’t work at all.

Better performance for everybody

A while ago Microsoft released Office 365 CDN as a part of Office 365. Without any additional costs, Office 365 customers can benefit of Microsoft’s global infrastructure and have their files served as quickly as possible.

What’s convenient about the Office 365 CDN is its simplicity. To publish files, you simply upload them to a document library in your SharePoint Online tenant designated as a CDN origin. Once you upload the files, SharePoint will automatically publish them to the CDN for global distribution.

While the Office 365 doesn’t offer any advanced configuration capabilities, it’s good value for your money. If your organization is globally distributed, using the Office 365 CDN could help you significantly improve the performance of your portal. Assuming that you configured it correctly, of course, because if you didn’t, you’re about to experience some hard to explain trouble.

Office 365 CDN and SharePoint Framework

After the release of the SharePoint Framework, the latest model for extending SharePoint, Microsoft quickly noticed an increasing need for an easy way to deploy files that make up SharePoint Framework solutions. SharePoint document libraries are not optimized for serving static assets, and Azure CDN might be too much for organizations that just want to use SharePoint. After introducing the Office 365 CDN the problem was solved, but there was still room for improvement.

In a recent version of the SharePoint Framework, Microsoft added the ability to include scripts and other assets inside SharePoint Framework solution packages (.sppkg). When deploying the solution to the app catalog, SharePoint would automatically extract these files and deploy them to a special location in SharePoint. This not only eliminates any manual steps but also allows you to deploy the same solutions on different tenants without having to change the URLs, which is perfect for ISVs. But there is also another benefit.

If you have the Office 365 CDN enabled in your tenant, files deployed from SharePoint Framework packages will be automatically served from the CDN, which simplifies the deployment steps even further. What’s great about the setup, is that SharePoint automatically detects if the CDN is enabled or not. If it’s enabled, SharePoint loads SharePoint Framework files from the CDN. If it’s disabled, it will load them directly from the SharePoint document library where they are deployed. All that without you having to change the URLs. But there is one caveat.

Inconvenient Office 365 CDN and SharePoint Framework solutions

By default, the Office 365 CDN is disabled. You can easily enable it using the Office 365 CLI or the SharePoint Online Management Shell. To enable the public CDN using the CLI you would execute:

When enabling the CDN for the first time, SharePoint will automatically create a number of CDN origins. You can check which origins are available, again using either the Office 365 CLI or the SharePoint Online Management Shell. To see the available origins using the CLI, execute:

Following are the origins, that SharePoint will automatically create for you:


But here is the caveat: if you have the Office 365 CDN enabled in your tenant, but for some reason the */CLIENTSIDEASSETSorigin is not configured, you won’t be able to use your SharePoint Framework solutions! If you try to add a client-side web part you’ve built, you won’t find it in the toolbox. And the worst part is that you won’t get any errors either, which could cause you spend hours if not days trying to figure out what is wrong. So if SharePoint automatically creates the */CLIENTSIDEASSETSorigin, how could it be missing?

When enabling the Office 365 CDN using the SharePoint Online Management Shell, you can choose to enable the CDN without provisioning the default origins. Alternatively, someone might have deleted the origin, either by accident or on purpose. Either way, the origin would not be configured and your SharePoint Framework solutions would not be working. So how to fix it?

Add the missing origin required by SharePoint Framework solutions

If you notice that the Office 365 Public CDN origin required by the SharePoint Framework is missing in your configuration, you can easily add it using the Office 365 CLI or the SharePoint Online Management Shell. To add it using the CLI, execute:

It will take a few minutes for SharePoint to create the origin and propagate the files, but once the configuration completed, you will be able to use your SharePoint Framework solutions again.


SharePoint Framework heavily relies on static assets. Optimizing how they are loaded can help you significantly improve the performance of your intranet. While you don’t have to use a CDN to have your assets served optimally, if you choose to use the Office 365, double check that it’s configured correctly.

Furthermore, if you want to keep your Office 365 tenant governed at all times, check out our Customization Governance Solutions here at Rencore.


This blog post has been originally published on Waldek’s blog.

Waldek Mastykarz

Waldek is a Microsoft Office Development MVP and Head of Product at Rencore. He reinforces our product development adding loads of business experience from working as a SharePoint consultant for more than 10 years. Waldek is passionate about what he does and shares his enthusiasm through his blog and as a regular speaker at conferences and community events all over Europe. Recently, Waldek joined the SharePoint Patterns and Practices (PnP) Core Team to help developers make better use of the SharePoint and Office 365 platforms.