On Nov 10, 2009, at 9:56 AM, Pascal Voitot wrote: > Have you seen my mail about JAWR which is exactly this : > "On the other hand wro4j allows you to organize your resources in > groups > and supports gzip compression." > > if you need JS optimization, I think Google Closure Compiler is the > way to > look at... With chrome and all the work they do around JS, they are > certainly the ones to follow just now :) We're already minifying our JS both at build time and at runtime (although we could switch to Google Closure at some point in the future if it's better).

But I don't think Google Closure will merge CSS and JS files together.

Re JAWR indeed we've already mentioned it several times on http://jira.xwiki.org/jira/browse/XWIKI-2022 (the lead dev for it has even commented in that issue!). We should definitely evaluate it vs wro4j.

>>>>>>>> more >>>>>>> than half people would drive away from a site with slow loading >>>>>>> pages. >>>>>>> >>>>>>> There are several interesting issues that could be implemented >>>>>>> to >>>>>>> substantially improve page loading time in XWiki. >>>>>>> >>>>>>> Number one is aggreation of CSS and JS files in order to reduce >>>>>>> HTTP >>>>>>> requests. (For info, we have a total of 25 external CSS and JS >>>>>>> files on a >>>>>>> basic XWiki install when in the best world we would have just >>>>>>> 2 - >>>>>>> 1 CSS and >>>>>>> 1 JS) >>>>>>> >>>>>>> Someone interrested in working on this with me ? _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Have you seen my mail about JAWR which is exactly this : "On the other hand wro4j allows you to organize your resources in groups and supports gzip compression." if you need JS optimization, I think Google Closure Compiler is the way to look at... With chrome and all the work they do around JS, they are certainly the ones to follow just now :)

regards Pascal On Tue, Nov 10, 2009 at 9:45 AM, Marius Dumitru Florea< mariusdumitru.florea(a)xwiki.com&gt; wrote: > Hi Vincent, > > Vincent Massol wrote: >> On Nov 10, 2009, at 8:58 AM, Vincent Massol wrote: >> >>> Hi Marius, >>> >>> On Nov 5, 2009, at 6:56 PM, Marius Dumitru Florea wrote: >>> >>>> Jerome Velociter wrote: >>>>> Hi Thibaul, all >>>>> >>>>> Something easy to do that would contribute to reduce the number >>>>> of >>>>> CSS >>>>> files is to concatenate all the WYSIWYG CSS files from the >>>>> various >>>>> plugins at build time (there are more than 10 AFAIK). Marius, >>>>> have >>>>> you >>>>> looked into this? Do you know if this could be done in the 2.1 >>>>> timeframe ? >>>> There are I think three steps to be taken in order to minimize the >>>> CSS load: >>>> >>>> 1) expand @import url('someURL'); >>>> 2) concatenate CSS files >>>> 3) minify the resulted CSS file >>>> >>>> So far I haven't found a tool to expand the CSS import >>>> declaration. >>>> Maybe I could write a small maven plugin for this. >>> I've found this: >>> http://raibledesigns.com/rd/entry/javascript_and_css_concatenation >>> >>> which leads to wro4j: http://code.google.com/p/wro4j/ > > wro4j seems to be a runtime optimizer while YUI Compressor is a build > time optimizer. I'm not sure which approach is the best. On the maven > YUI Compressor site they say: > > "Because Javascript compression could need time and resource, and to > avoid repetitive (stupid) resources consumming at runtime, this > plugin > do compression of static files at compile time." > > On the other hand wro4j allows you to organize your resources in > groups > and supports gzip compression. > >> >> hmmm.... >> http://code.google.com/p/wro4j/wiki/KnownIssues > > I'll drop the @import declarations and merge the CSS files instead. > > Thanks, > Marius > >> >> -Vincent >> >>> Sounds promising. >>> >>> Thanks >>> -Vincent >>> >>>> I think we can adapt to maven what is presented in this article >>>> >

>>>> in order to achieve the last two steps. >>>> >>>> Marius >>>> >>>>> Note that the target of 1 CSS and 1 JS is pretty challenging for >>>>> XWiki >>>>> as we are also making it a modular software where CSS and JS >>>>> extensions >>>>> can be conditionally loaded on some (not all) of the pages. >>>>> Something to >>>>> investigate for JavaScript extensions could be a dynamic JS >>>>> loading >>>>> mecanism, a la dojo >>>>> ( >

>>>>> ) >>>>> >>>>> Jerome. >>>>> >>>>> PS: I put devs in copy as this is more a developer topic. >>>>> >>>>> On 11/5/09 5:28 PM, Thibaut Camberlin wrote: >>>>>> Hi all, >>>>>> >>>>>> Page Loading time is a very important criteria when developing a >>>>>> web site. >>>>>> According to a recent >>>>>> survey< >

>>>>>>> more >>>>>> than half people would drive away from a site with slow loading >>>>>> pages. >>>>>> >>>>>> There are several interesting issues that could be implemented >>>>>> to >>>>>> substantially improve page loading time in XWiki. >>>>>> >>>>>> Number one is aggreation of CSS and JS files in order to reduce >>>>>> HTTP >>>>>> requests. (For info, we have a total of 25 external CSS and JS >>>>>> files on a >>>>>> basic XWiki install when in the best world we would have just >>>>>> 2 - >>>>>> 1 CSS and >>>>>> 1 JS) >>>>>> >>>>>> Someone interrested in working on this with me ?

