So you have configured your site exactly the way you wanted it, maybe lots of content too, and you’re rocking a lot of visitors. But there’s always that slight nagging at the back of your head, like something’s not quite right, not quite perfect. It seems to be running a little slow.
Performance optimisations may be optional for non-monetised blogs, but it is often critical for sites that aim to please their visitors and generate revenue. It has been shown that there’s a direct correlation between the site speed and the revenue generated from the site. According to Google, taking more than 4 seconds to load your site’s pages is no good.
But performance optimisation is not easy, especially if you’re just starting out. Over the years, I have experimented with many performance optimisation methods and workflow. This post represents years of experience that culminates in a proven (at least from my own experience) workflow to dramatically increase a WordPress site’s performance. Page load time reduction of up to 75% is not unusual.
But keep in mind though that this is not a tutorial. What I am presenting is an overview of the workflow that I have adopted and refined over the years. Because of the technicalities involved in implementing each of the optimisation methods, explaining how would be overwhelming for an article. But, if anything else, it should give you a good starting point to embark on your own journey and experimentation for optimising your site’s performance.
1. Optimise your theme
Optimising a site starts from the coding stage. If you’re developing your own theme, make use of sprites for those image assets. This helps in reducing the number of HTTP requests for each page load, which is critical to site performance.
Then further reduce the file size of your static files. Use appropriate filetype for images, like you know, don’t ever use bitmap (.bmp) images if you’re gonna put it on the web. JPEGs are great for photos, 8-bit PNGs for arts. If you must use 24-bit PNG for alpha transparency, run it through image optimiser (TinyPNG is especially great for this). In fact, run all the images through the appropriate image optimisers for their file type.
Some people minify their JS, CSS, and even HTML files. While that can shave off a few kilobytes, I find it time and again to be very counterproductive in terms of code development and maintenance. You can achieve practically the same thing later on through a different method, so I don’t usually minify the theme’s files.
Beyond that, there’s not much else you can do to improve performance at this stage. Some people really do try very hard to keep the number of database queries down, but unless you’re doing something very funny or really complex, this is often negligible.
If you’re not developing your own theme, try to choose a theme that fits the guideline above, like oh I don’t know, the Graphene theme maybe?
2. Optimise your site’s images
The amount of images in a theme is typically minuscule compared to the amount of images you insert into your posts and pages. It is therefore important to optimise them too.
Don’t upload images that are bigger than about 1000px x 1000px in dimension. Most people won’t ever view images at sizes bigger than that. If you’re building a site for client and they don’t know how to resize the images first before uploading, install the Resize images before upload plugin. And again, don’t ever use bitmap images.
When you insert images into your posts and pages, make sure that their physical dimension is exactly or as close as possible to the dimension they are displayed in. HTML scaling not only makes images look sub-optimal, it’s also bad for performance.
Finally, install some kind of server-side image optimisation plugin to further shave off a few percentage of the size of the images. If you’re on a Linux-based shared server, EWWW Image Optimizer is for you. CW Image Optimizer is an alternative for those on a VPS or dedicated server.
3. Use only what you need
Plugins are awesome, but features require resources, and you only have a finite and limited amount of resources. Keep only plugins that you really need and actually improve your site’s value, and remove everything else. Don’t be tempted to add fancy features just because you like it. Contrary to popular belief, your site is not for you, it’s for your visitors.
That being said, learn to identify which plugins are resource-heavy and which aren’t. Just because you have 20 plugins doesn’t necessarily mean that it’s using more resources than using only 5 plugins.
Learn to also pick plugins that add the least amount of scripts to your site, though this typically requires some detective work. For example, it’s very typical for a site to use the lightbox effect (or any derivative of it) for images. But many lightbox scripts use the Scriptaculous and Prototype libraries. There are also lightbox scripts that use the jQuery library instead, like WP jQuery Lightbox. Because it’s far more likely that jQuery is already being loaded for your site compared to Scriptaculous and Prototype, it is much better for performance to use the jQuery-based lightbox plugin than the alternative.
4. Combine and minify scripts
Most WordPress sites have anywhere from 5 to 50 separate CSS and JS files. The more plugins you use, the greater this number is. Each of those separate scripts requires a single HTTP request to the server to be downloaded, so performance suffers a lot because of the latency associated with HTTP requests.
The solution is to combine all these separate scripts into as few scripts as possible. My favourite tool for this is the WP Minify plugin, which automatically combines the scripts and then minify them. Some people prefer the minify feature already included in caching plugin like W3 Total Cache, but I find this plugin to give the best set of features, including much easier debugging.
Which is important because chances are the first time you do this on a new site, things will break. JS scripts are sensitive to the order in which they are loaded, and not all scripts are amenable to being minified. Because the scripts are combined, it takes just a single misbehaving script to cause all the other scripts to stop functioning. Figuring out which script is giving the grief can be a huge pain without a debugging feature.
UPDATE 26/8/2013: As of version 0.9.2.6 of W3 Total Cache, the built-in minify feature has been improved enough that it’ll probably be better to use it instead of using WP Minify. We can now specify files to be excluded from the minification, as well as specify the minified JS file to be loaded asynchronously. On top of that, the fact that all the caches (page, database, minify) are managed by a single plugin effectively eliminates the risk of one of the caches being out-of-sync with the other caches.
5. Use a caching plugin
This step has one of the biggest potential of speeding up your site, but it is also usually one of the more difficult to set up. Because each site is unique, there’s really no plug-n-play solution if you want to squeeze every little bit of performance juice out of your site.
W3 Total Cache (W3TC) is my choice of plugin for this purpose. It’s more powerful than the other alternatives like WP Super Cache, but it is also more difficult to configure. Configuring it wrongly can actually cause your site’s performance to decrease, so make sure you do thorough testing before being satisfied.
This is a typical setting that I employ for this plugin:
- Page caching to Disk: Enhanced
- Disable minify feature (since I’m using WP Minify)
- Database cache to Opcode: APC
- Disable object cache (didn’t find any noticeable performance improvement, but slows down the admin interface a lot)
- Enable browser cache
If you’ve configured this plugin properly, you should be able to easily get a time-to-first-byte (TTFB) of less than 1 second.
6. Server-side optimisation
Much of what has been discussed up to this point is performed on WordPress itself, and most of the time from within the WordPress admin interface. There’s also the performance improvements that can be realised on the server-side by configuring your server or installing performance optimisation tools.
This section is applicable to those using a Virtual Private Server (VPS) or a dedicated server. Those on shared hosting, I’m afraid you don’t have much luck here.
First mandatory item is to enable GZip compression. I prefer to do this server-side instead of via W3TC because there’s simply no reason for any site to not employ GZip compression. Instead of enabling HTTP compression individually on each site hosted on the server, I globally enable it on the server itself.
A PHP opcode caching is a must too. Take your pick from APC, eAccelerator, Memcache, etc.
Then I install mod_pagespeed from Google to implement optimisations that cannot be more easily realised by other methods, like turning small icons into inline base64-encoded image, and auto-spriting of those images not under my control (e.g. added by a plugin).
One of the features provided by mod_pagespeed that I especially like is domain sharding â€“ breaking up your main domain into multiple subdomains for parallel downloading of static files. I find this to be extremely useful because there’s no need to physically transfer your static files to different servers or different folders, or even rewrite your codes. Couple domain sharding with a CDN and boom, you have a winning formula.
7. Use a Content Delivery Network (CDN)
I typically leave this part last because it’s easiest to setup after everything else is completed. Cloudflare is a terrific free CDN, and it improves your site’s resilience and protection against spambots and other malicious bots too, but it does sometimes fail, and fail hard. But if you require SSL support, I’m afraid you’ll have no choice but to fork out some cash for any reputable CDN.
Don’t do things twice
There’s one last word of advice with regards to performance optimisation: don’t do things twice.
A lot of the tools that I mentioned in this article can actually do some of the things that the other tools can do. Cloudflare, W3TC, and mod_pagespeed can all combine and minify scripts on your site, but I’ve chosen WP Minify to do that job simply because I think it’s the best tool for that job. I then make sure that none of the other tools are doing the combining and minifying operations on the scripts.
This is important because there’s absolutely no use in optimising resources that have already been optimised. Instead, you will only use more resources for zero gain, which will actually decrease the performance of your site. Your performance optimisation tools should complement each other instead of trying to do everything just because they can.
The heart of the machine
There is also one other component that I haven’t mentioned yet that affects performance by a fair bit: your server. You can only do so much to optimise your site and its content, but if your server is crappy, your site’s performance is gonna be crappy. Many servers are just fine for most purposes and performance requirements, but if you find your server to be overall dodgy and lacking in support, don’t be afraid to pack up and leave. A reputable hosting provider will do your site wonders in the long run, even if it means you’ll have to fork out a little bit of extra cash for it. Lurk around in WebHostingTalk to get an idea of which host is worth your money.
Keep also in mind that as your site grows, the time will come when shared hosting no longer suffices. VPS and dedicated servers typically provide more resources and processing power for your sites, so they’ll help improve your site’s performance. If your income depends on your site(s), it’s worth it to consider upgrading from a shared hosting and do your cost and benefits analysis.
That about sums up the performance optimisation workflow for WordPress sites. It should give you a fair overview of what’s involved, and starts you on your own journey to experiment with it yourself. The details can be rather technical, and things won’t always go as you expect. But if you persevere and see it through, there’s a lot that you stand to gain from optimising your site.