As posted last week, I ran into some challenges with implementing Azure CDN. The lack of cache control in Azure CDN combined with the fact that WordPress doesn’t including any cache control information by default meant that my site was cached for a week with no ability to invalidate it. So after a week of waiting until the cache expiry ran out, I was ready to try again! This time, I was able to successfully migrate with the following steps.
Step 1: Ensure You have HTTP CACHE-CONTROL Headers
By default, WordPress only includes HTTP CACHE-CONTROL headers on the admin pages, which means that the CDN never releases the cached pages until its default expiry (which in the case of Azure CDN is 7 days). In order to fix this, I updated the header.php file to include some HTTP CACHE-CONTROL information.
header(“Cache-Control: public, max-age=900, s-maxage=900”); // HTTP/1.1
This includes the HTTP CACHE-CONTROL directive to expire the page after a maximum of 900 seconds (e.g. 15 minutes).
<configuration> <system.webServer> <staticContent> <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="3.00:00:00" /> </staticContent> </system.webServer> </configuration>
In this example, the maximum age is set to 3 days instead of the CDN’s default of 7 days.
Step 2: Test Your Page with Fiddler
Fiddler is a really good testing tool for Azure in a number of scenarios, but in this case it provides a method to test the HTTP headers and ensure that the HTTP cache information is coming through. Here is fiddler testing my home page:
Step 3: Create the CDN
Creating the CDN is easy – you just go to the Azure Portal and create a new CDN and point it at your existing Azure Web Site.
Note that it takes about an hour for the CDN to cache all your content, so until this happens you’ll see an error page.
Step 4: Enable HTTPS and Query String
You can enable HTTPS so that cached content is served even with HTTPS and you can turn on Query String which enables the CDN to view each query string as a unique request. For example, with Query String turned on www.microsofttrends.com?version=1 is treated as a different page as www.microsofttrends.com?version=2.
Step 5: Test Your Caching in CDN
Once your CDN is setup, I would recommend testing your caching approach by making a change to your site and ensuring it flows through as expected based on your caching rules. As noted above, in my case, the home page should be cached for a maximum of 15 minutes.
In order to test this, I made a minor change to the first sentence of the last post I wrote. In the “live” site, it now says “Office365” instead of “Office 365”.
When I access the CDN version, I still see the original cached version.
And now, 15 minutes later, I see the updated post:
Step 6: Change Your Domain Name to Point to the CDN End-Point
The last step is to change your domain name CNAME record to point to the CDN end point instead of your Azure Web Site.
First, you need to remove the domain name record from your Azure web site (this will take your site offline). Second, you need to move your CNAME record in your domain name manager (I use GoDaddy to manage my domain and they provide an admin tool to do this). Finally, you need to add your domain name into the CDN through the Manage Domains feature.
MicrosoftTrends is now running successfully through CDN with the appropriate caching rules working as expected. Running tests against the site shows a significant improvement in speed, especially from places such as Japan, China, India, Australia, etc. which have typically high latency to the US data centers.