[proposal] JS and CSS improvements

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[proposal] JS and CSS improvements

Ludovic Dubost

Currently the albatross skin loads around 10 js and 10 css, which is
quite a lot.
We can improve loading time by:

- compression and cache (raffaello will provide Apache configs specific
to XWiki to help for that)
- merging and optimizations of css/js (I've published
http://www.xwiki.org/xwiki/bin/view/Code/MergeCSS to help on that)
- removing unused css/js (now we need to find which one are unused)
- conditional loading of css and js.

This last improvement can help us a lot since some of the css/js are not
even used in view mode, or are only used by a specific panel.
For this my proposal is to add a feature to the core to allow
conditional loading of CSS and JS files.
The current macros in the header would instead of putting CSS and JS add
a placeholder for additional CSS and JS.
Then everywhere where we need these CSS/JS (in a panel, in a wiki page,
in a template) we would call a macro #includecss or #includejs
This macro would add in the context the CSS and JS to add.
At the end of the template rendering the placeholder would be replaced
by the added CSS and JS.
The page would be served.

This would allow to manage the way CSS and JS are added.

WDYT ?

Ludovic


--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs

ludovic.vcf (301 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] JS and CSS improvements

Sergiu Dumitriu-2
Hi Ludovic,

Just found this email in my inbox, and was surprised by the similarity
with the Skin Extensions proposal.

Ludovic Dubost wrote:

>
> Currently the albatross skin loads around 10 js and 10 css, which is
> quite a lot.
> We can improve loading time by:
>
> - compression and cache (raffaello will provide Apache configs specific
> to XWiki to help for that)
> - merging and optimizations of css/js (I've published
> http://www.xwiki.org/xwiki/bin/view/Code/MergeCSS to help on that)
> - removing unused css/js (now we need to find which one are unused)
> - conditional loading of css and js.
>
> This last improvement can help us a lot since some of the css/js are not
> even used in view mode, or are only used by a specific panel.
> For this my proposal is to add a feature to the core to allow
> conditional loading of CSS and JS files.
> The current macros in the header would instead of putting CSS and JS add
> a placeholder for additional CSS and JS.
> Then everywhere where we need these CSS/JS (in a panel, in a wiki page,
> in a template) we would call a macro #includecss or #includejs
> This macro would add in the context the CSS and JS to add.
> At the end of the template rendering the placeholder would be replaced
> by the added CSS and JS.
> The page would be served.
>
> This would allow to manage the way CSS and JS are added.
>
> WDYT ?
>
> Ludovic
>

--
Sergiu Dumitriu
http://purl.org/net/sergiu/

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] JS and CSS improvements

Ludovic Dubost-2

Yes.. we need this to be able to also create valid XHTML since CSS is
not allowed in content anyway.
MergeCSS does not work well though. We had to roll it back when we have
been using it.

Ludovic

Sergiu Dumitriu wrote:

> Hi Ludovic,
>
> Just found this email in my inbox, and was surprised by the similarity
> with the Skin Extensions proposal.
>
> Ludovic Dubost wrote:
>  
>> Currently the albatross skin loads around 10 js and 10 css, which is
>> quite a lot.
>> We can improve loading time by:
>>
>> - compression and cache (raffaello will provide Apache configs specific
>> to XWiki to help for that)
>> - merging and optimizations of css/js (I've published
>> http://www.xwiki.org/xwiki/bin/view/Code/MergeCSS to help on that)
>> - removing unused css/js (now we need to find which one are unused)
>> - conditional loading of css and js.
>>
>> This last improvement can help us a lot since some of the css/js are not
>> even used in view mode, or are only used by a specific panel.
>> For this my proposal is to add a feature to the core to allow
>> conditional loading of CSS and JS files.
>> The current macros in the header would instead of putting CSS and JS add
>> a placeholder for additional CSS and JS.
>> Then everywhere where we need these CSS/JS (in a panel, in a wiki page,
>> in a template) we would call a macro #includecss or #includejs
>> This macro would add in the context the CSS and JS to add.
>> At the end of the template rendering the placeholder would be replaced
>> by the added CSS and JS.
>> The page would be served.
>>
>> This would allow to manage the way CSS and JS are added.
>>
>> WDYT ?
>>
>> Ludovic
>>
>>    
>
>  


--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] JS and CSS improvements

Sachin Mittal
Well I think this has to be done in steps
1. Remove all the unused js code from the albatross skin like under scriptaculous and also the multiple prototype.js
2. In the javascript.vm and stylesheets.vm conditionally load css and js files based on the action.
3. For better maintainability keep all js under one folder and all css under other and images in other.
4. I am be wrong but doing step 3 would enable someone to put all the static content under a web server say apache and use app server say tomcat to serve only the dynamic content by bridging the two, which in turn would prove to be a good solution for a scalable enterprise deployment.
5. Merge all the css under one or lot fewer files.
6. Also check that style.css under toucan skin is 57 kb large, so the css size should be reduced in the merged css file(s)

Thanks
Sachin


Ludovic Dubost-2 wrote
Yes.. we need this to be able to also create valid XHTML since CSS is
not allowed in content anyway.
MergeCSS does not work well though. We had to roll it back when we have
been using it.

Ludovic

> Ludovic Dubost wrote:
>  
>> Currently the albatross skin loads around 10 js and 10 css, which is
>> quite a lot.
>> We can improve loading time by:
>>
>> - compression and cache (raffaello will provide Apache configs specific
>> to XWiki to help for that)
>> - merging and optimizations of css/js (I've published
>> http://www.xwiki.org/xwiki/bin/view/Code/MergeCSS to help on that)
>> - removing unused css/js (now we need to find which one are unused)
>> - conditional loading of css and js.
>>
>> This last improvement can help us a lot since some of the css/js are not
>> even used in view mode, or are only used by a specific panel.
>> For this my proposal is to add a feature to the core to allow
>> conditional loading of CSS and JS files.
>> The current macros in the header would instead of putting CSS and JS add
>> a placeholder for additional CSS and JS.
>> Then everywhere where we need these CSS/JS (in a panel, in a wiki page,
>> in a template) we would call a macro #includecss or #includejs
>> This macro would add in the context the CSS and JS to add.
>> At the end of the template rendering the placeholder would be replaced
>> by the added CSS and JS.
>> The page would be served.
>>
>> This would allow to manage the way CSS and JS are added.
>>
>> WDYT ?
>>
>> Ludovic
>>
>>    
>
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] JS and CSS improvements

ebullient
+1

Serving js and css from a static location would be WAY better
performance wise... orders of magnitude better...

On Wed, Mar 12, 2008 at 3:14 PM, Sachin Mittal <[hidden email]> wrote:

>
>  Well I think this has to be done in steps
>  1. Remove all the unused js code from the albatross skin like under
>  scriptaculous and also the multiple prototype.js
>  2. In the javascript.vm and stylesheets.vm conditionally load css and js
>  files based on the action.
>  3. For better maintainability keep all js under one folder and all css under
>  other and images in other.
>  4. I am be wrong but doing step 3 would enable someone to put all the static
>  content under a web server say apache and use app server say tomcat to serve
>  only the dynamic content by bridging the two, which in turn would prove to
>  be a good solution for a scalable enterprise deployment.
>  5. Merge all the css under one or lot fewer files.
>  6. Also check that style.css under toucan skin is 57 kb large, so the css
>  size should be reduced in the merged css file(s)
>
>  Thanks
>  Sachin
>
>
>
>
>  Ludovic Dubost-2 wrote:
>  >
>  >
>  > Yes.. we need this to be able to also create valid XHTML since CSS is
>  > not allowed in content anyway.
>  > MergeCSS does not work well though. We had to roll it back when we have
>  > been using it.
>  >
>  > Ludovic
>  >
>
>
> >> Ludovic Dubost wrote:
>  >>
>  >>> Currently the albatross skin loads around 10 js and 10 css, which is
>  >>> quite a lot.
>  >>> We can improve loading time by:
>  >>>
>  >>> - compression and cache (raffaello will provide Apache configs specific
>  >>> to XWiki to help for that)
>  >>> - merging and optimizations of css/js (I've published
>  >>> http://www.xwiki.org/xwiki/bin/view/Code/MergeCSS to help on that)
>  >>> - removing unused css/js (now we need to find which one are unused)
>  >>> - conditional loading of css and js.
>  >>>
>  >>> This last improvement can help us a lot since some of the css/js are not
>  >>> even used in view mode, or are only used by a specific panel.
>  >>> For this my proposal is to add a feature to the core to allow
>  >>> conditional loading of CSS and JS files.
>  >>> The current macros in the header would instead of putting CSS and JS add
>  >>> a placeholder for additional CSS and JS.
>  >>> Then everywhere where we need these CSS/JS (in a panel, in a wiki page,
>  >>> in a template) we would call a macro #includecss or #includejs
>  >>> This macro would add in the context the CSS and JS to add.
>  >>> At the end of the template rendering the placeholder would be replaced
>  >>> by the added CSS and JS.
>  >>> The page would be served.
>  >>>
>  >>> This would allow to manage the way CSS and JS are added.
>  >>>
>  >>> WDYT ?
>  >>>
>  >>> Ludovic
>  >>>
>  >>>
>  >>
>  >
>
>
>  -----
>  http://www.assembla.com/wiki/show/sachin_mittal about me:
>  --
>  View this message in context: http://www.nabble.com/-proposal--JS-and-CSS-improvements-tp12806140p16012509.html
>  Sent from the XWiki- Dev mailing list archive at Nabble.com.
>
>
>
>  _______________________________________________
>  devs mailing list
>  [hidden email]
>  http://lists.xwiki.org/mailman/listinfo/devs
>



--
'Waste of a good apple' -Samwise Gamgee
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] JS and CSS improvements

Sergiu Dumitriu-2
In reply to this post by Sachin Mittal
You should read http://dev.xwiki.org/xwiki/bin/view/Design/SkinExtensions

It is still a draft, this is why it wasn't published on the mailing list
yet.

Sachin Mittal wrote:

> Well I think this has to be done in steps
> 1. Remove all the unused js code from the albatross skin like under
> scriptaculous and also the multiple prototype.js
> 2. In the javascript.vm and stylesheets.vm conditionally load css and js
> files based on the action.
> 3. For better maintainability keep all js under one folder and all css under
> other and images in other.
> 4. I am be wrong but doing step 3 would enable someone to put all the static
> content under a web server say apache and use app server say tomcat to serve
> only the dynamic content by bridging the two, which in turn would prove to
> be a good solution for a scalable enterprise deployment.
> 5. Merge all the css under one or lot fewer files.
> 6. Also check that style.css under toucan skin is 57 kb large, so the css
> size should be reduced in the merged css file(s)
>
> Thanks
> Sachin
>
>
>
> Ludovic Dubost-2 wrote:
>>
>> Yes.. we need this to be able to also create valid XHTML since CSS is
>> not allowed in content anyway.
>> MergeCSS does not work well though. We had to roll it back when we have
>> been using it.
>>
>> Ludovic
>>
>>> Ludovic Dubost wrote:
>>>  
>>>> Currently the albatross skin loads around 10 js and 10 css, which is
>>>> quite a lot.
>>>> We can improve loading time by:
>>>>
>>>> - compression and cache (raffaello will provide Apache configs specific
>>>> to XWiki to help for that)
>>>> - merging and optimizations of css/js (I've published
>>>> http://www.xwiki.org/xwiki/bin/view/Code/MergeCSS to help on that)
>>>> - removing unused css/js (now we need to find which one are unused)
>>>> - conditional loading of css and js.
>>>>
>>>> This last improvement can help us a lot since some of the css/js are not
>>>> even used in view mode, or are only used by a specific panel.
>>>> For this my proposal is to add a feature to the core to allow
>>>> conditional loading of CSS and JS files.
>>>> The current macros in the header would instead of putting CSS and JS add
>>>> a placeholder for additional CSS and JS.
>>>> Then everywhere where we need these CSS/JS (in a panel, in a wiki page,
>>>> in a template) we would call a macro #includecss or #includejs
>>>> This macro would add in the context the CSS and JS to add.
>>>> At the end of the template rendering the placeholder would be replaced
>>>> by the added CSS and JS.
>>>> The page would be served.
>>>>
>>>> This would allow to manage the way CSS and JS are added.
>>>>
>>>> WDYT ?
>>>>
>>>> Ludovic
>>>>
>>>>    


--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] JS and CSS improvements

Sachin Mittal
Hi,
I read that posting.
I have a doubt though, how would having a separate extension class would solve the purpose of faster loading of static content.
Over the time I can add lot of css and js files to be loaded by these extension classes thus brining back to square 1.
Alternately in current javascript.vm and stylesheets.vm I can have a conditional load by calling few needed files only based on xwiki action, thus making the page load faster.

The problem is that the css and js code is very fragmented which makes it difficult to collect place the static content in say web server.
Next many time css and js code needs to be parsed by velocity context to evaluate certain variables which in most case refer to the image url. We cannot put these dynamic files into web container and I believe loading such files (static but dynamic) also increases the page load time.
Thus collecting all the js, css and images files and placing them into three separate pre determined directories would avoid use of velocity code inside the static content.
This then can be moved to web server thus achieving the desired result.

Also when the files are same type are grouped together, it is lot easy to manage and make further improvements on it.

Thanks
Sachin


Sergiu Dumitriu-2 wrote
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] JS and CSS improvements

