DISQUS

unscriptable · 8 months ago

What about the time at the browser? One of my clients turned gzip off since it was hurting the responsiveness due to lagging browser performance.

They last tested during the days of IE6 and FF1.0, though. I imagine that the clients are much faster now, but this analysis isn't complete without an end-to-end comparison.

Ade · 8 months ago

Good point.

figvam · 8 months ago

Decompressing GZIP is an order of magnitude faster than compressing it. I wonder what hardware they have used for their testing?

DGentry · 8 months ago

> Inevitably, someone will argue that they can't spare a few ms
> per page to compress the data, even though it will make their
> site much more responsive.

I used to work on drivers for network interfaces, some years ago. Transmitting a packet from the web server isn't free. Depending on the OS it might first need to be copied from the web server into the kernel, then be processed by the kernel's IP stack, split up into 1500 byte chunks for the ethernet interface with TCP/IP headers prepended, and finally enqueued for DMA.
10-15 usec of CPU time to transmit a maximum sized TCP/IP frame to an ethernet interface is not unreasonable.

Your compression test reduced the HTML size by 110636 bytes, which would reduce the number of ethernet frames transmitted by 76 packets. Thats about 0.75 to 1.1 msec of CPU time.
Additionally, those 76 packets would have required 38 acknowledgements from the remote system to be processed. Processing received packets is slightly more expensive because an interrupt is generally required, so I'll assume 15-20 usec. Thats another 1/2 to 3/4 msec of CPU.

Finally, of those 9 msec about half were in user space to run the actual compression code, and half was spent in the filesystem. A web server compressing data in memory wouldn't have so much system overhead. The actual CPU time consumed would be closer to 5 msec.

So where did we end up? We spent 5 msec of CPU time on compression, but we save 1-2 msec in CPU cost elsewhere. Spending the time on something highly compressible like HTML saves CPU time elsewhere in the system.

I'll agree with Ivo that there is significant startup time in compression operations, compressing a bunch of small files takes longer than one big file. Nonetheless its still a pretty good tradeoff.

Ivo · 8 months ago

In your speed estimates, you are overlooking the fact that gzipping many small files takes more time than gzipping one large file.

Daniel Tenner · 8 months ago

What if we're on a host that doesn't charge for bandwidth anyway? Does it still make sense to gzip everything?

paulbuchheit · 8 months ago

Yes, if you care at all about the performance of your site, you should use gzip. The real point of my calculations is to show that the CPU costs are relatively insignificant because computers are fast. Also, to be clear, gzip is only for text (html, js, css, etc), not images, video, etc since those are already compressed.

Rakesh · 7 months ago

Also, Nginx provides static gzip module http://wiki.nginx.org/NginxHttpGzipStaticModule . So all the static resources ( like CSS, js ) can be compressed one time and thus save some more CPU cycles :)

x · 8 months ago

then it comes down to user download rate

can i has unlimited happiness?

Graphain · 8 months ago

Yes, faster download times for users.
And for users on plans with severe bandwidth limits (e.g. mobile phones) you save users costs too.

Andreas Krey · 8 months ago

At least around here flatrates for mobiles become commonplace. For the speed, I regularly use port forwarding to my home proxy via compressed ssh. That way the ssh tunnel takes care of any compression (including headers), and I don't need to care about safety of any wireless stuff.

SyP · 8 months ago

What about IE6 + gzip bugs?

Adam · 8 months ago

IE6 users are accustomed to poor performance at this point, so might as well do a browser check and don't serve gzipp'ed content if that's the case.

Saiyine · 8 months ago

Most dot com providers ban the use of the gzip encoding because the CPU usage.

David Berrebi · 8 months ago

Interesting stuff, thanks

Marvin · 8 months ago

Can you share insight about using nginx as a reverse proxy? What config script its better? Thanks!

Managed Hosting · 8 months ago

Everyone should be gzipping. Depending on the level of compression you will have an increase in your cpu utilization.

Ade · 8 months ago

Nice little app.

Varun Mathur · 8 months ago

Interesting article Paul. I'd add the following for AJAX-based web applications to make things very zippy for the user:

1. Concatenate your JS and CSS files. Don't send out several files over the wire to the browser - the browser can only make 2 connections at a time. Be careful about JS dependencies - order is imp. in JS.

2. Minify and then compress the JS and CSS. Use Dojo's Shrinksafe or the YUI Compressor to do this. It will strip out whitespace, etc - make the code smaller in size (In JS, every byte counts) and compress.

3. Now gzip the above.

Write an Ant script to automate all the above on code commit and you are done. Try other methods like loading other elements in the background or after a tab etc is clicked - important to show something to the user almost instantly. Did this for Alertle.com, which was a 100% AJAX web app (no page refresh at all), and the initial size of the code being sent to the browser went from 700k to about 20k using the steps above :)

Julius Davies · 8 months ago

Varun Mathur's comment is excellent. To add to it:

4. I prefer to concatenate and "shrink" my CSS and JS on the server, dynamically, with every request. You may think this is a bad idea until you read #5....

