 | HTTP Compression |
| | |
Whenever a user visits any web site their browser is sent data or content that makes up the web page. It is assumed that the browser knows how to get the content and then display it. The way the browser gets the content is that it opens a connection through the internet and talks to the web server where the content is located. The browser talks to the web server using a "language" called the HyperText Transfer Protocol (HTTP) specification.
Normally when content is sent to the browser it is sent "as is" which means everything is sent from the web server to the browser as it appears on the web server. This works well for web sites that do not get much traffic, but for web sites that get increasingly large volumes of visitors it becomes more and more unsuitable. Each time a web page is transfered from one computer to another it costs someone money to transfer it. Not only does it cost more money but it drains avaliable bandwidth that could be used for other purposes.
What HTTP compression is, is a way that makes it possible to dramatically reduce the amount of data that it takes to transfer a web page. How it works is each time a user opens their browser and requests a web page from a web server, it compresses or compounds the data and thus reducing the amount of data that it sends. Then when the user recieves that compressed web page, the their browser decompresses it and they are shown the same web page as they would have if it would not have been compressed.
In an ideal world there would be an infinite amount of data that can be transferred to and from a web server at any given time. Since we do not live in an ideal world it must be realized that for each web server there is a limit on how much data it can transfer back and forth over a certain amount of time. The amount of data a web server can transfer per second is usally referred to bandwidth and measured in KB/sec. One of the advantages of using HTTP compression on a web server is that it reduces the amount of bandwidth required to serve web pages to users that request them and frees up that bandwidth so that it can be used for the delivery of more content or the increase in the quality of the content already served by the web server.
Not only does HTTP compression free up bandwidth but it speeds up the amount of time it takes for most web servers to delivery content to users viewing their web pages. Since the amount of data required to send web pages decreases so does the amount of time it takes to send them. This provides users will be more enjoyable web experience since web pages load up faster.
The HTTP 1.1 specification compresses data mainly via the gzip compression algorithm which is an open-source and widely accepted method of compressing data. There are two things that are required for HTTP compression to take place in the instance where a user requests a page from a web server. First, the web server must give the option of serving up compressed content via the HTTP 1.1 specifications. And second, the user requesting the web page must have a web browser that support HTTP 1.1 and the HTTP compression aspects of the specification. Most modern browsers such as Internet Explorer, Netscape, Mozilla, and Opera include support for HTTP compression. Any other web browser that adheres to the specifications of version 1.1 of the HyperText Transfer Protocol most likely includes support for HTTP compression. The reason version 1.1 is required for HTTP compression to occur is that HTTP compression was not included until 1.1 and thus version 1.0 does not include support for HTTP compression. In some instances such as the use of a proxy server, the HTTP 1.0 specification is used. In this case the web browser must turn on support for HTTP 1.1 through proxy servers or the web server must provide support for HTTP compression by HTTP 1.0 requests.
The amount of data that will be compress for any given web page depends on the amount of reoccuring characters that are contained in it. Compression works best on text-based files such as HTML (HyperText Markup Language), ASP, PHP, and CGI. Since a web-page is a text-based file it is possible to get between 70-90% compression on it. Many web pages include pictures on them and it is important to know that HTTP compression does not compress the pictures that are referred to from the web page, it just compresses the text-based web page itself. Many web server plugins will actually include routines that will compress or resample pictures and images and send those to the user viewing the web page instead of the original pictures. Although this is not part of HTTP compression, it does reduce the amount of bandwidth required to serve up a web page even further. The only problem is that not only does resampling reduce the quality of the pictures, it also reduces the quality of the content on the web page. In a world where image is everything it is important that the images on a web page are served up in a decent manor. The reason HTTP compression does not include compression for images is that most images are already compressed (ie. JPG, GIF, BMP, etc.) and to compress them further would be a waste of web server processing time and resources because of the fact that the gain via compression is very little.
Many web server compression plugins use caching to reduce the amount of system resources required to initally compress web pages and to also try and to further speed up the amount of time it takes to send compressed web pages. How it works is they compress the data once and save a copy of it somewhere on the web server. When a user requests that page, the saved, already compressed version of it is sent instead. What this does is saves the web server the time of actually having to recompress the web page agian. The problem with this is that most web pages today are dynamic. Web pages that are dynamic are web pages that change each time it is displayed. Web pages that are dynamic would be those created with PHP, ASP, CGI, and Perl. Since the page is constantly changing it is not wise to have the page cached on the web server since it would just be a waste of disk space and server resources. Some other disadvantages of using HTTP compression with caching arise when it is time to figure out which page should be cached where and when and also when the web pages have to be written to the hard disk. Writing the cached pages to RAM memory can get even more harry when trying to figure out which pages have been cached and which have not been. The fact of matter is that caching does not improve on the speed it takes to serve up web pages as much as it claims. Web page compression actually takes very little system resources in the first place and it also reduces the amount of time it takes to send the actual web page enough where it does not even matter anymore. One of the worst implementations of HTTP compression is with the use of caching. The main reason is that HTTP compression is used to improve bandwidth transfering where as caching is used to improve speed performance. The mixing of these two technologies can become confusing and at most times just cumbersome.
Today many web servers are starting to use HTTP compression and are also beginning to see the benefits First and foremost, HTTP compression reduces the amount of bandwidth required for web servers to serve up web pages. In doing such, HTTP compression results in faster web page delivery and load times. Faster web page load times result in a better user experience when browsing the web site and the happier the user the more likely they will by products or return to the web page. HTTP compression is already integrated into browsers that adheard to HTTP 1.1 specifications, which includes almost all browsers to-date, and therefore there is no reason why HTTP compression should not be used on web servers. HTTP compression is a technology that should be taken advantage of by all web server administrators to help reduce bandwidth, bandwidth costs, web page delivery times, and also web page load times.
Take advantage of HTTP compression today, get ISAPIZip!
|
|
