Two and a half years ago I wrote an article on improving the performance of your WordPress website. It was a bit of a hit, and helped lots of my followers on Twitter dramatically improve their page-load times. More than ever, web performance is still an issue, and unfortunately is often overlooked. Things have moved on a bit since when the original article was written and I thought it might be worthwhile revisiting this topic to include present day theories and solutions. Without further ado, let's get to it!
Why should I care?
Let's cover this point again, shall we?
In 2012, the popularity of mobile devices on was on the rise and RWD (responsive web design) was the flavour of the month due to the growing drive behind Twitter's Bootstrap framework, along with Foundation, Inuit and the rest. It appeared that whilst everyone was thinking mobile (in terms of design and layout) performance for mobile was left by the wayside. Great, so you were able to style up that sidebar to work nicely on mobile, but quite frankly, if the site is going to take 6 seconds to load, no-one's going to give a rats arse how good it looks. Why? Because they would have been long-gone. Adios impatient mobile visitor!
Whilst it's safe to assume the majority of desktop and laptop internet connections are capable of decent download speeds, some mobile visitors are still experiencing the equivalent of dial-up days. Sure, mobile operators are improving their networks, but if you travel on the train from Havant to Waterloo, you get near-as-dammit zilch in the form of network coverage (at least on O2).
So, in summary; Web performance is just as valid as before, especially if you're targeting mobile visitors to your site. Even if you assume 90% of your traffic to your site is on desktop, having a fast page-load time isn't going to annoy your visitors, is it?
The United States of Performance
Broadly speaking you could categorise the areas you should focus on into three states of your web site; Quick-Win Nevada, Intermediate Idaho and Complex Colorado. I'll reuse these catchy states below :
Quick-Win Nevada
Image Sizes
I covered this in the first blog post, so I won't go over this too much, but don't doubt the amount of fluff that image editing tools add to image files. All that irrelevant info can be trimmed to convert your overweight two-tonne jpgs to slim, six-pack ripped equivalents, all without losing visual appeal. Previously I mentioned Yahoo's Smush.It service (WordPress plugin), which still runs, but if you can use tools like CodeKit to automate this for you too. I believe there's a grunt task you can add too, which is always nice :)
CSS & Javascript Compression
In a similar vein to the original blog post, you'll get performance boosts if you can reduce the amount of "stuff" that needs to be sent from the web server in the first place. CSS and Javascript compression isn't a new topic, but it's been made infinitely easier with the advent of tools such as CodeKit (a second mention, it's almost like i'm being paid for this, but i'm not) and command line pre-processors like Grunt. On the assumption you work with WordPress, the Roots theme has an incredibly useful Grunt file that would save you a LOT of time. Worth taking a look, even if you don't use the theme framework and roll your own variation of it.
Avoid Bloat in the Original Site-build
Forgive me if the title is a little too obvious, but it's all to easy when developing a WordPress site to add complexity and rely heavily on bloated scripts and css frameworks. If you're wondering what I mean by avoiding bloat let me give some examples of how you can avoid adding pounds around the preverbal mid-rift:
- Use Twitter's Bootstrap? Instead of creating your own CSS file to overwrite their default settings, why not brave adjusting their own base files, using LESS or SASS? It'll result in less CSS overall, and thus, less fat! Whoop!
- Love all those jQuery plugins? Try looking for lighter versions of popular plugins, if your client only requires something simple. For example, the jQuery Cycle plugin ships a "lite" or "cycle zero" version if all you need is a basic cycle plugin. Be gun-ho and hack plugin code to do only what you need, and cut out the fat.
Use and correctly setup a caching plugin for WordPress
Resurrected from my original blog post, but still as relevant as wearing a seatbelt and keeping your mouth shut whilst using a toilet-brush! The big players in the WordPress plugin scene appear to still be WP Super Cache and W3C Total Cache. In my experience, WPSC is much easier to setup, and provides a much more straightforward setup process. It's all down to personal preference, but my recommendations are to use it's "mod_rewrite" caching method, and to pre-load the cache every 720 minutes. On average, we've seen between 30 - 70% web-page performance increases from using that plugin along with other methods in my original, and this post.
Intermediate Idaho
These suggestions are a little more technical, but can result in some hefty performance increases. If you're feeling brave, give them a shot.
Be Less Database Intensive
WordPress provides developers with a whole raft of handy shortcodes and functions that you can use in your themes, and they really are quite brilliant (at times). However, prolific use can result in a lot of repetitive communication going back and forth between your theme and the database. For example its my understanding that every time you call bloginfo(), it results in a database call to fetch the relevant info, such as theme folders. It'll initially look at the Site Url, stored in the {table_prefix}_options table and then run a series of funky regex conditions to spurt out the end result, such as the URL to the themes folder. If you're using that function a lot, you can save the strain on the server by passing the value of a commonly used function to a variable within PHP, that you can re-use instead. For example :
<?php
$theme_folder = get_bloginfo('template_url');
?>
<h1>The theme is held here <?= $theme_folder ?> </h1>
So this simple block would fetch the template url from the database once, despite using it x number of times in the theme file. This is especially useful in the header of a WordPress site, or footer, if you're still loading in scripts and assets outside of wp_enqueue_script().
Switch your Development Method to use CSS / Asset Pre-compilers
This belongs in the intermediate Idaho section, because it isn't an easy jump for those that are comfortable writing everything by hand. Sure, i'll even go so far to say it isn't for everyone, but on the whole it'll apply to a majority. By switching your development technique to use services such as LESS, SASS, Grunt, node or CodeKit (fourth mention...) you'll reap more benefits than I can articulate in a blog post. Tools are cropping up everywhere at the moment to help web developers and their workflow. You might be wondering why using SASS or Grunt will help with performance, but with the example of Roots WordPress theme framework, their grunt file automatically joins css and javascript files respectively, strips whitespace, compresses files and optimises images. In short, it does all the tasks I would consider basic, but without lifting a finger. It'll help you to keep things skinny.
Complex Colorado
These are not by any stretch of imagination "quick fixes" but they do make a more considerable improvement to performance, or at least the delivery of your site.
Break it off with Apache, or configure it correctly!
For the less technical, Apache is a web server and it's sole task is to be told what to fetch, run off and find it, and then bring it back to the browser. It's not hard, and it should be a fairly quick process all-in-all, but unfortunately when using shared hosting, or generally crappy hosting, Apache may not be configured to max performance. At Codepotato, we did an "out of the box" comparison of Apache to it's arch nemesis, Nginx. By "out of the box" we setup both server technologies on an identical virtual server, and didn't do any additional performance tuning. Literally installed and run. Using Blitz.io we slammed the VPS with traffic to see exactly how many concurrent users the servers could handle. Apache bummed out at 80, whereas Nginx carried on right up until the mid thousand point and I think struggled at the 1500 mark. Sure, Nginx caches everything by default, but it demonstrates how the technology behind the scenes might be slowing down things too.
Improve your Hosting
This could be easily labelled "cop-out" but if you're running on a shared hosting provider, you might find that simply moving your site over to Digital Ocean (warning: referral code alert!) could provide a hefty performance / load-time improvement. We moved the Codepotato site at the weekend to it's own VPS, and it now loads 33% quicker than it did on grid hosting with TSO Host. From no cache, most of the pages on our site load in sub 500ms. VPS's are cheap as chips nowadays, but our recommendations are Digital Ocean (starting at $5 a month) and Linode (around $10 a month).
Use a CDN, or Move Assets to a Subdomain
Web browsers often have their own in-built limit to the number of connections they have open with a URL at any given time. If your entire site uses www.yourdomain.net then some browsers will slow down the loading of the site by the fact that they'll only have six active connections at any given time. You can enjoy a nice performance hit by moving assets such as JS, CSS and images to a Content Delivery Network (CDN) or even just a subdomain of your main domain. CDN's are a little more tricky to setup, and there are numerous plugins for WordPress that'll help you do it, but it has to be said that it might be overkill for your average WordPress site. Why not just create an "asset.yourdomain.net" subdomain, and link to that for your assets. It'll mean that web browsers will allow six connections to that subdomain, and six to your main web address used by the site. In theory, it's dead simple, but a little more complex to setup.
Blimey, wall of text!
Yes, but wasn't it worth it?
I would love to see your before and after page-load scores, so feel free to post your results from following our original and newer blog posts below.
Thank you for reading, and I sincerely hope it's helped!
UPDATE -
A couple of tweeters have got in touch since publishing this post with the successes they've had. Great to see that it's helping!
https://twitter.com/dnburgess/status/471655407140610048