Sergiu Dumitriu-2
Sachin Mittal wrote:

> Hi,
> I read that posting.
> I have a doubt though, how would having a separate extension class would
> solve the purpose of faster loading of static content.
> Over the time I can add lot of css and js files to be loaded by these
> extension classes thus brining back to square 1.
> Alternately in current javascript.vm and stylesheets.vm I can have a
> conditional load by calling few needed files only based on xwiki action,
> thus making the page load faster.
>
> The problem is that the css and js code is very fragmented which makes it
> difficult to collect place the static content in say web server.
> Next many time css and js code needs to be parsed by velocity context to
> evaluate certain variables which in most case refer to the image url. We
> cannot put these dynamic files into web container and I believe loading such
> files (static but dynamic) also increases the page load time.
> Thus collecting all the js, css and images files and placing them into three
> separate pre determined directories would avoid use of velocity code inside
> the static content.
> This then can be moved to web server thus achieving the desired result.
>
> Also when the files are same type are grouped together, it is lot easy to
> manage and make further improvements on it.

This is true for a static XWiki installation, when you know what
features you have in the site. This is the old way of doing things, and
it worked almost fine with the previous XWiki-one-big-product-0.9. Now,
we're turning XWiki into a platform with lots of modules on it. Still,
we are far from there, since now we managed to separate the products
from the platform pretty well, but we're just starting to separate
applications from the products/platform. And this step is hard and slow
because the platform is not extensible enough. Sure, it is easy to write
applications that just require some wiki documents, but it becomes
almost impossible when they require some javascript, some CSS and
modifying some parts of the interface.

