Published in CSS on Monday, May 10th, 2004
Results of collecting snapshots of http compression data within a two month period.
Note: The "official line" on this topic is being archived and updated here.
A while back I wrote up a post that explained how you could use PHP's output buffering to take advantage of HTTP Compression and compress your CSS files. To summarize, your css files download faster by compressing them with PHP's built in compression handling (smaller filesize = shorter download, simple!).
I thought I would pass along some of the data we collected from several client sites during the months of March and April.
Note: if you aren't familiar with HTTP Compression, check out this rather long but informative article: HTTP Compression Speeds up the Web.
The data was collected in random snapshots - windows of time where we collect user data for our clients websites. Basically, if the user-agent is not some type of bot we initiate a session and set a cookie. We have some flaming-hoops (conditions) that a user must pass before real data is collected, in an effort to try and collect reliable data.
Without going into too much detail, lets just say that the data was very reliable (you'll have to take my word on this one, we've worked hard to filter out rotten data).
Similar to Apache's mod_gzip and mod_deflate functions, PHP's ob_gzhandler checks to see what type of content encoding the users browser will accept and sends the appropriate data.
For example, if your browser sends an 'accept encoding' header of 'gzip, deflate' it will receive the compressed CSS file. Otherwise it will receive an uncompressed version of the file.
Content Encoding is part of the HTTP 1.1 standard, and most modern browsers will accept compressed data (for more details see the article linked in the third paragraph). So why do we collect numbers?
Some firewall programs, and likely other devices and software, have been known to block your browser from sending the 'accept-encoding' information. When this happens, the uncompressed version of the file is delivered.
Okay, the results:
| # of sessions | # that accepted compression | % that accepted compression |
|---|---|---|
| 117956 | 94238 | 78.82 |
On average the css files were compressed to 21% of their original size.
Not much to say here, other than that it works and we're going to continue using it. We'll keep evaluating the data, to help us estimate a number for 'bandwidth savings for the overall site'.
Nice follow-up on the original article. Thanks.
Comments and Feedback