On 11/10/09 11:06 AM, Jerome Velociter wrote: > On 11/10/09 10:41 AM, Pascal Voitot wrote: >> On Tue, Nov 10, 2009 at 10:04 AM, Vincent Massol<[email protected]> 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... > > I really think compressing / compiling together JS is for us the tip of > an iceberg in terms of JS optimization. > > As I said previously on this thread, we can't do that for JavaScript > extensions which are loaded conditionally in a non-predictable manner. > They represent more than half the JS files we load on the home page > today for example. > > Note that we should find a way in the JSFX to declare an extension being > "loaded on all pages" (it's not possible yet), so that extensions such > as jump to page and other common widgets can be aggregated with other > "always served" JS. > > But even if we do that, remains all the extensions added on demand > (there are some on the home page, too) that can be solved but by an > asynchronous script loading mechanism (see > http://www.stevesouders.com/blog/2008/12/27/coupling-async-scripts/ for > example).
A candidate library to implement this would be http://developer.yahoo.com/yui/get/ Jerome. > > My 2 cents, > Jerome. >> >> >>> 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< >>>> [email protected]> 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-files-for-faster-loading/ >>>>>>>> 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 >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
