Forum Moderators: open
A lot of the bandwidth comes from a discussion forum. These pages aren't graphic - at most, they load a gif banner. They are, of course, text-heavy. So, I'm looking for ways to cut down on bandwidth usage unrelated to images.
One thing I'm going to do is some archiving to cut down on "big" pages, particularly those that get loaded frequently.
Any other suggestions for cutting bandwidth, particularly in a mostly text-based environment?
There used to be a few good examples of big sites with fat indents that must have cost a bit $ in bandwidth.
The home page of WW hardly has any line breaks or indents, but you still save almost 1%....i.e. 250Meg? :)
When I was playing around with spidering and indexing pages, a more "assorted" set of pages were getting cut down by about 10% by removing line breaks, double spaces etc.
Probably just a good a saving for most people as external calls to jscript/css, caching etc
As brotherhood_of_LAN said, this can cut down a surprising amount of your file size.
Jim
I have been adjusting my little rule of thumb when it is advisable to go external. I think it is a mix of 3 issues with fuzzy gray lines inbetween them.
1) Will going external reduce the html size by atleast 25%? If so, go external.
2) Will going external actually reduce the html-css-js total in size? If not, stay on page.
3) page views per visitor greater than 5? If so, go external.
4) More than 50% of your daily uniques from search engines? Keep the css/js on page.
5) How many pages does a user have to view to see a return on bandwidth savings by going external?
6) How many users will see a negative download impact by going external? If it's more than 10%, you may want to stay on-the-page.
7) How many visitors will you lose if you go off-the-page with CSS?
I think 5-6 are the important ones. You have to judge your cutoff point where the return bandwidth savings is worth it, or is going to hurt you.
Personally, if I were you:
- I'd look for a software compression (gmod-zip for Apache or XCompress for IIS). You can obtain a gain up to 80% (at least this is what I gained in my ASP pages using software compression, 60% if we considered also all non HTML/ASP files).
- I'd link externally all CSS and JS (IMPORTANT: and make them cacheable, because if not all users would download it several times among the same session)
- I would make images cacheable
- I'd try to make images smaller
- I'd delete all useless HTML code: <strong>; <em>; images ALT, width and height (where possible)
- I'd look the logs to see if there's any "bad boy" bot which is stealing bandwidth from you
Brett,
I get the other 6 points, but can you please expand a bit on this one?
Thanks,
Jim
- reduce number of displayed posts per page
The viewtopic-page is drawing by far the most traffic accross our boards, so even little reduction will save a lot over all.
- mod_gzip (on apache)
Ask your hoster for this. I talked with mine, and he happily installed it. Some will argue that it takes too much processing time, tell them to just try it for a day, the benefits usually outweigh the drawback by far. The CPU usage is not as heavy as some people think.
Otherwise gzip your pages in your scripts. This is not as efficient as mod_gzip, however you are not dependant on your hoster to install it. For PHP look here for example: [leknor.com...] (class.gzip_encode.php). Some BBs have implemented this sort of compression and have an option to turn it on/off in the configuration (www.phpBB.com for example)
Let this test: [leknor.com...] make a guess on how much you could save with gzip compression. It is highly effective on text (!)
You might also ask the dev/support team of the BB if there is sth. like that available. Maybe someone has done it already.
On on of the search engine services i run, i found this problem the hard way. Basically around the peak times of day, the load average on the machine would go from it's normal "1 or 2" to 100 or 200 (obvoiusly causing all sorts of problems). After some investigation, it became clear that mod_gzip wasn't fast enough to spew out the pages at the rate I needed them: this was a runaway cpu resource problem. Basically while it is workin on compressing some pages, it would get requests to compress more pages before it was finished with the first ones, resulting in the server to collapse. The temporary fix was to change the sizes of files which i allowed it to compress (such that it would effectively be comrpessing fewer files with a lower level of compression - i think it defaults to a level of 6).
This first reared it's head around 35 [compressed] php pages per second from a 1xP4-2.2Ghz machine. Again, the big issue there is the cliff effect: you can't really tell how close you are, but when you step over it, it's painfully obvious! I since upgraded the machine to a 2xP4-2.4Ghz and have sustained rates of over 50 pages/second without any issues.
I would think that most forum's wouldnt need this type of throughput, but I would strongly encourage anyone looking to deploy mod_gzip to at least profile their server (i.e. stress test) to get a feel for where the breakdown is with your configuration.
If that's true, it means that more that 50% of your visitors are first timers and you want the fastest loading page possible. That first page view for a first time visitor is the most critical. Speed isn't the only thing, it's everything (or vice versa!?).
It's that all important out of the box experience. On the web, that means speed is critical. Slow loading pages and they will resist going farther into the site. Fast loading pages, and they are more likely to stick around and view more.
how do you explicitly make js css and images cacheable?
If you use an apache server, have the following added to you configuration. It will add the necessary headers to cache images and javascript files.
# Expire in one week
ExpiresActive On
ExpiresByType image/gif A604800
ExpiresByType image/jpeg A604800
ExpiresByType image/png A604800
ExpiresByType image/x-icon A604800
ExpiresByType application/x-javascript A604800
In IIS is as simple to put them in another directory and from the IIS panel select the properties of that directory (right button over it). There's a section where you can modify all the properties related to these files, like how long should be cached before fetching them another time (I don't remember exactly what section was, and now I'm at home and I don't have a IIS installed ;-)
In the long run, though, I think some of the suggestions about compression and caching will have a big impact across the entire site.
As for the bandwidth stuff:
1) Cut any animated gifs completely. Many forums have some emoticons that are animated. Its a huge waste of bandwidth.
2) Don't just reduce the number of messages per page. Experiment with it. Remember, users may end up viewing more pages if you reduce the messages per page, and this has the massive overhead of the rest of your HTML template.
3) Force users to register before they can view the forums (not the most friendly thing in the world, but it will keep down page views).
4) There are numerous HTML tricks you can use to reduce bloat. Definitely use css for redundant styles, but you can also do things such as reduce colors to 3 characters instead of 6 (#EE9966 -> #E96). You can detect a browser on the server side, and if it supports advanced CSS, you can do away with all the tables on the page and run the layout w/ external css (this of course has an even better effect on multiple page views).
5) Kill comments/alt tags.
6) Keep a page view count on every ip and restrict them to say 50/day or something crazy high to cut out bad guys.
