Optimizing WordPress For Shared Hosting
On 05.25.2010 by Paul Robinson |
There are lots of websites hosted on shared hosting in this age, and the majority are probably running WordPress. While it’s a great application once set up with plugins it isn’t the lightest one on the block. Here we are going to look at making WordPress as shared server friendly as possible.
WordPress is actually fairly lightweight on a default install, but there are quite a few plugins essential for a good SEO friendly WordPress install. With those installed you can easily end up with a footprint of between 20-30MB per request. On a shared server, with say a memory limit of 90MB, you are pretty much up the creek without a paddle it 3/4 people enter your website. Here I am going to share my top tips for making WordPress work it’s best in a limited resource environment.
Minified Scripts
The first tip is a small one. Whenever possible use the minified versions of scripts such as jQuery. This doesn’t really help much with memory, but does give a little bit of a speed increase. Feel free to skip this one, but if you are all about squeezing out those few extra milliseconds then give it a go.
WP Super Cache
My all time favorite caching system for WordPress has to be WP Super Cache. It has always worked wonderfully on my shared hosting environment. It can be a little tricky to set up, but there are great instructions provided and it’s worth it. I, personally, find having ‘Cache Rebuild’ and ‘Coarse File Locking’ switched on helps too. I also have compression switched on, although that tends to only help with bandwidth usage.
Reduce Amount Of Plugins
This may seem obvious, but the less plugins you have the less memory you are likely to use. You might also want to look out for plugins that load scripts/options all the time, even when they are not needed. This can add extra weight to WordPress by loading information even when the plugin is not required to do anything.
Timthumb!
Otherwise known as a dynamic thumbnail generation script, Timthumb uses PHP & GD to create alternate sized thumbnails. It is quite often in themes, especially magazine style themes to create thumbnail sizes WordPress doesn’t normally create. While Timthumb does actually have a cache to store the images it creates it isn’t as efficient as a WP Super Cache style cache.
More often than not you do not want to spawn a PHP process when it isn’t needed, especially on shared hosting. Why? Well because loading a WordPress page takes, as I said before, about 20-30MB of memory. If you can load a page without PHP spawning you won’t use large amounts of your available memory & you could probably survive a front page feature on Digg. That is what WP Super Cache does, it saves the result of PHP processing your request for a page to a flat HTML file & redirects you to that flat file using Mod Rewrite (Apache Module) the next time you want to view it.
What’s That Got To Do With Timthumb?
Well Timthumb caches images after they are created, which is great. The problem is that to find if an image is cached it needs to use PHP, but you don’t want to run PHP as a normal PHP process still uses between 8-13MB of memory. That’s memory you can’t afford if WP Super Cache is re-caching your page (20-30MB + 8-13MB = 28-43MB). Therefore the best option is to modify Timthumb to work exactly as Super Cache does, using Mod Rewrite to direct you to the cached file. This will probably make this post huge, but here’s how I got mine working. A big thanks to 2 examples (linked to below) of Timthumb being used with Mod Rewrite I found on the web, although the exact same code didn’t work for me, the code here is only very slightly modified.
First you need to find this section of code in Timthumb:
function get_cache_file() {
global $lastModified;
static $cache_file;
if(!$cache_file) {
$cachename = $_SERVER['QUERY_STRING'] . VERSION . $lastModified;
$cache_file = md5($cachename) . '.png';
}
return $cache_file;
}
Now comment out the two highlighted lines, and/or replace them with these lines:
$filename = cleanSource(get_request( 'src', 'timthumb' ));
$filename = pathinfo($filename);
$cachename = $filename['filename'] . '-' .
get_request( 'w', 100 ) . '-' .
get_request( 'h', 100 ) . '-' .
get_request( 'zc', 1 ) . '-' .
get_request( 'q', 80 );
$cache_file = $cachename . '.png';
Thanks to speedingupwebsite.com for some of this code. We basically change Timthumb so it doesn’t md5 the filename, as we need a nice sensible filename for us to rewrite to.
Next we can go onto the Mod Rewrite. I can’t deny that Mod Rewrite is powerful, but I hate the stuff so please forgive any mistakes I make here.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{SCRIPT_FILENAME} timthumb\.php
RewriteCond %{QUERY_STRING} src=http:\/\/.*\/(.*)\.(png|jpe?g)&w=([0-9]+)&h=([0-9]+)&zc=([0-9]+)
RewriteCond %{DOCUMENT_ROOT}/wp-content/themes/returntrue/thumbs/cache/%1-%3-%4-%5-80.png -f
RewriteRule ^.* /wp-content/themes/returntrue/thumbs/cache/%1-%3-%4-%5-80.png [L]
</IfModule>
Again thanks to speedingupwebsite.com & also thanks to hungryhacker for the code here. I’ve modified it (very slightly) as while it was very helpful it just refused to work for some reason.
Let’s explain what’s going on here. First we check if the script we are asking for is timthumb.php. If you called the script something else change that part. The next part checks the query string. We want to match the images filename, the width, the height & if zoom crop is turned on. The sections in parenthesis can then be used in the next part to fill in the new filename we gave thumbnails saved by timthumb. We use %{DOCUMENT_ROOT} to get the path to the root of our site & then we fill in the path to the cache folder created by timthumb. The -f tells Mod Rewrite to only return true if the file actually exists. If those three conditions are all true we try to redirect the request for timthumb to the actual saved image file. If those rules are not true it will hand the query to timthumb as normal.
This has worked wonders keeping the strain on the server down for my website. Just remember that you will need to change both the paths to where your timthumb cache is. It works in exactly the same way as Super Cache, redirecting requests to Timthumb to the actual image file should it exist.
There we have it. My list of ways to help optimize WordPress for running on shared servers. I just want to make it clear that the Timthumb Mod Rewrite cache was not my idea, the code is a slightly modified version made with help from the two sites I linked to above. All credit goes to them for the idea & the code.
I hope this post was useful & it has helped you optimize your WordPress install. I currently have all of the tips here implemented here on Return True & I’ve noticed a dramatic increase in performance. As always if you have any questions about anything in this post, please post them in the comments.
Discussion: 10 Comments
Hi there,
I think the reason my mod_rewrite rules “don’t work” is because mine involve modifying the WordPress theme so it never actually looks for timthumb if the cache file exists.
The other site you linked to takes the different approach of poaching the query string from the URL to timthumb, and using that to look for the cache file. That has the advantage of working with most any theme that uses timthumb, without having to modify the theme.
I wish I’d googled before I went through all that effort, because the other site you linked to already had all the information right there – I really thought I was onto something.
Actually your rules helped a lot. I’m still learning to use mod rewrite so they helped me understand it a bit more. I did try your method of changing the file paths, but when I found the other version I decided to go for that due to the fact I needed to implement it over 3 or 4 sites all with different themes.
I went looking too as I needed to stop PHP running at all to help with server stress. I wasn’t going to post it as it’s technically just repeating what’s already out there, but I though maybe some people may not be able to fix the problem I had with the mod rewrite rules. I’m not sure why they didn’t work for me, but it was only a slight modification to the filename matching in the rule. It matched the entire file path except for
http://and I only wanted the filename.Your post still helped a lot so thanks for writing it.
Also I hope you don’t mind that I wrote this out. I just wanted to share how I got it working just in case it helps anyone.
“I’m still learning to use mod rewrite so they helped me understand it a bit more.”
Good luck with that – mod_rewrite is voodoo[1]! That’s basically why I edited timthumb the way I did, it’d involve minimal understanding of mod_rewrite. The speedupwebsite method seems a lot cooler, I just can’t be bothered messing with it.
Anyway, just thought I’d stop by and say thanks for the pingback.
1) http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
The thing I hate about Mod Rewrite is the fact that if you make a mistake (and you can’t enable logging) you’re basically left guessing what is wrong, if the problem isn’t obvious.
Yeah, I had no choice but to use the other method. While I could have changed the paths to Timthumb it was quicker & easier (for clients) to just upload the new files with modified paths.
No problem.
This is great. You should submit this to the TimThumb author to integrate.
Have you seen Smart Image Resizer? http://shiftingpixel.com/2008/03/03/smart-image-resizer/
I’m deciding between TimThumb and it right now. Supposedly it’s even better. It does cache too. And it even sharpens images. Love to know your thoughts on it vs TimThumb.
Great tips, I was referred by HostGator to this post, really appreciate this
Wow! Really?
Thanks, glad you found the post helpful.
I’m curious why you’re still concerned about timthumb, regarding the new built-in thumb method of WP.
As I totally appreciate the work that has been published here, I’m excited to get your statement considering the omnipresent timThumb vs wp thumb generator, and of course taking TAI into discussion as well!
I was searching a while, but a clear statement has never been posted anywhere… few just state timThumb is bugged, wp’s inner method is too shallow etc. -> However, I’m actually at the point to create a category-related post-thumb grid, which forces me to grapple with the whole thumb thing, hence it would be dumb to utilize timthumb if it’s out of date!
I found a subtle statement in your recent “Using The Attached Image With Custom Post Thumbnails In WordPress” tutorial…however, this leads me to add: ” What’s if there already exist around 100 pictures?” … isn’t it smarter to let the timthumb/tai combo produce thumbs via url instead of the wp method?
You may notice that this post was from a few month ago. At the time I hadn’t had the time and hadn’t need to delve into the usefulness of WP’s new post thumbnails feature.
However I have since then & the answer is, it’s entirely up to you. WordPress’ new post thumbnail system is great, it allows you to create custom thumbnail sizes without on-the-fly generation script like timthumb. You are right in that if you already have pictures it’s a pain, but that’s easily sorted with Viper007Bond’s regenerate thumbnails plugin.
The biggest problem comes in that you will still have to go through all your posts to set a featured image or WP will not show one. However if you check out my latest post you can see I’ve updated The Attached Image to help out with that.
Also sorry for the delay & the down time. Someone decided it would be funny to attack the site. Luckily Mod_Sec caught it, but it still took the site down for a little while.