10 Nov
2009
10 Nov
'09
11:27 a.m.
On Tue, Nov 10, 2009 at 11:16 AM, Jerome Velociter <jerome(a)xwiki.com> wrote:
On 11/10/09 11:09 AM, Pascal Voitot wrote:
That we do already :)
Using prototype dom:loaded event (we also have our own event to indicate
the DOM is loaded and has been pre-processed by XWiki scripts, see
http://platform.xwiki.org/xwiki/bin/view/DevGuide/JavaScriptAPI#HDOMEvents
for more)
oh yes guys, nice idea :)
I have been disconnected from you for some time now and I may have missed
some features ;)
On Tue, Nov 10, 2009 at 11:06 AM, Jerome
Velociter<jerome(a)xwiki.com>
wrote:
On 11/10/09 10:41 AM, Pascal Voitot wrote:
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.... On Tue, Nov 10, 2009 at 10:04 AM, Vincent
Massol<vincent(a)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).
Jerome.
_______________________________________________
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
> 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(a)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-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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs