CDN Buster

CDN Invalidation – Why and How


Content Delivery Network (CDN) is a collection of geographically distributed servers that mirror and serve you static contents (images, JavaScrip/CSS files, movies etc.) to your readers much faster than your own blog server can. It speeds up your blog tremendously:

  1. It serves a large part of your website payload from servers that are close to the readers. CDN servers are specifically optimized for such contents.
  2. Since your resources on the CDN have different address (URL), the reader’s browser loads the statc content and the dynamic content (from your blog server) in parallel, enhancing the user experience.
  3. The load on your blog server goes down becuase it is no longer serving a large part of the page content, which improves its performance.

In short, if you are not using a CDN yet, you should. It is very easy to set it up if you use any popular cacching plugins (such as WP Super Cache or W3 Total Cache). Most CNDs are of the so-called Origin Pull kind, where the CDN server automatically pulls a file from a location (typically your blog itself) whenever it is asked to serve a file it doesn’t have in its cache. This is usually a one-time operation, which is slow. The CDN then proceeds to mirror the file on its servers all over the world. Thereafter, whenever the file is requested, the file is served instantly from a server closest to the reader.

Once you use a Content Delivery Network (CDN) such as Amazon Cloudfront to speed up your blog, you will come across instances when you update a static file (a style or image file, for instance), but your readers keep getting the stale file from the CDN. No amount of cache clearing on your blog server is going to help because the stale file is in the CDN. The only way would be to “invalidate” the file, which will signal the CDN to pull a fresh copy from the origin location. But this necessitates you to log on to the CDN server, locate the file, generate a proper invalidation request, and wait for it to percolate to all the mirrors. And it often costs money.

In order to address this issue, I wrote a plugin called CDN Buster, which offers a much easier alternative. You enter a Version String in the option below, and append the same string where you define the CDN address in your caching plugins, such as WP Super Cache or W3 Total Cache. This way, when your reader loads a page, he is looking for a different file, and your CDN server will query your blog server for it, where this plugin will intercept the query and serve the modified file from the original location. Thus, the modified file will get loaded on your CDN and all will be well.

The Pro version gives you more tools to control how the invalidation works. You can set it to automatically update the CDN settings in your WP Super Cache or W3 Total Cache plugin. Or you can change origin pull location on your CDN server to a generic string (e.g. cdn-bustor-* where * can be anything) without touching your blog settings to invalidate the cache. You can even specify the file names or file types to further control your invalidations. CDN Bustoer Pro is a complete CDN invalidation tool for managing any origin pull networks.

But if you do not want to use my plugin to handle CDN invalidation, and if you have SSH or FTP access to your server, you can do the work yourself in a couple of steps.

First logon to your server (or access it via FTP or cPanel File Manager), and navigate to your blog root.
Create a symbolic link to the blog root folder with a name like, say cdn-v01

ln -s . cdn-v01

Now logon to your CDN server (AWS, if you are on Amazon CloudFront, for instance), and find the distribution origin. This is likely to be your blog address. Add the origin path /cdn-v01 and you are all set. It may take a while for the CDN to complete the invalidation, but it is cheaper and less labor-intensive than actually requesting each file to be invalidated.

The same trick can be accomplished by adding a RedirectMatch directive in your .htaccess file, if you are on an apache server. But the symbolic link method is cleaner and will work across all servers.

RedirectMatch 301 cdn-v../(.*).$ /$1/