You’ve probably already seen the awesome news that AkturaTech is now 100% cloud. All our servers now exist in a magical fairy land which is as awesome as it sounds.
Seriously, setting up for the cloud is so much fun. All the different little components to play with and set up are like toys for grown ups. We didn’t even want to outsource it because starting up entire servers and setting them up in a few clicks was just too awesome to miss. Yeah, I get that I’m a nerd.
We ended up going with Rackspace. While Amazon has a much bigger feature set, Rackspace support is top notch and for some reason I just get a better feeling about them. I’ve learned to go with my gut feeling. Still, I researched the crap out of both of them and found that many people were getting better speeds, preferential CPU cycles and just all round better performance out of Rackspace. Things might have changed by the time you read this but this is what we went with.
For some silly reason, I thought that moving to the cloud would mean everything would just be faster. In hindsight this is really dumb. The old dedicated server had 8x the memory and 8x the CPU of our original cloud server which meant it served up pages super quick. The problem was that EVERYTHING went through the one server so it could get bogged down easily.
Checking Google Analytics, our site speed didn’t look very pretty. A quick test with the awesome tool at Pingdom verified that ChimpRewriter.com was slow as hell.
Fast forward a few hours, and Pingdom is reporting a load time of under a second most of the time. Oh yeah!
Wanna know how a slow site can seriously impact your business? Check out this page from KissMetrics. It should serve as a wake up call.
This is what we did:
- Install W3-Total-Cache (already done in this case)
- Take the time to go through every single setting and work out whether it should be on or off, and what option to choose. There are tons of people who have already done this, so just search for “w3 total cache setup guide”, “optimal settings” and stuff like that. There are a ton of options so this was one of the most time consuming bits
- Make sure HTML compression is enabled
- Minify script and CSS automatically using disk enhanced cache. Don’t minify inline script and CSS if you have a responsive site!
- Preload page cache by pointing it at your sitemap.xml or sitemap-index.xml
- Browser cache is important, set long expirys on all your objects, greater than a week according to Pingdom
- As you go through settings, re-run the speed test to see if what you’re doing is working. Clear all caches each time and do the test TWICE. The first time will take a huge amount of time while the cache plugin does its thing. They also give you an analysis with recommendations on what to fix up i.e. browser cache, minify etc
- When you’re all done, run the speed test again. By this point you should see “images” and maybe “other” as the big killers in load time. Remember to run speed test twice.
So after this, load time was already less than halved from 6s to about 2.5s. Given we already had a Rackspace account, it made sense to set up a CDN as well to host all the static content. This includes the minified scripts and CSS which are two big killers.
Note: Highly recommended to do a database backup before this as the plugin modifies your posts!
- Set up a container at Rackspace (or bucket at S3)
- Make it public and get the link
- Get your API details from CDN
- In W3 Total Cache General Settings, choose your CDN
- On the CDN settings tab, punch in your API details
- Export the media library
- This is by far the biggest pain in the ass. If you have been uploading images via FTP rather than the built in WordPress Media Gallery you will probably have some issues here
- Try using the built in media exporter in W3 total cache. The button will show at the top of your wordpress panel as a notification. Give it some time, it can be a bit slow.
- You may have to manually clean up some links if it imports the same image multiple times like it did on ours. We just deleted the dups from the media library then modified the posts where the plugin modified the links
- Do NOT tick all the CDN options yet, else your site will break
- Add the CDN host URL without the http:// and click test. It may take some time for DNS propagation
- Go through the CDN tab and click all of the “export XXX” buttons i.e. attachments, theme files, wp-include. You don’t need to do custom files unless you add some
- NOW tick all the CDN options to host attachments, theme files etc
- Run the speed test on your site to generate required caches (or hit locally from a browser that is not logged in – if you are logged in to WordPress it will not generate cache depending on your settings)
- Run through your site on your logged in browser and check pages look ok. If things are broken, just uncheck the CDN options and empty all caches. You might have to modify some links to images, import stuff to the media library manually or whatever. This process is the most time consuming part of the CDN cutover.
- Open a browser that is not logged in (like Chrome in Incognito mode) and run through your site. This will be the CDN hosted version of your site. If all looks good, congrats!
- Run the speed test again. It gives a breakdown of all the content loaded. Check that the relevant content is all loaded from your CDN URL, not your original domain.
- It will also alert you to missing files in the content list with a little yellow triangle. If there are missing files, again you’re going to have to go through and see why they haven’t been uploaded to the CDN. Make sure they are in the media library or the theme directory and re-link
Now your speed should be like lightning!
We’ll monitor conversions and bounce rate over the next few weeks and see how it goes…