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 to
> >>>>>> have 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){return
> >>>>>>>
> r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new
> >>>>>>> RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('(G(){9(1m E!="W")H
> w=E;H
> >>>>>>> E=18.15=G(a,b){I 6 7u E?6.5N(a,b):1u E(a,b)};9(1m $!="W")H
> D=$;18.$=E;H
> >>>>>>> u=/^[^<]*(<(.|\\s)+>)[^>]*$|^#(\\w+)
> >>>>>>>
> >>>>>>> etc... etc...
> >>>>>>>
> >>>>>>> This is run every time the document is loaded (onload) which is
> quite a
> >>>>>>> hit 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 like
> mod_gzip
> >>>>>>> which 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 using
> unzipped
> >>>>>>> (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 to
> make
> >>>>>>> any 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 not
> worth
> >>>>>>> it. Furthermore the core developers only have so much time, and I
> think
> >>>>>>> in that respect it's also a waste of their time if they had to
> support
> >>>>>>> this.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Sebastiaan
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Alex Objelean wrote:
> >>>>>>>> What do you mean by "unpacked"?
> >>>>>>>> "packing" = "minified", using Rhino Shrinksafe of JSMin or Yahoo
> tool for
> >>>>>>>> this purpose.
> >>>>>>>> It is indeed does not result in a performance boost, but it is
> still an
> >>>>>>>> improvement.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 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, or
> the
> >>>>>>>>> hoster?
> >>>>>>>>>
> >>>>>>>>> I experimented with the packed js, but in general I hardly notice
> the
> >>>>>>>>> overhead for some js (the sum of the size of images is often
> bigger than
> >>>>>>>>> the sum of all the js). Furthermore, the js is static: it almost
> never
> >>>>>>>>> changes, so the it is downloaded only once! Also, if the js is
> reused
> >>>>>>>>> accross pages, then it's only downloaded once on one page! Thus
> you are
> >>>>>>>>> optimizing for the very first pageload.
> >>>>>>>>>
> >>>>>>>>> However, the js has to be unpacked by the client EVERY SINGLE PAGE
> VIEW.
> >>>>>>>>> When using the packed jQuery lib, I really NOTICED this a lot. It
> was
> >>>>>>>>> VERY irritating (couple 100 ms delay every time I view ANY page on
> my
> >>>>>>>>> site).
> >>>>>>>>>
> >>>>>>>>> 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 is
> applicable
> >>>>>>>>>> to
> >>>>>>>>>> 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#a14024597
> >>>>>>
> >>>>>> Sent 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]