On Tue, Nov 10, 2009 at 10:04 AM, Vincent Massol&lt;vincent(a)massol.net&gt;   wrote: > On Nov 10, 2009, at 9:56 AM, Pascal Voitot wrote: > >> Have you seen my mail about JAWR which is exactly this : >> "On the other hand wro4j allows you to organize your resources in >> groups >> and supports gzip compression." >> >> if you need JS optimization, I think Google Closure Compiler is the >> way to >> look at... With chrome and all the work they do around JS, they are >> certainly the ones to follow just now :) > We're already minifying our JS both at build time and at runtime > (although we could switch to Google Closure at some point in the > future if it's better). > > apparently it's really efficient but I'm not a JS expert enough to consider its real power...

> But I don't think Google Closure will merge CSS and JS files together. > > no i don't think so :) > Re JAWR indeed we've already mentioned it several times on > http://jira.xwiki.org/jira/browse/XWIKI-2022 >    (the lead dev for it has even commented in that issue!). We should > definitely evaluate it vs wro4j. > > don't know wro4j... should have a look at it, just to know! > Thanks > -Vincent > >> regards >> Pascal >> >> >> On Tue, Nov 10, 2009 at 9:45 AM, Marius Dumitru Florea< >> mariusdumitru.florea(a)xwiki.com&gt;   wrote: >> >>> Hi Vincent, >>> >>> Vincent Massol wrote: >>>> On Nov 10, 2009, at 8:58 AM, Vincent Massol wrote: >>>> >>>>> Hi Marius, >>>>> >>>>> On Nov 5, 2009, at 6:56 PM, Marius Dumitru Florea wrote: >>>>> >>>>>> Jerome Velociter wrote: >>>>>>> Hi Thibaul, all >>>>>>> >>>>>>> Something easy to do that would contribute to reduce the number >>>>>>> of >>>>>>> CSS >>>>>>> files is to concatenate all the WYSIWYG CSS files from the >>>>>>> various >>>>>>> plugins at build time (there are more than 10 AFAIK). Marius, >>>>>>> have >>>>>>> you >>>>>>> looked into this? Do you know if this could be done in the 2.1 >>>>>>> timeframe ? >>>>>> There are I think three steps to be taken in order to minimize the >>>>>> CSS load: >>>>>> >>>>>> 1) expand @import url('someURL'); >>>>>> 2) concatenate CSS files >>>>>> 3) minify the resulted CSS file >>>>>> >>>>>> So far I haven't found a tool to expand the CSS import >>>>>> declaration. >>>>>> Maybe I could write a small maven plugin for this. >>>>> I've found this: >>>>> http://raibledesigns.com/rd/entry/javascript_and_css_concatenation >>>>> >>>>> which leads to wro4j: http://code.google.com/p/wro4j/ >>> wro4j seems to be a runtime optimizer while YUI Compressor is a build >>> time optimizer. I'm not sure which approach is the best. On the maven >>> YUI Compressor site they say: >>> >>> "Because Javascript compression could need time and resource, and to >>> avoid repetitive (stupid) resources consumming at runtime, this >>> plugin >>> do compression of static files at compile time." >>> >>> On the other hand wro4j allows you to organize your resources in >>> groups >>> and supports gzip compression. >>> >>>> hmmm.... >>>> http://code.google.com/p/wro4j/wiki/KnownIssues >>> I'll drop the @import declarations and merge the CSS files instead. >>> >>> Thanks, >>> Marius >>> >>>> -Vincent >>>> >>>>> Sounds promising. >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>>> I think we can adapt to maven what is presented in this article >>>>>> > http://www.samaxes.com/2009/05/combine-and-minimize-javascript-and-css-file… >>>>>> in order to achieve the last two steps. >>>>>> >>>>>> Marius >>>>>> >>>>>>> Note that the target of 1 CSS and 1 JS is pretty challenging for >>>>>>> XWiki >>>>>>> as we are also making it a modular software where CSS and JS >>>>>>> extensions >>>>>>> can be conditionally loaded on some (not all) of the pages. >>>>>>> Something to >>>>>>> investigate for JavaScript extensions could be a dynamic JS >>>>>>> loading >>>>>>> mecanism, a la dojo >>>>>>> ( > http://dojocampus.org/content/2008/10/09/dojo-module-packaging-and-loading/ >>>>>>> ) >>>>>>> >>>>>>> Jerome. >>>>>>> >>>>>>> PS: I put devs in copy as this is more a developer topic. >>>>>>> >>>>>>> On 11/5/09 5:28 PM, Thibaut Camberlin wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Page Loading time is a very important criteria when developing a >>>>>>>> web site. >>>>>>>> According to a recent >>>>>>>> survey< > http://www.webdesignerwall.com/general/users-place-more-weight-on-design/ >>>>>>>>> more >>>>>>>> than half people would drive away from a site with slow loading >>>>>>>> pages. >>>>>>>> >>>>>>>> There are several interesting issues that could be implemented >>>>>>>> to >>>>>>>> substantially improve page loading time in XWiki. >>>>>>>> >>>>>>>> Number one is aggreation of CSS and JS files in order to reduce >>>>>>>> HTTP >>>>>>>> requests. (For info, we have a total of 25 external CSS and JS >>>>>>>> files on a >>>>>>>> basic XWiki install when in the best world we would have just >>>>>>>> 2 - >>>>>>>> 1 CSS and >>>>>>>> 1 JS) >>>>>>>> >>>>>>>> Someone interrested in working on this with me ? > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs