Last week I saw Will presenting on technical issues associated with SEO. One of the key issues he presented on was site speed. Specifically, the cost of ignoring site speed as a performance and revenue indicator. Will’s own experiences of Distilled’s performance issues (mostly resolved by implementing Cloudflare) were a stark reminder of the importance of building at least a basic knowledge of CDN (content delivery network) implementation.
Why bother with site speed?
We already know there’s a strong business benefit to improving site speed, it’s possible to see figures as high as 1% conversion rate loss for every second in site speed squandered. I presented at a large retailer network company head office on Thursday, comparing the time to render taken by a search result page at Google, Amazon’s home page and their flagship retail site:
Assuming a directly proportional relationship between page load and conversion rate, the potential gain for this site is obvious.
How does a CDN work?
Put simply, a CDN caches all of the objects on your site (for instance; images, JS files and CSS files) and serves them from a location that is usually closer to the request location. This should mean that visitors see a faster page load. By hosting all of your static files on a CDN, it’s fair to assume there’ll be a perceived increase in page load, especially in locations far from your own hosting (assuming the CDN has good coverage there).
I wanted to learn about CDN implementation, so I opened an account with MaxCDN. SEOgadget’s static files are now being served from “cdn2.seogadget.com”.
The end to end set-up process should have taken around 10 minutes. There was a little complication owing to SEOgadget being an SSL site, but I’m pleased to note that MAXcdn will work with your own SSL certificate, provided that you have a wildcard certification that will certify any subdomain (for example: *.seogadget.com).
How to configure WordPress with a CDN
Firstly, open an account with your CDN provider of choice. In MAXcdn, create a new “pull zone”:
You can name the zone anything you like, in our case, “SEOg”. Set the “origin server URL” name to match your domain name and enter your intended custom CDN domain (the location from which your static files will be. Don’t worry, you don’t have to do anything with DNS just yet:
After you’ve created your new pull zone, you’ll see this message:
Take a note of the two domains, your custom domain (cdn.yourdomain.co.uk and the pull zone location generated by MAXcdn – seog.seogadget.netdna-cdn.com). Now head to your DNS control panel:
(This assumes you’re using CPanel to manage your domain a, cname and MX records via your web host. We use TSOhost’s nameservers and SEOgadget has been hosted with them for a long time. If you’re not using CPanel, you’ll have to follow slightly different steps to get to the DNS zone editor at your registrar - it’s very easy though, so don’t be put off if this is new):
Select “Advanced DNS Zone Editor” and the domain you’d like to edit, here:
Protip: Yoast uses more than one CDN address serving JS and CSS separately. This (I think) has the benefit of asynchronous downloading of those files.
Configure MAXcdn with W3 Total Cache
W3 Total Cache is our caching plugin of choice. It’s easy to use, fast and reliable. What’s most powerful about the plugin is compatibility with several well known CDN service providers. Here’s how to set it up with MAXcdn very quickly:
Firstly, select “NETDNA / MaxCDN”. Don’t enable just yet, just click “Save all settings”. Next, head to the CDN configuration from the options along the top of the settings page.
You’ll see a space for your CNAME, so complete that and fetch the API key from MaxCDN here:
As soon as you’re done, click “Save all settings” and select “Test NetDNA” to make sure all is well. The outcome should look like this:
This makes a great weekend project – give it a go!
I quite enjoyed getting SEOgadget set up with a proper CDN. The process is not without its pitfalls – especially if you happen to use SSL to serve your content. Still, with a little perserverence and background reading, it becomes relatively simple (and extremely interesting). The main limitation I faced were problems related to multiple subdomain names (cdn.*, cdn2.*, etc) because of the SSL certificate. We have a wildcard certificate that wasn’t validating easily in the MaxCDN interface. To save time and hassle I elected to creating a separate certificate which was fine for one subdomain but not for multiple addresses.
The performance panel provided is initially very interesting. We’re now serving the US far more locally, (so I might expect our latency to be vastly improved in the US) but, we’re serving the UK and all of Europe from Amsterdam. I suspect that overall performance won’t be improved much in the UK. My initial tests certainly make me feel the improvement locally is marginal, but still improved.
I used Pingdom tools to evaluate overall object loads and got some initially interesting results from New York, with one exception to the observation that we appear quite a lot quicker:
Initial data is almost irrelevant though, so I’ll be watching Google Analytics (site speed report, segmented by country) for a reduction in page loads from our main traffic generating sources over the next few weeks. I’m hoping for an improvement across the board, and certainly no increases in the UK:
I’ve set up a basic alert in Google Analytics to inform me when there’s a week on week decrease in page load – it’s not terribly granular, so we’ll see what happens:
A few useful sources
I’d like to recomend you take a look at these (extremely useful) blog posts:
Image credit: Yi Shiang