WordPress performance tweaking – (1) Browser Caching

I thought it was probably worth a few posts on how I’ve “tweaked” my WordPress blogs to load a bit quicker in your browser window.
Like many self-hosting bloggers I use an inexpensive hosting provider – which means that there are compromises in terms of performance. So I need to make the most efficient use of the resources available.
If you use a hosting platform such as WordPress.com – rather than running your own site – then these options may not be open to you; you’ll have to take whichever settings they make available to you. This isn’t a necessarily a bad thing, but the site may be optimised for robustness and reliability rather than performance.

Most of these techniques aren’t specific to WordPress (the software – as opposed to the hosting site) – they apply to other web pages.
One of the advantages of the WordPress approach, though, is they can be wrapped up by plugin developers – which means all of the hard work’s been done for you.

And most of my leg-work has been done by other bloggers. I’ll try and credit them as I go through.
One big help has been TentBlogger’s site – a valuable source of information on SEO in particular.

Browser cache

Probably the oldest technique – this isn’t WordPress specific – is to use your reader’s browser cache. This is the history of the pages that they’ve opened recently – so if they return to a page, there’s already a copy sitting on their hard disk.

The downside is that nowadays, many browsers are set to clear at the end of the session – to ensure privacy.
But implementing this can still mean that your banners and stylesheets don’t reload every time your readers navigate.

This technique works with the Apache webserver, which is the most commonly implemented solution – certainly on Linux platforms.

So how does this work ? Well, you can set up your web pages with “expiry dates”. You can set these in your Apache configuration file, but you’re probably better off working with a file called .htaccess that’s almost certainly sitting in your blog’s home directory. You can only change this through ftp or your file management tool (normally CPanel or Plesk).
You can put this code right at the top – outside any sections such as “# BEGIN WordPress”.

You can change the expiry on the different files to suit your activity level.
Remember, though, that you may not want to cache your CSS file if you’re in the process of changing it – you won’t be able to see the changes. You can always empty your browser’s cache, but you may just want to comment out the line (with a “#”) while you’re developing …

[code lang="apache"]
ExpiresActive On
ExpiresByType text/html "access plus 5 minutes"
ExpiresByType text/php "access plus 30 days"
ExpiresByType text/css "access plus 30 days"
ExpiresByType image/jpeg "access plus 30 days"
ExpiresByType image/jpg "access plus 30 days"
ExpiresByType image/gif "access plus 30 days"
ExpiresByType image/png "access plus 30 days"
ExpiresByType text/javascript "access plus 30 days"
ExpiresByType application/javascript "access plus 30 days"
[/code]

If you want to find more detail, have a look at the Apache mod_expires documentation.

(Thanks to Justin Britten’s “Expires Header” article for pointing me in the right direction.)

Leave a Reply