Re: [xwiki-devs] [xwiki-users] Page Loading Optimization
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 ? 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 ?
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 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... 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 ?
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Do you know tools such as JAWR which can take several CSS or js files and put them in one file using some configurations? I tried it with Grails for example... Maybe it could help or give some ideas at leat... https://jawr.dev.java.net/ regards Pascal On Thu, Nov 5, 2009 at 6:56 PM, Marius Dumitru Florea < [email protected]> 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 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... 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 ?
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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/ 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... 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 ?
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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/
hmmm.... http://code.google.com/p/wro4j/wiki/KnownIssues -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... 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 ?
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.
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... 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
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 < [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.
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...
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
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. 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.
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...
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 ?
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...
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.
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...
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
To be considered too: http://www.sonatype.com/people/2009/11/javascript-compression-in-nexus/ -Vincent On Nov 10, 2009, at 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...
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.
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...
> 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 ?
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). 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.
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...
> 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
On Tue, Nov 10, 2009 at 11:06 AM, Jerome Velociter <[email protected]> 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).
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< [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.
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...
>> 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
On 11/10/09 11:09 AM, Pascal Voitot wrote:
On Tue, Nov 10, 2009 at 11:06 AM, Jerome Velociter<[email protected]> 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).
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....
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) 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...
>>> 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
On Tue, Nov 10, 2009 at 11:16 AM, Jerome Velociter <[email protected]> wrote:
On 11/10/09 11:09 AM, Pascal Voitot wrote:
On Tue, Nov 10, 2009 at 11:06 AM, Jerome Velociter<[email protected]> 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).
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....
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 ;)
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...
>>>> 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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.
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...
>> 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
Since there is no consensus on which optimizer (eg. jawr or wro4j) to use I thought it would be a good idea to decide what is needed and compare features. Some requirements: 1. Creating bundles by calling an api (for "always used" document skin extensions) 2. Adding dynamic resources to bundles (eg: from jsx or skin actions) 3. Calling a bundle from velocity. Anything else? Feature comparison: - Both jawr and wro4j support: 1. Server side cache 2. Browser/proxy caching - jawr uses "cache forever" and creates different file after changes, wro4j uses a more traditional method. 3. Minification (only with wro4j-extensions) (jawr and wro4j both use YUI) 4. Get resources from servlet context (jawr) jawr.js.bundle.baz.mappings=/js/baz/**, /js/someScript.js, /js/someSubdir/ jawr uses ServletContext.getResourceAsStream (wro4j) <css>/static/css/style.css</css> 5. Get resources from classpath (jawr) jawr.js.bundle.foo.mappings=jar:/com/mycompany/myapp/foo.js, /js/bar.js (wro4j) <css>classpath:ro/isdc/resources/file.css</css> 7. gzip where request says it's supported by the browser - Only jawr supports: 1. Creating and registering custom "generators" for getting scripts from skinx objects, external URLs via http get, through "skin action" etc. https://jawr.dev.java.net/docs/generators.html 2. Interpreting css @import and replacing with imported document 3. Logging (via log4j) 4. Recursively loading by directory (not available when loading from classpath) info about order https://jawr.dev.java.net/docs/source_ordering.html 5. supports i18n messages https://jawr.dev.java.net/docs/messages_gen.html 6. jawr is better documented - Only wro4j supports: 1. Get resources from external url <css>http://www.site.com/static/style.css</css> 2. Get resources from local file (not in servlet WEB-INF/) <css>file:c:/temp/file.css</css> * These could be replicated with custom generators. 3. css variables (named colors etc.) 4. wro4j is much simpler Some reading: http://code.google.com/p/wro4j/wiki/GettingStarted http://code.google.com/p/wro4j/wiki/Features https://jawr.dev.java.net/files/documents/8162/135874/jawr-2.8-docs.zip https://jawr.dev.java.net/servlets/ProjectMailingListList https://jawr.dev.java.net/servlets/ForumMessageList?forumID=3025 In the end it seems to be a matter of opinion. In my opinion jawr is best because of the sendmail effect, the bigger the mess the less likely that some feature we need will be missing. Any thoughts? Caleb James DeLisle Jerome Velociter wrote:
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... >>> 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
On Sun, Nov 29, 2009 at 09:14, Caleb James DeLisle <[email protected]> wrote:
Since there is no consensus on which optimizer (eg. jawr or wro4j) to use I thought it would be a good idea to decide what is needed and compare features.
Some requirements: 1. Creating bundles by calling an api (for "always used" document skin extensions) 2. Adding dynamic resources to bundles (eg: from jsx or skin actions) 3. Calling a bundle from velocity. Anything else?
I would add 4. Project life state and community size
Feature comparison: - Both jawr and wro4j support: 1. Server side cache 2. Browser/proxy caching - jawr uses "cache forever" and creates different file after changes, wro4j uses a more traditional method. 3. Minification (only with wro4j-extensions) (jawr and wro4j both use YUI) 4. Get resources from servlet context (jawr) jawr.js.bundle.baz.mappings=/js/baz/**, /js/someScript.js, /js/someSubdir/ jawr uses ServletContext.getResourceAsStream (wro4j) <css>/static/css/style.css</css> 5. Get resources from classpath (jawr) jawr.js.bundle.foo.mappings=jar:/com/mycompany/myapp/foo.js, /js/bar.js (wro4j) <css>classpath:ro/isdc/resources/file.css</css> 7. gzip where request says it's supported by the browser
- Only jawr supports: 1. Creating and registering custom "generators" for getting scripts from skinx objects, external URLs via http get, through "skin action" etc. https://jawr.dev.java.net/docs/generators.html 2. Interpreting css @import and replacing with imported document 3. Logging (via log4j) 4. Recursively loading by directory (not available when loading from classpath) info about order https://jawr.dev.java.net/docs/source_ordering.html 5. supports i18n messages https://jawr.dev.java.net/docs/messages_gen.html 6. jawr is better documented
- Only wro4j supports: 1. Get resources from external url <css>http://www.site.com/static/style.css</css> 2. Get resources from local file (not in servlet WEB-INF/) <css>file:c:/temp/file.css</css> * These could be replicated with custom generators. 3. css variables (named colors etc.) 4. wro4j is much simpler
Some reading: http://code.google.com/p/wro4j/wiki/GettingStarted http://code.google.com/p/wro4j/wiki/Features
https://jawr.dev.java.net/files/documents/8162/135874/jawr-2.8-docs.zip https://jawr.dev.java.net/servlets/ProjectMailingListList https://jawr.dev.java.net/servlets/ForumMessageList?forumID=3025
In the end it seems to be a matter of opinion. In my opinion jawr is best because of the sendmail effect, the bigger the mess the less likely that some feature we need will be missing.
Any thoughts?
Caleb James DeLisle
Jerome Velociter wrote:
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... >>>> 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (6)
-
Caleb James DeLisle -
Jerome Velociter -
Marius Dumitru Florea -
Pascal Voitot -
Thomas Mortagne -
Vincent Massol