Wisdom of gzipping web pages
in [Java Programming]
|
Prev: example of a logic bug using pseudocode
Next: Two stuck threads in synchronized method - at least it seems like from a stack trace
From: Roedy Green on 21 Jul 2008 18:57 What are your thoughts on the wisdom of gzipping web pages to be served to the general public to view with a browser? Does it buy you much in speed? What percent of browsers support it? Any non-obvious advantages/disadvantages? -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
From: Daniel Pitts on 21 Jul 2008 19:17 Roedy Green wrote: > What are your thoughts on the wisdom of gzipping web pages to be > served to the general public to view with a browser? > > Does it buy you much in speed? > What percent of browsers support it? > > Any non-obvious advantages/disadvantages? > CPU time vs bandwidth is the main trade-off. In the general case, I wouldn't worry about it (and would probably leave it off). For high-scale systems, it depends on the average size of your documents, your server CPU power, your bandwidth, and your average users bandwidth. With so many factors that can tip the scale one way or another, it takes an in-depth cost/benefit analysis to decide. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Peter Duniho on 21 Jul 2008 20:28 On Mon, 21 Jul 2008 16:17:13 -0700, Daniel Pitts <newsgroup.spamfilter(a)virtualinfinity.net> wrote: > Roedy Green wrote: >> What are your thoughts on the wisdom of gzipping web pages to be >> served to the general public to view with a browser? >> Does it buy you much in speed? >> What percent of browsers support it? >> Any non-obvious advantages/disadvantages? >> > CPU time vs bandwidth is the main trade-off. In the general case, I > wouldn't worry about it (and would probably leave it off). For > high-scale systems, it depends on the average size of your documents, > your server CPU power, your bandwidth, and your average users bandwidth. > With so many factors that can tip the scale one way or another, it > takes an in-depth cost/benefit analysis to decide. Though, it seems to me that if bandwidth has already been found to be a high cost, and the pages can be pre-compressed (i.e. don't have dynamic content, or at least the content varies little enough that caching will be effective), _and_ support at the receiving end can be assumed, then the answer may be more obviously in favor in that case. Of course, it also depends on whose cost you're trying to reduce. It's a more obvious win if you're trying to reduce download times for clients, or targeting mobile platforms. It's less obvious if all of the costs being balanced are borne at the server end. Personally, I didn't realize any browsers supported compressed streams as HTTP responses, but I guess that's mainly just because I know so little about the more esoteric details of HTTP. :) Pete
From: Zig on 21 Jul 2008 20:37 On Mon, 21 Jul 2008 18:57:00 -0400, Roedy Green <see_website(a)mindprod.com.invalid> wrote: > What are your thoughts on the wisdom of gzipping web pages to be > served to the general public to view with a browser? > > Does it buy you much in speed? It does add overhead for the client and server. For most servers though, that overhead tends to be small in comparison to the application logic of building the page. For clients, the decompression overhead is negligable in comparison to rendering the page. The bandwidth improvement is pretty impressive for apps that generate gobs of HTML and inline javascript. For well optimized HTML, the bandwidth gain / overhead trade-off is more relevant. But for a mere web server that has a cpu typically sitting idle, making the cpu do compression practially gives the user a significant boost in bandwidth. I think IIS 7 recommends turning gzip on by default now for static and dynamic content? It is hard to go wrong with IIS's "Compress static content" option though. > What percent of browsers support it? As far as browsers go, I'm pretty sure Opera, FireFox, IE, Safari, and others support it; I can't think of any *current* browsers that don't support it off the top of my head. The browser has to send a Accept-Encoding: gzip header to the server to indicate gzip support. I assume for Apache Tomcat or mod gzip, the sample configs should by default include a list known defective User Agents, where that header is intentionally ignored. > > Any non-obvious advantages/disadvantages? > IE 5 & 6 had a bug a while back. In the case where your document had: <script src="blah.js" /> It would send the Accept-Encoding when requesting the .js file, but then it's javascript parser would not check the result to see if it was gzipped before parsing it as javascript. AFAIK, that bug was cleared up in one of the IE service packs, so anyone who's done a Windows Update in the last couple years (or updated to IE 7) should be fine. That one is a bit hairy though, since I don't think the User-Agent string changed after the fix, and thus the server does not have enough information to determine whether or not the browser is defective. HTH, -Zig
From: Kevin McMurtrie on 22 Jul 2008 01:05
In article <1u4a84dltp25aln4p20gtcnf9omeiqnfou(a)4ax.com>, Roedy Green <see_website(a)mindprod.com.invalid> wrote: > What are your thoughts on the wisdom of gzipping web pages to be > served to the general public to view with a browser? > > Does it buy you much in speed? > What percent of browsers support it? > > Any non-obvious advantages/disadvantages? It can help if your pages must have lots of froufrou on them. Chunked encoding, Keep-Alive, and Cookie scoping are worth looking up too. -- Goolge is a pro-spamming service. I will not see your reply if you use Google. |