One of the top considerations of any web site owner should be speed.

In these days of broadband connections, people are used to near instantaneous results, and a slow loading front page is guaranteed to lose visitors.

There are several factors which control loading time.

One is of course server response times.  There is little that can be done about that!

Then there is the core code of the site.  WordPress is WordPress and there is little or nothing you can do to change it.

There are areas though that are well within the site owner’s control.

The Theme.

The one thing I would say about themes, from the speed perspective is that the more graphic the site, the slower it tends to be.  A graphic rich theme is going to be slow, and it is worthwhile bearing this in mind when making a choice.

Plugins.

Plugins can be a site killer.  I use a plugin on my sites – Plugin Performance Profiler (P3) – which is a good indicator of which plugins are holding the site back.  Using that plugin I have managed to shave seconds off sites’ load times, by either indicating which plugins to remove or which to replace with a slicker version.  In quite a few cases I have managed to find replacement plugins that have exactly the same functionality but are faster to load.

External links.

External links within plugins or extra coding (such as advertising or analysis0 are frequently the cause of sluggish sites, as the server has to wait to connect to those sites before continuing to serve up the rest of the main site.  If your traffic analysis site is having an off day then your site will too.  

As an example, I had a plugin on this site which displayed my blogroll on the sidebar along with their latest posts and date of posting.  Before the page could load, the server had to contact each linked site in turn to retrieve information.  I ditched the plugin and reverted to standard links and shaved 32 requests and several seconds off the load time.

Images.

These are probably the biggest contributors to “gross tonnage” of any site.  Always reduce images in physical size and compression before uploading.  A photograph that is say 3,500 by 2,000 pixels may look stunning but it will weigh many megabytes.  Setting its display size may reduce the visible size but it will still weigh all those megabytes.  If you only want it to appear at say 600 x 400, then reduce it before uploading.  Also compress it as much as possible as many kilobytes can be shaved off an image that way.

Caching.

Caching can have an enormous impact on page load times.  It does so by generating static pages from the normal dynamic ones and therefore cuts way back on database requests, code requests and file loads.  There are several excellent caching plugins which can be found on the WordPress site.  While I haven’t tried all of them, the ones I have tried give facilities to allow code compression and browser caching which help greatly with load times.

A word of warning about caching plugins – I have noticed that Plugin Performance Profiler (see above) tends to give very poor responses for caching plugins.  On closer examination though, the poor response times are almost exclusively within the Admin pages of the site.  One would assume that not many outside visitors are going to reach in there?!

One of the more important jobs in running a WordPress site (or any site for that matter) is backing up.

There are two parts to this – the files and the database.

Not all files need to be backed up, as in the event of catastrophic failure, the core WordPress files can be restored using the standard installation.  However the contents of the wp-contents folder are critical, as this is where the images, plugins etc are kept.  Granted, plugins also can be restored using available files from the Web but restoring them from a backup can save a lot of time and effort.

I experimented with several plugins to do my backing up, but had to abandon all as they were unreliable, unworkable or very resource hungry.  I had to find an alternative method, as the idea of connecting to several sites, and doing an FTP download plus doing a PhpMySQLAdmin dump each and every day was a non-runner.

I decided that Cron was my solution.

I set up a couple of small files – one to compress the contents of wp-content and the other to do a mysqldump.

Files –

/bin/tar –czf /usr/local/hosts/webspace/httpdocs/backups/backup-‘date +%d.%m.%y’ .tar.gz /usr/local/hosts/webspace/httpdocs/www/wp-content

Database –

/usr/bin/mysqldump –host=dbserver –user=dbusername –password=dbpassword databasename –quick > /usr/local/hosts/webspace/httpdocs/backups/backupdb-‘date +%d.%m.%y’ .sql

(need I point out that the paths, names and passwords are not the actual ones used?!)

I saved both files on the server and then set up a Cron Tab to run each file.

This worked perfectly on two of the sites I was testing on, but the third refused to work properly.  The ‘mysqldump’ function threw up an empty file each time, despite the code being identical in structure across all three sites.

It took a while to find the problem, but I eventually solved it.  It didn’t accept the password for the database as the password started with an ampersand ‘&’.  I tried various methods, such as escaping the ampersand and inserting quotes around the password but each time it failed.  In the end, I took the simple route – I set up an additional user for the database and gave that user a slightly simpler password.  It worked!

I now have a series of sites set up and all are running smoothly.  Because of the flexibility of Cron I could set the backups to run anywhere from once a minute to once a year.  However I have chosen a more sensible option. The databases are backed up every night and the files are backed up every week. That should be sufficient?

My next job is to refine the Files backup to ignore all cached files, as they are very bulky and aren’t necessary for a restore anyway.

One of the big problems with customising themes is that the theme’s core files have to be modified.

So you spend a happy few hours modifying style.css and you get the site looking just as you wish.  Then along comes an update to the theme which nicely overwrites your customised style.css and you are back to where you started. 

Of course you should have a backup of your customised file, but suppose the update included the theme author’s updates to style.css? 

As I have already pointed out, Weaver has the facility to insert your own code (CSS or HTML) into the header or footer of the site without any file editing.

An example of this is in the layout of the nested comments on the theme.  I felt that the reply to a comment wasn’t indented enough, and could lead to some confusion, as it wasn’t immediately obvious whether a comment was a new comment in its own right, or a reply to a previous comment.

The obvious way was to modify the style.css file but I went the route of adding an insert of some CSS into the Header in the (Advanced) Admin area –

.commentlist li.comment, #respond  {
margin-left: 15px !important;
}

This had the desired effect.  The effect is small but significant enough to improve readability –

Since I made that modification, there has been an update to the Weaver theme.  I applied the update and all my modifications remained intact.

Another hugely significant feature is that in the event of catastrophic failure I only need three things –

1. A database dump (mailed to me daily via a plug in)
2. A copy of the images I have created
3. A tiny XML file which Weaver creates and which contains all the modifications I have applied to the theme, including code inserts.

Every other item I need can be downloaded from the Internet.

Not many themes can do that?!