It is true that mod_gzip *does* compress the entire response before starting transmission to the client. I'm sure it could stream it with modern apache architecture, but it hasn't been updated since 2002 from what I can see. However on modern servers compressing 180 kB files takes a few milliseconds (+/- 20 ms on my laptop), so I seriously doubt you'll notice.
Just as an example, assuming I can download 1.6 MB/s on my rather fast 20 mbit ADSL connection (which is pretty close, except that only some sites actually give me that), then transferring 180 kB takes:
uncompressed: 180 kB / 1600 kB/s = .1125 s, starting immediately compressed: 34 kB / 1600 kB/s + 0.020 s = .0413 s, starting after 0.020 sThus even on my FAST connection, the actual download would be about 3 times as fast, and the delay would only be 20 milliseconds. If the connection is slower, the gain will be larger.
What's more, I believe that Tomcat/Jetty's gzip filters actually *do* stream the data immediately.
Regards, Sebastiaan Johan Compagner wrote:
Personally i dont like gzipped html sites, because has to load first the complete stream before it does anything, or is that changed nowadays? On 11/29/07, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:Matej Knopp wrote:No. Only javascript resources. They are static and the gzipped version is cached. Gzipping generated html every time seems like a waste of resources to me.Actually I use mod_gzip a lot in production because I have apache proxying stuff anyway. Jetty has a gzip filter and I'm sure tomcat has something similar, so you can keep it all java if you want. CPU is something that is very over-abundant on most modern webservers; mod_gzip has a really tiny performance penalty and unless you have a REALLY high volume site, you're not even going to notice it. If you can make the pages snappier by gzipping it to limit the bandwidth required by the *client*, I think it's worth it. Regards, Sebastiaan-Matej On Nov 29, 2007 1:52 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:Didn't know that; that's nice. :-) Learn something new every day. Do you also serve the HTML gzipped? Regards, Sebastiaan Matej Knopp wrote:We do also serve javascript gzipped, so there is no reason for using mod_gzip either. -Matej On Nov 29, 2007 1:48 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:I'm with Matej on this one. 2 files to maintain, extra code logic in Wicket itself to maintain, extra complexity, with no real gain. Wicket markup can already be "minimified" (see Matej's other mail), and I really think using something like mod_gzip is a much better option: separation of concerns and you get compression on other stuff as well. Regards, Sebastiaan Matej Knopp wrote:But that would mean maintaining two files for every script. Which means at least a compilation time dependency. And I still don't see good reason for this. -Matej On Nov 29, 2007 1:26 PM, Alex Objelean <[EMAIL PROTECTED]>wrote:Sebastiaan, Matej, I think you get me wrong. I do not suggest to minify the js files in runtime. What I suggest,is tohave both, for instance: wicket-ajax.js & wicket-ajax.pack.js, in the distributed jar. And include the wicket related js this way: if (Application.DEVELOPMENT .equalsIgnoreCase(Application.get().getConfigurationType())){add(HeaderContributor.forJavaScript(new ResourceReference( AbstractDefaultAjaxBehavior.class,"wicket-ajax.pack.js")));} else { add(HeaderContributor.forJavaScript(new ResourceReference( AbstractDefaultAjaxBehavior.class, "wicket-ajax.js"))); } Alex. Sebastiaan van Erk wrote:I'm talking about packers (like the jQuery packed version): What I see in jQuery.pack.js:eval(function(p,a,c,k,e,r){e=function(c){return(c<a?'':e(parseInt(c/a)))+ ((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};if(!''.replace(/^/,String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){returnr[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(newRegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('(G(){9(1m E!="W")Hw=E;HE=18.15=G(a,b){I 6 7u E?6.5N(a,b):1u E(a,b)};9(1m $!="W")HD=$;18.$=E;Hu=/^[^<]*(<(.|\\s)+>)[^>]*$|^#(\\w+) etc... etc... This is run every time the document is loaded (onload) which isquite ahit on client side performance. I guess removing extra whitespace or shortening variable names could help some (minimizer), but I think it's pretty much useless in most cases. I think a better options is installing something likemod_gzipwhich can also gzip outputted html. In the jQuery case: jQuery is 79 kb plain unzipped. jQuery is 46 kb minimized unzipped. jQuery is 26 kb plain gzipped. jQuery is 13 kb minimized gzipped. The difference in this case is 33 kb a single time when usingunzipped(because it's cached after load), and 13 kb a single time when using mod_gzip. If your site has any number of images they're going tomakeany gains you're going to get out of this quite irrelevant IMHO. Personally I think it's a waste of time and the extra complexity of packed/nonpacked in deployment/development mode is seriously notworthit. Furthermore the core developers only have so much time, and Ithinkin that respect it's also a waste of their time if they had tosupportthis. Regards, Sebastiaan Alex Objelean wrote:What do you mean by "unpacked"? "packing" = "minified", using Rhino Shrinksafe of JSMin or Yahootool forthis purpose. It is indeed does not result in a performance boost, but it isstill animprovement. Sebastiaan van Erk wrote:I don't really understand the desire to pack js. For who do you want to reduce the overall traffic? The client, orthehoster? I experimented with the packed js, but in general I hardly noticetheoverhead for some js (the sum of the size of images is oftenbigger thanthe sum of all the js). Furthermore, the js is static: it almostneverchanges, so the it is downloaded only once! Also, if the js isreusedaccross pages, then it's only downloaded once on one page! Thusyou areoptimizing for the very first pageload. However, the js has to be unpacked by the client EVERY SINGLE PAGEVIEW.When using the packed jQuery lib, I really NOTICED this a lot. ItwasVERY irritating (couple 100 ms delay every time I view ANY page onmysite). Regards, Sebastiaan Alex Objelean wrote:It would be nice to have 2 versions of each js: original &packed.For instance: wicket-ajax.js & wicket-ajax.pack.js Also to use the packed version in DEPLOYMENT model. This isapplicableto other js from the wicket-core & wicket-extensions. The idea is to reduce the overall traffic. Any thoughts? Alex-- View this message in context:http://www.nabble.com/-RFE--packed-JS-in-DEPLOYMENT-mode.-tf4896243.html#a14024597Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
