The WordPress core is very flexible and has a massive collection of free and premium themes, widgets and plugins that allow it to be used in many different ways, but with this flexibility comes the problem that blogs implemented on WordPress tend not be as fast as other sites implemented on simpler or more focussed frameworks. Some of this is inevitable in its wide scope, but there are ways to improve the performance.

Why are pages slow to load?

The structure of a typical WordPress site, with a theme, possibly a child theme, half a dozen assorted plugins/widgets (or more)  leads to one substantial cause of slow load times … the sheer number of different files that are transferred across the internet to the browser. Most of these files are small, and much more time is spent in negotiating a connection for each file, and then requesting its download, than is actually spent in transferring the file contents. (The protocols on which the internet is built were not optimised for the purposes they are now used!) This time is a significant contributor to the time it takes to load a page.

At the time of writing a page on this site loads 15 javascript files and 3 CSS files. (I actually used this one on image metadata as a simple example with no images or complicated inserts). The site is using a development build of the K2 theme, no child theme (which would add at least a CSS file and possibly a javascript file), and a gallery plugin though that isn’t used on the page tested. The time taken to reload the page shortly after its first load is about 3.9 seconds (measured using http://www.webpagetest.org ) of which a little over half is taken up by requesting the javascript and css files (not downloading them, as all requests return a ‘not changed’ message). This is obviously detrimental to a visitor’s view of the site.

Why are there so many files? Because all the files needed by any widget or plugin are loaded for every page, regardless of whether they are needed.  When I get round to adding a contact page, that will add another javascript file and another CSS file to every page, and similarly if I decide to add a slideshow for the gallery, and for any other display widget that needs one or other (or both). All of this adds up to a slow and unresponsive site.

How can we improve performance

If half the time is spent just asking whether a file needs to be reloaded, then speeding up how a page is created by WordPress (using one of several caching plugins available) can only have a limited effect on the page load time. We need as well to reduce the number of files that have to be requested, and that means combining some of the files.
The version of the K2 them I’m using has an option to use combined versions of the Javascript files, rather than the individual files used during development and testing of the theme. This reduces the total number of javascript files from 13 to 5, and the page reload time from 3.9 seconds to 2.4 seconds – a significant improvement!
If some of the other files could also be combined further gains could be made, but these are held in various places, and will be updated at different times (some are from WordPress itself, others from widgets). Manually maintaining combined files (and changing the core WordPress and widget code to use combined files!) is impractical. Even manually adjusting the javascript files for a theme that doesn’t do this automatically for you would be tedious, so when evaluating themes you might want to consider the performance aspects of the theme as well as appearance!

Automated solutions

Inevitably there are people who have tried to provide partially automated solutions to this problem, one such being the W3 Total Cache plugin, which helps to address this and other performance issues. It is a more complex plugin than those that just attempt to cache the main page file, and is inevitably more difficult to configure and use. It’s not for the novice but does allow you to combine these script files into a smaller number of files and so has the potential to significantly improve page loading times … but if you do try it, take file and database backups of your site first and read the documentation and faq carefully. If misconfigured it could render your site inoperative, so be careful!