[xwiki-devs] [xwiki-users] Page Loading Optimization

Pascal Voitot pascal.voitot.dev at gmail.com
Tue Nov 10 10:09:14 UTC 2009


On Tue, Nov 10, 2009 at 11:06 AM, Jerome Velociter <jerome at xwiki.com> wrote:

> On 11/10/09 10:41 AM, Pascal Voitot wrote:
> > On Tue, Nov 10, 2009 at 10:04 AM, Vincent Massol<vincent at 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.florea at 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 at xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> > _______________________________________________
> > devs mailing list
> > devs at xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> devs at xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>



More information about the devs mailing list