5. I concatenate them into two files, with the greatest "last-modified" datestamp of all the concatenated files serving as a suffix on the filename:

concatenated_20090417_235959.js
concatenated_20090417_235959.css

And I set an HTTP "Expires" header of 1 year on these files. This way browsers almost never re-download the JS and CSS (unless it's actually changed).

I find this strikes a nice balance between performance and ease-of-maintenance: any change to the CSS or JS is picked up right away, without any need to run a build.

Jeff · 8 months ago

If you're using Wordpress, you defiantly need to be using WP Super Cache. Not only does it make Wordpress a ton faster, it has built-in options for gzip encoding.

Robert Felty · 8 months ago

I don't understand what the advantage is of minifying and compressing. Do browsers load and/or parse the uncompressed file if it is minified?

Adam · 8 months ago

"Minifying" means that you cut out all the unnecessary boilerplate, like whitespace, line breaks, function names, variable names, etc. This doesn't have anything to do with compression and doesn't affect how the browser parses your file. It's merely a way of maintaining the semantic meaning of your code while decreasing the packet size being delivered.

seo wales · 8 months ago

minifying is compression but akin to txt speak tht u uz on ur fone.

Juan · 8 months ago

always think the worst case scenario... and that is a really slow network... without gzip sites like gmail, friendfeed , mobileme will take too long to load ... most of those sites uncompressed are 1 to 2 MB (javascript mostly) and they will continue to get bigger as webapps become much more complex. If you are in a country where broadband is still defined as 500Mbps (there is still a lot of those), Gziping will make your website feel way faster and cut several seconds of your loading time

genieyclo · 8 months ago

I love how appjet.net fails the test itself.

pratyk · 8 months ago

Is your python server opensourced. Can you write a blog post about your server configuration.

John · 8 months ago

If you're running an image heavy site, in practice you wouldn't see the same level of bandwidth savings since the images are already compressed. But compression should definitely be turned on by default for text/* content types.

CG · 8 months ago

Yes. Using gzip (mod_gzip or mod_deflate) is a no-brainer. If your users are still stuck on IE6, you'll need to omit the js files from the gzipped payload. If you're really clever, you might be able to conditionally gzip files with a .js extension for IE6 user agents.

Michael · 8 months ago

need to be ABSULUTELY SURE that its not going to be a problem for older browsers and mobile browsers (on the types of phones the average person has - not just new top-end "early adopter" phones)... and even newer browsers on older (slow) hardware.

Stephen Pierzchala · 8 months ago

1. Any browser that doesn't support GZIP encoding doesn't send the 'Accept-encoding: gzip[,deflate]' header. This flags the server to sent your text files in all their brutal honesty.

2. If anyone is running a browser that is lower than IE 6.0, they have bigger issues than worrying about compression. Every browser released since 2001 handles HTTP compression flawlessly (except for the IE 6 JS issue, which is just insane and conditional responses will deal with that).

3. Measure your performance FROM THE CLIENT SIDE with and without compression. Server-side processing time is important, but how long does it take to send the file along the wire to its destination.

You can even compress content in many shared hosting Wordpress environments by placing the '<?php ob_gzhandler(); ?>' command at the very top of the header.php file.

Good luck and happy compressing.

smp
http://newestindustry.org/category/webperforman...

zuborg · 7 months ago

hehe, good and right article, just funny to see that this one page have almost 0.4MB not compressed text content (html/css/js) :

http://site-perf.com/cgi-bin/show.cgi?id=4nUAyu...

Santosh D · 7 months ago

http://gzipcheck.appjet.net/
does not use the gzip encoding!

DSarathy · 7 months ago

Good one Paul.

Nathan S · 7 months ago

Great post Paul, definitely agree that this is a must.

You mention nginx, but I wanted to add that anyone is using a reasonably modern build of apache/httpd either as their primary web content server or in a proxy-balancer configuration can also do this very very easily, and handle the historical browser issues that people mentioned:

# Deflate
AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml application/xml application/xhtml+xml text/javasc
ript application/javascript application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Ankara nakliyat · 6 months ago

try it winrar

spacer man · 6 months ago

HI! FRIEND! I VISIT YOUR BLOG ITS TOO MUCH INTERESTING


PLEASE VISIT MY BLOGS

http://www.onlinespacer.blogspot.com/
and
http://www.worldofjewellery.blogspot.com/

These blogs are for charity donation for poor childern. The money that is earn from this blog which i completely spread into them. Please Please Please I again says that Please visit those blogs and click one google add (ads by google) and send me comments on it and follow my blog as a friend Because that question not for me its for humanity! :(

eprojecthelp · 4 months ago

Are you a expert in JAVA leverage your skills to others and gain huge benefits in doing so.. use our Project help and Training features.

Log on to eProjecthelp.com today.

www.eprojecthelp.com

VasiaUVI · 3 months ago

Can you tell me please if Gzip compression is possible in Blogspot?
And if it is how can I implement it?
Thank you!