On Tue, Nov 10, 2009 at 11:06 AM, Jerome Velociter <jer...@xwiki.com> wrote:
> On 11/10/09 10:41 AM, Pascal Voitot wrote: > > On Tue, Nov 10, 2009 at 10:04 AM, Vincent Massol<vinc...@massol.net> > 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). > > and there are also libraries such as google apps or jquery in which you generally intercept the onload event to wait for end of loading before creating your widgets.... > 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< > >>> mariusdumitru.flo...@xwiki.com> 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 > >> devs@xwiki.org > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > _______________________________________________ > > devs mailing list > > devs@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
