Regular readers will know that for the last month and a bit, we’ve been in a never ending battle of wills against servers and load times.
Our first major change was implementing Amazon’s S3 service to serve static files from the site. It helped, but in the end we ended up moving to Rackspace Cloud Sites to finally get a grip on the server issues we were having.
Since moving last Monday, the site has mostly purred, and since I’ve been looking for ways to improve load time again. One thing that did surprise me that as much as the files served from Amazon S3 were being served well, there was some latency there, and it wasn’t as quick as I’d hoped for, even if it did help decrease the load on our core hosting setup.
If you know about CDN’s and how to set them up, you should probably stop reading from this point, because the following isn’t going to be a detailed, or perhaps completely accurate technical description.
What is a CDN
A Content Delivery Network (CDN) is a network of server locations that deliver your content in multiple locations. Traditionally, if someone visited your site, they’d pull all your locally hosted static files (images, js, css) off your server directly. With a CDN setup, they pull those static files from their closest CDN, so for example if you were in Europe, the static files would be served from a local node of the CDN network. What this means is that your static files are quicker to load because they are served from a closer location, and although you’re still serving some files (php etc) from your original server, the end user gets the page quicker.
Each node in the CDN takes a copy and cache’s that for local traffic. The bigger the CDN network, the quicker load times are for most because there are more closer nodes to serve the static files.
The reason we’ve implemented Amazon Cloudfront was one of ease of use: we already had Amazon S3 set up, so it was simply a matter of 5 minutes and bingo: CDN. A number of people have pointed out to me that given the site is on Rackspace, we have access to Rackspace Files, which uses the Limelight CDN network. The Limelight CDN network is superior as a CDN, not only because they have an Australian presence where as Amazon doesn’t, but sheer global presence.
However, the WordPress tools to set up Rackspace Files aren’t as easy to use as those available for Amazon, and we already have files on S3, which cut out the need to transfer a ton of image files across as well. Ultimately Rackspace Files (with Limelight) will offer a better solution, but for now we implement what we can with the tools at hand.
To setup Amazon Cloudfront with WordPress, you need S3 to begin with: read Using Amazon S3 for image hosting with a WordPress blog. The cool thing about Cloudfront is that it pulls data from pre-existing S3 files, so there’s no transfers required, it’s just a matter of setting things up.
Paul Stamatiou has the best guide for setup here, and I won’t attempt to replicate it all (he has pictures as well). The key points though:
– Go into Amazon Web Services and enable Cloudfront
– Using S3Fox, select the bucket (folder) on S3 you want to add to the CDN, right click, and pick manage distributions
– Add a name for the distro (Amazon Cloudfront), tick the “enable the distribution” box, pick a CName (in our case, turbo.inquisitr.com) and click create distribution
– you then get a resource URL. Using the instructions in our S3 guide (or via your host on how to setup a CName), using the details given, setup a Cname for your URL (turbo.yourname.com) pointing at the Cloudfront URL.
This is where I did it differently. Presuming you’re on S3 and you’ve got something like images.yourname.com for your S3 content, download the CDN Rewrites plugin here and install it. Once that’s setup, you simply need to tell it to redirect any URL from images.yourname.com to turbo.yourname.com (and this presumes you’ve got your files on S3 to start with, if you haven’t, this won’t work.) Select the options as fit, for example images, css, js etc…
Besides some little bugs with a thumbnail plugin we’re using (not related at all to Cloudfront), our page load times have been cut by between 40% and 80% (the former, only when we’re loading a full image to then make the thumbnail.) On one test, Pingomatic went from 8.7 seconds before to 2.9 seconds after…and that’s staggering. I don’t get the full effect in Australia because there’s no local CDN, but even I can see the difference here.
If you’re under load stress, and what to make you site load quicker, a CDN might be right for you.