Warning: getimagesize(http://philbrownphotos.com/dc/wp-includes/js/tinymce/plugins/wordpress/img/trans.gif): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/infobarrel.com/m/includes/article.class.php on line 1778
Reducing the bandwidth of a WordPress installation - InfoBarrel

Forgot your password?

Reducing the bandwidth of a WordPress installation

By Edited Jan 9, 2014 0 0

A few months ago I noticed my monthly bandwidth for two WordPress installations I was running was starting to run over 6GB. This was a bit strange because hardly anyone visited these sites. It was a bit alarming because my monthly allowance was 5GB. These were photo sites, but I was hosting the photos at Photobucket so that shouldn't have been the problem. In the end, after much research, and the following battery of changes, I reduced the bandwidth down from 6GB+ one month to a more reasonable 82MB the next. There didn't seem to be too much information about reducing bandwidth, so I cobbled together the following for various sources.


There are numerous plugins available that cache pages of your site so that anyone who looks at the same unchanged page twice gets to see a static, cached, html version of it, rather than a spontaneously generated full CSS, PHP and database-queried output. Up until I switched to WordPress 3.0 Multisite I had been using a combination of DB Cache Reloaded and WP Super Cache. Despite what it says in the details section of DB Cache Reloaded, using both is the best option, because they do different things. DB caches database queries and WP Super Cache does likewise for the actual pages, as well as offering an option to compress the html with GZIP. The problem I've had since switching to Multisites is with WP Super Cache not refreshing pages when they're changed. I think it's something to do with domain mapping and permalinks, but whatever settings I try it will not refresh updated pages even for logged-in users which is driving me crazy when I'm trying to see new posts. It also seems to be incessantly complaining about .htaccess file differences, yet when I copy in the exact code it asks for I can't access the site at all. It also says I have some Apache module missing. So, all-in-all, my installation is not doing well with WP Super Cache. I also tried Hyper Cache which doesn't seem to have the capacity to make you aware of some many problems, and appears to work, but gives me the same problem with not updating pages with new content, no matter what settings I change. That said I recommend trying either, because I'm pretty sure it's a problem with my installation rather than the plugins, which up until now have worked fine. DB Cache Reloaded seems to be as stable and non-intrusive as ever. I did try installing W3 Total Cache as well, but that threw up so many problems I couldn't even get it to activate.


So, given that I've had to get rid of WP Super Cache and anything like it, but still wanting GZIP compression, I've now installed GZIP Enable, which works perfectly with no errors at all. A quick check on whatsmyip.org/http_compression/ showed the following results:

Original Size: 24.93 KB
Gzipped Size: 5.53 KB
Data Savings: 77.82%

So that's a 78% bandwidth saving right there. Apparently GZIP compression used to be built into WordPress, and then they removed it.


Image sizes can be a bandwidth killer and some compromise needs to be made between size and quality. I'm generally favouring 700 pixels on the long edge at JPG quality 6, which gives a file size generally of less than 100kB. PNG's are also a good option because they are not lossy like JPG's. Either way I also highly recommend ImageOptim (Mac only) a simple and free application that runs numerous compression routines on whatever image files you drag into it, picks the best one depending on the settings, compresses it and shows you how much space you saved. Doing that prior to uploading can cut file sizes around 25% on average.

If you're posting lots of pictures then a host like ImageShack or Photobucket means you use their bandwidth instead of your own. The downside is that if they go out of business you'll have a site full of broken links.

RSS feeds

This is more important than I previously assumed. First ensure that under Settings > Reading, the option 'Syndication feeds show the most recent' is set to something low, like the default 10. I had one site where I'd set it to 999 (because I wanted new subscribers to get everything) which I think contributed hugely to my inflated bandwidth problems. The problem is not, as far as I understand, so much actual people subscribing to your feeds, but badly coded robots and other data collecting devices which may download your feed numerous times. For that reason set it to 10 and, as with the pictures, outsource the whole syndication, this time to FeedBurner, which routes your feed via its own servers, thus using its own bandwidth to syndicate it. In combination with the FeedBurner Feedsmith plugin, which gathers any feed from your site and redirects it to your FeedBurner feed, you end up with only one feed leaving your site, no matter how many subscribers you have.


Depending on your host you should be able to see after a day or two how much bandwidth you're saving. Another tool to check general health of the whole site, as well as GZIP compression status, is ismyblogworking.com.



Add a new comment - No HTML
You must be logged in and verified to post a comment. Please log in or sign up to comment.


Explore InfoBarrel

Auto Business & Money Entertainment Environment Health History Home & Garden InfoBarrel University Lifestyle Sports Technology Travel & Places
© Copyright 2008 - 2016 by Hinzie Media Inc. Terms of Service Privacy Policy XML Sitemap

Follow IB Technology