Reduce Webserver Bandwidth
Most hosting and server leasing suppliers only provide a limited amount of bandwidth for your webserver, usually through a monthly cap, with extra bandwidth costing significantly more. By reducing your bandwidth your pages require, you can support more users while keeping your costs down. You'll also improve the load times of your pages.Compress the Pages
An average 30K web page can easily be compressed down to just 3K, which means that for the extra few milliseconds it takes to compress it, you not only save bandwidth, but you also deliver the page much faster to the user, especially if that user is on a dialup or a heavily contended connection.Both IIS and apache support compression (as do all modern browsers). IIS has the functionality built in, apache 1.3 uses mod_gzip and apache 2 uses mod_deflate.
There is usually no point turning on compression for images, but remember to turn on compression for not just html pages, but javascript files, css and xml (rss feed) files.
An example setup for apache 2 with mod_deflate to compress everything except images
<Location /> # Insert filter SetOutputFilter DEFLATE# Netscape 4.x has some problems... BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don't compress images SetEnvIfNoCase Request_URI \ \.(?:gif|jpe?g|png)$ no-gzip dont-vary
# Make sure proxies don't deliver the wrong content Header append Vary User-Agent env=!dont-vary </Location>
Once you have turned on compression your log files should show you delivering pages much faster, which improves the end-user's experience of your site.
Set Expires Header
If most of your users usually read more than just one page, then setting a page expires header will reduce the amount of requests your webserver has to handle. Setting the expires header tells the browser to used it's cached copy of the file (be it an image, css, js or html file) rather than requesting a new copy.Although most repeat requests for pages, images etc set the 'if-modified-since' header so the web server only returns data if the item has been updated since the last time the browser requested it (unlikely for an image/css etc), the browser still has to ask the webserver just in case. By setting the expires header you have saved a request and response.
You can also set expires headers for dynamic content, such as php pages. If your site only gets updated a couple of times a day, then you may as well at least set a 15 minute expiry for dynamic content, so as a users browses your site, they don't need to re-request unchanged content.
The big benefit is if your page contains lots of small images, javascript includes, or style sheet includes, as after the first page a user visits, they don't even need to request them again, which decreases your server load/bandwidth, and improves the speed for the user.
Both IIS and apache support expire headers, apache through mod_expires, or for dynamic content, you can add an expires header by hand.
An example mod_expires setup for apache 2 which sets a default 10 minute expiry for all files, a one day expiry for images, and no expiry for dynamic php content
<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault A600
ExpiresByType image/gif "access plus 1 day"
ExpiresByType image/jpeg "access plus 1 day"
ExpiresByType image/png "access plus 1 day"
ExpiresByType image/x-icon "access plus 1 day" <FilesMatch "\.(php|php4)$">
ExpiresByType text/html "now"
</FilesMatch>
</IfModule>
You can check the expires headers are being set using the live http headers extension for firefox, which displays all the request and response headers.
Remember that if you use a long expiry for any content, then when you edit the content, your browser will still display the cached version until the expiry time has passed, unless you force the browser to reload the page, or flush your browsers cache. For this reason, it's best to only set expire headers on live sites, not development sites.
Of CSS and Javascript
Using CSS to define your pages style, rather than using lots of font tags to explicitly define how you want the page to appear, always makes sense as it produces much more manageable and tidy code. The same is true for javascript, using functions rather than inline code makes the page easier to maintain.
However whether you move those CSS statements and javascript functions to external files, or statically include them in every page will depend on how your users visit your site.
If most of your users just visit one page, and then leave - never to return, then statically including all of the style and script statements at the top of the page will reduce the number of requests the user's browser makes, which will slightly reduce the bandwidth and speed of your pages.
But if most of your users visit more than one page on each visit then including the style and scripts in separate files, will result in less data being sent to the user for each subsequent request (assuming the style and script code is common across the site).
<link href="/style/css/site.css" rel="stylesheet" type="text/css" /> <script src="/js/common.js" type="text/javascript"></script>
Setting the expires headers for .css and .js files will help reduce your bandwidth even more.
Reduce Image Size
Large images can be one of the greatest drains on bandwidth for a site, so taking a little care to reduce the image size can help a lot.
Firstly check that the image format you have chosen is producing the smallest results. Many site logos are saved a jpeg files, when gif or png would produce smaller results.
For photographs, look at reducing the jpeg quality to see how much of an effect that has on the file size. Also consider using thumbnails instead of full size images in your page. You can still link the thumbnail to a larger copy of the image, but you will be suprised how many users are quite happy just seeing the thumbnail, and don't click to get a larger image.
If you have the same logo on each page, then you only really need to worry about speeding up that first page load.
