As I’ve already mentioned before, we’re working on a Mac version of LandlordMax. The good news is that it’s almost ready. It’s also why I haven’t been posting much lately, I’ve just been way too consumed trying to complete and release the Mac version. It’s amazing how many little details there are when supporting another operating system. I plan on eventually posting about some of the issues we encountered between Mac and Windows.
To give you a quick update, the Mac version is looking really good. The only issue we’re aware of that’s left has to do with backing up and restoring database file between the Mac and Windows versions. This is an example of some of the weird operating system differences that we’ve had to resolve.
In any case, we’re extremely close to releasing it. I know I told some people I expected it to be available by now, but the LandlordMax Mac version will be released any day now.
It’s very exciting!
Thursday, August 27, 2009
3 Quick and Simple Tricks to Speed Up WordPress
There are many ways to improve the performance of your WordPress blog, and today we’ll be focusing on three simple and easy techniques. That is, instead of dealing with caching and other advanced topics, we’ll instead focus on how to improve the performance of your WordPress blog by just making some small and minor changes to your WordPress theme.
The performance of your blog basically comes down to 3 main issues in order of importance:
The number of calls to your database
The amount of code that needs to be executed.
The amount of data that needs to be downloaded (images, etc.)
Beyond this you’re getting into the more advanced topics such as caching, etc. And you shouldn’t really be looking at the advanced techniques until you resolve these basic issues first.
1. The number of calls to your database
Every single call to your database is very expensive (this is true for all web application, not just a WordPress blog). It’s not just marginally more expensive, it’s critically more expensive. The good news here is that there is a lot, and I do mean a lot, of room for improvement. Most themes out there completely ignore this issue and just call the database whenever they want any type of data (which is understandable for generic themes, but not for custom themes). In any case, this is very bad. And I do mean very bad. Well ok, maybe it’s not so bad if you have barely any traffic, but as soon as your blog starts to take off it will quickly hamper your performance.
For example, looking at the latest default WordPress theme for version 2.7 (the “classic” theme isn’t much better), in the “header.php” file, you can find:
; charset=” />
<?php wp_title(’«’, true, ‘right’); ?> <?php bloginfo(’name’); ?>
” type=”text/css” media=”screen” />
RSS Feed” href=”” />
Atom Feed” href=”” />
” />
There’s more, but this is enough for our example. If we look at the code above, the method bloginfo() calls the database for every new value. In our example I count 7 new and different values out of 9 bloginfo() calls, hence 7 database calls. WordPress is smart in that once a call for a specific value is made (say “name”) it will cache and re-use the value for that one web request. That’s good and it does help (kudos to the WordPress developers for this), and in our case it saves two database calls. But on the next page request, we still have another 7 database calls to make.
The good news is that we can drastically improve the performance of our blog theme above with some simple changes:
<?php wp_title(’«’, true, ‘right’); ?>My Blog’s Name
These simple changes has dropped the number of database calls from 7 to 1!!! That’s very significant, especially since these expensive. And that’s every time a user calls every page!
Sure there is a small penalty, but it’s extremely minor. For example if we change our blog’s name then we need to manually change the theme as well. But how often do you change your blogs name? I’ve never changed the name of this blog since I’ve started it and nor do I ever plan to. And why would I? I would lose all my marketing and branding efforts.
If you go through the rest of your theme, I’m sure you can extract a lot of database calls. Especially on the header, the footer. But if you look, I’m sure you can find similar code all over the place. Of course don’t go crazy, but do pay close attention to the database calls. Remember this is a simple theme. In a more complex theme you might easily be able to save yourself a good 10-20 database calls, if not more.
2. The Amount of Code to Execute
Very similar to the above tip, look around your theme for places where there are function calls that you don’t need. Trim down your blog’s theme.
A common place to find code that’s executed a lot that doesn’t necesarily need to be is plugins. Some plugins are great and really help improve your blog (such as Akismet for comment spam). But not every plugin is created equal. Some plugins are just badly written and really slow down the performance of your blog. Therefore look at all the plugins you have installed on your blog and limit yourself to only those that create real value. Ask yourself: s this plugin really worth it? And the more traffic you have, the more you need to ask yourself this.
Without getting too technical, since this is suppose to be quick and simple tricks, look for loops in the code of your blog’s theme (”for” and “while” loops). Examine the code that’s executed in these loops because it’s probably executed many times (which is why it’s in the loop in the first place). Is it necessary? Does it really provide something of value?
3. The amount of data that needs to be downloaded
The next most important you should be doing is looking at the main images on your blog. Is your logo’s filesize as small as it can be (while still looking good)? Can you shrink it? Then look at all the images that appear on virtually every page (the RSS subscription icon, the email icon, etc.). Can they be shrunk as well? And don’t just think about shrinking them, ask yourself if you need them in the first place? Do all the images serve a real purpose? Sure that bright yellow flashing gif animation of a flying toaster on the footer is kinda cool retro 1995 style, but is it really needed? That’s one less image you have to download and process.
Another easy place to reduce image size is on the images within your individual blog posts. Are they as small as they can be? Are you using 100kb image files or are you shrinking them down to 10-40kb? Sometimes a little loss of quality can more than halve your image file size, without a noticeable difference in quality to the un-attuned eye.
You can also look at shrinking the size of your css (Cascading Style Shee) file. Are all the styles need and used? If you’re a web geek, you can even consider removing all the whitespace to shrink the filesize. Just don’t do it manually, use a tool to help you out. The same goes for your Javascript files.
The performance of your blog basically comes down to 3 main issues in order of importance:
The number of calls to your database
The amount of code that needs to be executed.
The amount of data that needs to be downloaded (images, etc.)
Beyond this you’re getting into the more advanced topics such as caching, etc. And you shouldn’t really be looking at the advanced techniques until you resolve these basic issues first.
1. The number of calls to your database
Every single call to your database is very expensive (this is true for all web application, not just a WordPress blog). It’s not just marginally more expensive, it’s critically more expensive. The good news here is that there is a lot, and I do mean a lot, of room for improvement. Most themes out there completely ignore this issue and just call the database whenever they want any type of data (which is understandable for generic themes, but not for custom themes). In any case, this is very bad. And I do mean very bad. Well ok, maybe it’s not so bad if you have barely any traffic, but as soon as your blog starts to take off it will quickly hamper your performance.
For example, looking at the latest default WordPress theme for version 2.7 (the “classic” theme isn’t much better), in the “header.php” file, you can find:
; charset=” />
” type=”text/css” media=”screen” />
RSS Feed” href=”” />
Atom Feed” href=”” />
” />
There’s more, but this is enough for our example. If we look at the code above, the method bloginfo() calls the database for every new value. In our example I count 7 new and different values out of 9 bloginfo() calls, hence 7 database calls. WordPress is smart in that once a call for a specific value is made (say “name”) it will cache and re-use the value for that one web request. That’s good and it does help (kudos to the WordPress developers for this), and in our case it saves two database calls. But on the next page request, we still have another 7 database calls to make.
The good news is that we can drastically improve the performance of our blog theme above with some simple changes:
These simple changes has dropped the number of database calls from 7 to 1!!! That’s very significant, especially since these expensive. And that’s every time a user calls every page!
Sure there is a small penalty, but it’s extremely minor. For example if we change our blog’s name then we need to manually change the theme as well. But how often do you change your blogs name? I’ve never changed the name of this blog since I’ve started it and nor do I ever plan to. And why would I? I would lose all my marketing and branding efforts.
If you go through the rest of your theme, I’m sure you can extract a lot of database calls. Especially on the header, the footer. But if you look, I’m sure you can find similar code all over the place. Of course don’t go crazy, but do pay close attention to the database calls. Remember this is a simple theme. In a more complex theme you might easily be able to save yourself a good 10-20 database calls, if not more.
2. The Amount of Code to Execute
Very similar to the above tip, look around your theme for places where there are function calls that you don’t need. Trim down your blog’s theme.
A common place to find code that’s executed a lot that doesn’t necesarily need to be is plugins. Some plugins are great and really help improve your blog (such as Akismet for comment spam). But not every plugin is created equal. Some plugins are just badly written and really slow down the performance of your blog. Therefore look at all the plugins you have installed on your blog and limit yourself to only those that create real value. Ask yourself: s this plugin really worth it? And the more traffic you have, the more you need to ask yourself this.
Without getting too technical, since this is suppose to be quick and simple tricks, look for loops in the code of your blog’s theme (”for” and “while” loops). Examine the code that’s executed in these loops because it’s probably executed many times (which is why it’s in the loop in the first place). Is it necessary? Does it really provide something of value?
3. The amount of data that needs to be downloaded
The next most important you should be doing is looking at the main images on your blog. Is your logo’s filesize as small as it can be (while still looking good)? Can you shrink it? Then look at all the images that appear on virtually every page (the RSS subscription icon, the email icon, etc.). Can they be shrunk as well? And don’t just think about shrinking them, ask yourself if you need them in the first place? Do all the images serve a real purpose? Sure that bright yellow flashing gif animation of a flying toaster on the footer is kinda cool retro 1995 style, but is it really needed? That’s one less image you have to download and process.
Another easy place to reduce image size is on the images within your individual blog posts. Are they as small as they can be? Are you using 100kb image files or are you shrinking them down to 10-40kb? Sometimes a little loss of quality can more than halve your image file size, without a noticeable difference in quality to the un-attuned eye.
You can also look at shrinking the size of your css (Cascading Style Shee) file. Are all the styles need and used? If you’re a web geek, you can even consider removing all the whitespace to shrink the filesize. Just don’t do it manually, use a tool to help you out. The same goes for your Javascript files.
Subscribe to:
Comments (Atom)