Together, both SharePoint and Azure are a powerful duo. SharePoint forms the heart of knowledge management and collaboration tools, whilst Azure powers an organization’s cloud services strategy, both of which can be combined in multiple ways to resolve common business obstacles.
Many of the services offered by Azure can be used to extend and improve the operation of SharePoint, both on-premises and in the cloud. One of the services offered by Azure is the Content Delivery Network (CDN), an Infrastructure as a Service (IaaS) solution which provides all distributed cache infrastructure globally to enhance software operation.
What is Azure CDN?
Azure CDN enables you to cache information that changes infrequently. Currently, Azure CDN has servers in more than 70 cities around the world, the full list can be found here.
Alternatively, if your desired location isn’t on the list, you can use the Verizon and Akamai networks to reach those areas. These servers are also high-performance and have oversized bandwidths to support large workloads.
CDN works in the same way as local caching in the DotNet Framework, and also similarly to SharePoint On-prem and online internally. What we mean here is that it stores files in a specific way so when a user requires one of them, they can access and send it without using IOs from the hard disk or recovering them from the databases. The advantage of Azure CDN and its globally distributed servers is that information can be found much closer to the end-user, which decreases the time it takes to download it.
Azure CDN and SharePoint
Although SharePoint natively contains different cache mechanisms, they all occur locally on the farm itself, both for SharePoint Server On-Prem and in SharePoint 365 online. This helps to reduce the load on farms but also doesn’t decrease the response time for users if there is a long distance to the farm. An example of this is if the SharePoint data center and client were on different continents. And, although SharePoint 365 has its own CDN, the dedicated Azure CDN has a bigger capacity and finely-meshed network for optimal performance.
Bob German in his blog Choosing a CDN for SharePoint client-side solutions made a comparison between hosting files in a SharePoint Library, using the SharePoint native CDN and the Azure CDN in the below picture. As you can see, the TTFB (Time To First Byte) of the CDN Azure is considerably faster than the SharePoint CDN.
The above picture was taken from Bob German’s blog.
Example of using Azure CDN with an SPFx WebPart
- Create the Azure infrastructure:
- From your browser, start the Azure Management Center. If you don’t have an account, you can create a test account valid for 30 days
- Create a Resource Group in Azure to contain one Storage account and the CDN Profile
- Add a Storage account in the Resource Group giving it a name and location. The Standard performance account will suffice. Use all other default properties:
- Add a blob to the storage. Click on the Containers section of the Storage Account, and then use the +Container button. Assign it a name and select Blob (anonymous read access for blobs only)
- Now you need to create a CDN Endpoint. In the Containers section of the Storage Account, click on Azure CDN, and then create a new Endpoint indicating its name, pricing tier (here you can select the Microsoft, Akamai or Verizon networks depending on your geographical requirements; the price is the same), and the name for the Endpoint
- When the Endpoint creation is completed, it will appear in the list of Endpoints
- Click on the Hostname to go to the properties window
- The connection between the SPFx WebPart and the CDN cache is made through the Origin hostname. If you run the WebPart, all the files you use are copied to all Azure CDN global servers automatically (global replication can take about 15 minutes. The Endpoint hostname is the CDN URL for the WebPart
2. Create the SPFx WebPart
- Follow the instructions given by Microsoft to create a development environment for SPFx if you don’t have one, and also those to create a basic SPFx WebPart.
3. Configure the WebPart
Open the package-solution.json file in the config folder of the SPFx solution. Update the includeClientSideAssets property value as false to prevent the client-side assets being packaged inside the final sppkg file
- Open the deploy-azure-storage.json file in the config folder. Use for account the Azure Storage Account name, for container the name of the container (blob) in the Storage Account, and for accessKey, from the Storage Account window, click on Keys and copy the first key found
The .json file will be similar to the next picture.
- Open the write-manifests.json file from the config folder and for the cdnBasePath property use the Endpoint hostname (found earlier) plus the container name
4. Deploy the WebPart:
- Build the assets required to upload to the CDN provider using the command gulp bundle –ship from the PowerShell console
- Upload the files to the Azure CDN using the command gulp deploy-azure-storage. After the command has run, the files can be found in the Azure blob
- Package the solution using the command gulp package-solution –ship. The. sppkg file with the package is in the sharepoint\solution directory
- Upload the package file to the SharePoint App Catalog. The package will point to the Azure CDN, as the following image shows
- Install the WebPart on one page and open the browsers Developer Tools. In the list with files that form part of the page, are the files uploaded to the Azure CDN and the timing statistics
Load times depend on the customer’s location and distance to the Azure and Office 365 datacenters. In the example, both the customer and the data centers are located very closely, so the difference is impossible to determine. If the client and the Office data center are on different continents, Azure CDN will use a cache close to the client and the differences will be more prominent.