How I sped up my WordPress blog

I thought I’d share some tips on how I cut down the loading time for my blog. These tips might help someone out there make their WordPress blog (or any website) run faster. So far, using these techniques, I’ve shaved about 2 seconds off the loading time (when cache is empty) and for repeat visitors, the load time is under 7 seconds. Testing performed using OctaGate SiteTimer. As usual, FireFox and Safari browsers were much faster than Internet Explorer.

Compact (“minify”) your CSS, PHP, JavaScript (JS) and HTML Files

Removing whitespace, unnecessary lines, and useless code from these files will shrink file size, improving download time of these files, at the expense of (possibly) making the files slightly less readable. This is the easiest thing you can do with these files. There are even online “compressors” where you can upload or cut and paste your code, and it will spit out the compressed version, but I wouldn’t use that unless you understand the output. Obviously, it helps greatly if you understand CSS, PHP and so on, so you can edit and compact the code yourself.

Remove comments and commented code from your active files and paste them into local backup files. I keep them on my hard drive, where I can make notes on what they’re for, in case I do eventually need them. Some CSS files even have whitespace (empty spaces) at the end of the line. If you press the “End” key, you can see where the true end-of-line is, and backspace over it to remove the wasted space.

And as I’ve found the hard way, WordPress will still process code inside comments, while leaving it commented out. So commented code (especially with PHP or database calls) will needlessly waste processor time which could be used to display your webpage. Weigh the benefits of keeping commented code in your blog’s PHP files versus removing it to decrease file size and save processor cycles. Again, I remove unused code, comment it, and save it on my hard drive if needed later.

Google has an excellent Firefox addon called PageSpeed which can show you where your CSS is inefficient or unused.

See 10 Tips For A Smaller CSS File for specific examples of how you can shrink your CSS file.

Many PHP-based themes for WordPress also use comments and whitespace in excess. Removing the whitespace and concatenating lines where possible will result in smaller file sizes.

Your blog may also benefit from conditional includes, which will have the double benefit of shrinking your file size and providing dynamic content. The process is identical to the process for creating external JS files: include a link to the PHP file, and in that PHP file, remove the opening and closing PHP tags. Make it conditional by using if statements.

Move CSS to the top, and JS to the bottom

Page load time will also benefit if you move CSS links to the top of the page, and JS links to the bottom. Anyway, this is what Yahoo recommends in their webpage optimization guidelines. JavaScript that isn’t essential for the operation of the page (ex: visitor tracking code) should be placed in the footer or at the bottom of the page, so the main content can load first. If you run WordPress, this is easy; there are a few “move Javascript to footer” plugins. I use JavaScript to Footer.

JavaScript should also be externalized, to shrink overall HTML file size. See Reduce The Size Of Your HEAD and scroll halfway down for instructions on how to create external JS files.

Remove unnecessary Plugins, and make the remaining ones conditional

Are you using 10, 20, 30+ plugins? Some plugins are processed every time a page is loaded, even if they don’t actually do anything on that page. For example, some plugins hook into the wp_head function to place CSS or JS links in your header, which will be loaded on every page even if the plugin isn’t being used on that page.

Can you remove them, or find a “rollup” plugin that can do the work of two or three of your existing plugins?

A popular class of plugins for WordPress are the ones that interact with Google Analytics. The one used on my blog is Google Analytics for WordPress. This plugin automatically inserts your Google tracking code into your posts and pages. But I can duplicate the effort by simply pasting in Google’s tracking code directly into footer.php of my theme, thereby saving time having the plugin do it. Just go to your Google Analytics account and get the tracking code, and paste it into the PHP file. Sure, I might have lost some of the functionality of the plugin, but all I really need is the basic reporting function of my Analytics account.

Another popular plugin is Feedburner FeedSmith. This plugin detects all of the ways your feeds can be accessed, and redirects them to your Feedburner feeds. That way, you can aggregate all your subscribers under the FB feed, making your subscriber count more accurate, and making sure all your subscribers are seeing the same content.

But all I had to do to get rid of this plugin is visit What is My WordPress Feed URL? and then edit my .htaccess file to redirect the built-in WP feeds to my FeedBurner feed.

Redirect 301 /blog/feed/ http://feeds.feedburner.com/MyFeedName
Redirect 301 /blog/feed/rss2/ http://feeds.feedburner.com/MyFeedName
Redirect 301 /blog/feed/rss/ http://feeds.feedburner.com/MyFeedName

and so on.

I got rid of the Random Posts plugin by using code I found on the ‘net that returns random posts using a WordPress function.

I am also using the Similar Posts plugin (from the same author) in my post footer, and if I didn’t mind changing it to random posts instead, I could use the above code as well, and remove two plugins.

Check your plugins and see if any of them don’t need to run all the time. For example, if you run a plugin that allows visitors to email or print a copy of a post (ex: WP-EMail, WP-Print), you probably don’t need them to run if the visitor isn’t on a post page. Make them conditional instead. This sometimes requires direct editing of the plugin code itself.

1. Deactivate the plugin
2. Click the “Edit” link to edit the plugin file itself
3. Wrap the entire plugin in an if statement that checks the current page. Don’t forget the opening and closing braces “{ }”
4. Save the file and reactivate the plugin.

This will be most successful with plugins that write CSS or JS links inside your head tag, because this hack will stop them from doing so, thereby decreasing load time for pages where the plugin isn’t necessary. If you got a fatal error when editing/reactivating, or your blog breaks, or the fix simply doesn’t work, you might need to search the plugin file (deactivate it again first) and look for the section where the CSS or JS file is written, and add the above code there instead.

Once editing is finished, the plugin will only run where we want it. See WordPress Conditional Tags for a complete listing of conditional tags. Remember, you’ll need to repeat these steps every time a plugin is updated, because the hack will be wiped out by the update. It will be easiest if you deactivate the plugin, update it, then hack it, before reactivating it. Also, for those plugins you need to call manually in your template, you’ll want to go through your template files and wrap the function calls in an ‘if (function_exists(plugin_name))’ statement, because you’ll be deactivating it a lot and you don’t want your blog to break every time you need to update a plugin. In fact, I recommend you do this for all plugin function calls, even the ones you won’t be editing, because someday you might need to deactivate one.

Certain plugins don’t need to be running around the clock, and can be safely deactivated and reactivated when needed. For example, I keep the following plugins deactivated until I need them:

• WordPress Database Backup
• WordPress Automatic Upgrade
• Optimize DB
• Maintenance Mode

Although it might actually be better to remove them completely and reinstall them when needed, since all plugins (even deactivated ones) are checked to see if they apply to a current page. Very inefficient on the part of WordPress, but that’s the way it is, and this is an article about speed and optimization after all.

Use compression

If using WordPress on a Unix-based host, try and use mod_deflate or mod_gzip. Some cheap webhosts won’t allow you to use it, however, because they are resource hogs. As an alternative, you might be able to use PHP-based compression (zlib). It depends on your webhost. See Compress your WordPress website for more.

Got additional suggestions? Post a comment with your thoughts.