The future XWiki will be more like Gecko/Firefox, a strong platform with
very few features, but many extension points, on which you can put lots
of apps and extensions and get a powerful product like XWiki Workspaces.
And with a few click on the Administration interface, you can turn it
into Watch. Or into XWits. Or into Spawn. Or into all of them together.
Without restarting the server, downloading and importing xars, changing
configuration files, installing plugins and other hard work. It will be
easier than installing a Firefox addon. Firefox is so popular and
because they decided to go the XUL+overlay way, without limiting what
you can do with the browser. There are hundreds (thousands?) of
extensions for Firefox, especially because it is simple and
unrestrictive to write "the extensions of your dreams". Can we say that
about XWiki right now? No. But I'd like to be able to say that. And for
that we need to balance the performace/features ratio. If you want the
most performant site, just write plain HTML and put it in a HTTPD +
Squid cluster. Want to be as extensible as Facebook or iGoogle? Well,
you have to give up some of the performance.

And the simple decisions that you would like to put in javascript.vm are
maybe simple for the moment, when we have less than 20 js files for
which we know where and when are used, but they are increasing.


However, once you decided how your site looks like, we could have a
"Statify" tool that exports all the cacheable js/css content into some
static resources.

> Thanks
> Sachin
>
>
>
> Sergiu Dumitriu-2 wrote:
>> You should read http://dev.xwiki.org/xwiki/bin/view/Design/SkinExtensions
>>
>>

--
Sergiu Dumitriu
http://purl.org/net/sergiu/

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs