[richfaces-issues] [JBoss JIRA] Commented: (RF-1941) Improve performance of RF-enabled pages using http://developer.yahoo.com/performance/rules.html

Sun Sep 21 16:45:25 EDT 2008

    [ https://jira.jboss.org/jira/browse/RF-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12430532#action_12430532 ] 

Grzegorz Dubicki commented on RF-1941:
--------------------------------------

Nick,

Thank you for getting to this matter. It is great you used YSlow to test the RF demo site for Yahoo performance rules compliance.

As I greatly appreciate YSlow it is not by all means the ultimate performance expert and it's "A" grade does not mean that RF has no problems with load performance.

First, this tool is limited this way that Yahoo Performance rules consist of 34 rules at the moment and YSlow tests just 13 of them.

Second it tests them quantifically, not by the quality of their compliance. For example, as Przemyslaw wrote, '"Make Fewer HTTP Requests" rule is complied when you use ALL script and style load strategy because you have only one HTTP and one CSS requests then, but if you look at the quality it is not very good because you load 220kb (gzipped) of JS even if you need only few kb of it. So this rule is complied in not very elegant and optimal way.

I will try to more helpful and specific. This is a summary of the proposals from the comments to this date with a few of my thoughts about them.

*** 1. the original RF-1717 -originating proposal to have component's inline <script>s moved to the end of the <body> - suggested by Przemyslaw ***

I think this would need a new API possibility for components to have *some of their, selected* inline scripts moved to the end of the <body>. It can not be made for all of them automatically because some JSes need to be run at some specific point of HTML code, right?

*** 2. the ability to move some of the components normally <head>-put JS code to the end of the <body> - as Aaron suggested, ***

It would be useful to have possibilty to have some of the scripts for components loaded before the </body> tag.

As Aaron suggested this should be configured per used component as the developer using it knows if its JSes are necessary at page load time or not.

*** 3. new script/style load strategy - "only required as in DEFAULT but in a single file as in ALL" ***

As I think that both available at the moment settings for script/style load strategy (DEFAULT and ALL) make sense for some environments, there is a need for one more - for RF applications using only some components that are put on high-traffic Internet sites.

The idea is that this additional setting load only the required scripts/styles - as DEFAULT - but in a single file = request from client - as ALL.

It could work the following way:  it would internally get only the required scripts/styles, create one file with distinct filename with these files merged, minimize the result file (if it have not been done yet), cache it so all these operations would not need to be done for every request and finally put just only 1 <script>/<style> entry in <head> loading this merged file.

(I know this could work, because this is the exact way that we use for optimizing number of requests and loaded data size for our PHP site - check the result HTML code at http://www.translatica.pl (sorry, it is still in Polish only, but just look at the code))

*** 4. switching standard CSS images for components to utilize CSS Sprites technique, ***

- for what I have seen in the code of RF this would not be easy, but I think you could implement it in a way similar to the suggested for the scripts/styles - as a additional layer before generating the files sent to the HTTP client. This way you would not need to change the components code.

The last thing, if I have not missed somethig, is the proposal that does not really come from http://developer.yahoo.com/performance/rules.html :

*** do some runtime JavaScript performance improvements - as suggested in original RF-1717 and by Olivier and Marie ***

As the JS interpreters are greatly gaining speed as we talk on this matter (Chrome's V8, Firefox's set-for-3.1 TraceMonkey and Webkits new SquirrelFish Extreme) I think that this matter is becoming of slightly lower importance, but there are still many IE's out there so this would also be good to work on. Unfortunately I have too small JS knowledge to propose any specific optimization. (Perhaps some another voter/watcher could do this to inspire the RF devs?)

What do you think Nick? Would at least some of the avobe stuff be possible to implement? Or at least the 3rd one?

> Improve performance of RF-enabled pages using http://developer.yahoo.com/performance/rules.html
> -----------------------------------------------------------------------------------------------
>
>                 Key: RF-1941
>                 URL: https://jira.jboss.org/jira/browse/RF-1941
>             Project: RichFaces
>          Issue Type: Bug
>    Affects Versions: 3.2.0
>            Reporter: Przemyslaw Jaskierski
>            Assignee: Nick Belaevski
>            Priority: Critical
>             Fix For: 3.1.x, 3.3.0
>
>         Attachments: Results for livedemo.jpg, screenshot-1.jpg
>
>
> RF-1717 has been closed without addressing some great optimization opportunities described by Steve Saunders in his book. In short, these rules are here: http://developer.yahoo.com/performance/rules.html. Sticking to these rules _really_ helps.
> As Wim reported here: http://jira.jboss.org/jira/browse/RF-1717#action_12395166, the http://developer.yahoo.com/performance/rules.html#js_bottom helps a lot. It's a little bit confusing seeing this bug closed without addressing this (yes I know that this would require a general approach, that's why I report it here). Having a page rendering time of few seconds on a decent PC is not a good situation...
> I would strongly encourage to take stab at this, because there is a lot of other components that would benefit of this. This would make your product better.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira