[ http://jira.jboss.com/jira/browse/RF-1941?page=comments#action_12395606 ] Wim Bervoets commented on RF-1941: ---------------------------------- If it's not too difficult to merge then a merge to 3.1.x branch would be very much appreciated too :-) Wim -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/RF-1941?page=comments#action_12402394 ] Olivier Martin commented on RF-1941: ------------------------------------ Having general performance fixes in the 3.1.x series would be extremely appreciated here too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/RF-1941?page=all ] Nick Belaevski updated RF-1941: ------------------------------- Fix Version/s: 3.1.x (was: 3.1.5) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/RF-1941?page=comments#action_12411265 ] Marine Wacheux commented on RF-1941: ------------------------------------ Same comment : I have general performance issues that seem to be due to JavaScript position in HTML rendered page (and maybe other things), using RichFaces 3.1.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/RF-1941?page=all ] Nick Belaevski updated RF-1941: ------------------------------- Fix Version/s: 3.3.0 (was: 3.2.2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/RF-1941?page=comments#action_12420833 ] Aaron Barker commented on RF-1941: ---------------------------------- Additionally, the ability to put a script at the top or bottom of the page should be a parameter that is passed. If the code is required for something that is immediately needed it should be loaded at the top of the page (hide/show a layer). If it is for something that the user may or may not use (modal dialog, date picker, etc) then it can be moved to the bottom. An example would be that a modal may be required immediately (used to stop any interaction on the page when loading) or on user interaction (when clicking on a help link). Both scenarios should be supported. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/RF-1941?page=com.atlassian.jira.plugin... ] Grzegorz Dubicki commented on RF-1941: -------------------------------------- I would like to add one more suggestion: * switching standard CSS images for components to utilize CSS Sprites technique, -- In the mean time I have googled looking for some RF performance tips. I have found out that some of RF devs do not want to work on these kind of changes. Christian Bauer, for example, stated that "All in all, with todays client bandwidth, this is mostly irrelevant optimization." and that "The CSS sprite stuff is bullshit. Images are cached on the browser with no problem.". Apparently Nick assigned to this issue thinks the same, because there is no trace on his activity on this issue here. :( Excuse me, but first load 220.5K JS ((weight of compressed RF JSs) + CSS + HTML + gfx > 300 kb website with > 30 HTTP requests is noticably slowish even if you have a good broadband connection. And really fast broadbands are not common around the whole online world yet. And I think I am not alone thinking that the first load time of a website is an important part of the overall impression and must be worked on and optimized. - And what do all readers and voters think about it? Please comment on this issue and vote if you want it resolved! Let the devs know we are really interested in a better RF perfomance! -- 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

[ https://jira.jboss.org/jira/browse/RF-1941?page=com.atlassian.jira.plugin... ] Nick Belaevski commented on RF-1941: ------------------------------------ A little experiment. Preparation: 1. YSlow installed to FF3 2. Tomcat configured to GZip CSS/JS files 3. common.css and all static images removed from demo site (that is because YSlow complains it cannot find expires header for them and we cannot do anything with that - there's ETag on all of them and caching occurs) 4. Default expire set to 2d+ 5. Local address added to CDN list 6. Tree demo page opened See results on screenshot attached: points 5 and 6 are "A" - high mark -- 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

[ https://jira.jboss.org/jira/browse/RF-1941?page=com.atlassian.jira.plugin... ] Nick Belaevski updated RF-1941: ------------------------------- Attachment: Results for livedemo.jpg -- 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

[ https://jira.jboss.org/jira/browse/RF-1941?page=com.atlassian.jira.plugin... ] 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? -- 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

[ https://jira.jboss.org/jira/browse/RF-1941?page=com.atlassian.jira.plugin... ] Nick Belaevski updated RF-1941: ------------------------------- Fix Version/s: Future (was: 3.1.x) (was: 3.3.0) -- 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

[ https://jira.jboss.org/jira/browse/RF-1941?page=com.atlassian.jira.plugin... ] Michael Youngstrom commented on RF-1941: ---------------------------------------- How can you push back one of the most voted on features? Has some of the items in this issue been addressed already? What is being deferred? It would be nice if we could get a little more explanation. -- 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

[ https://jira.jboss.org/jira/browse/RF-1941?page=com.atlassian.jira.plugin... ] Nick Belaevski updated RF-1941: ------------------------------- Original Estimate: (was: 2 days) Remaining Estimate: (was: 2 days) Component/s: (was: planning_all) -- 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

[ https://jira.jboss.org/jira/browse/RF-1941?page=com.atlassian.jira.plugin... ] Nick Belaevski commented on RF-1941: ------------------------------------ 3.3.1-snapshot now contains maven-resource-dependency-plugin that allows to assemble required resources into a single file as proposed by Grzegorz Dubicki by #3. Usage is documented here: https://www.jboss.org/community/docs/DOC-13329 -- 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

[ https://jira.jboss.org/jira/browse/RF-1941?page=com.atlassian.jira.plugin... ] Nick Belaevski resolved RF-1941. -------------------------------- Fix Version/s: 3.3.1 3.3.0 (was: Future) Resolution: Partially Completed Assignee: Alexander Dubovsky (was: Nick Belaevski) Maven plugin for resources aggregation was developed for 3.3.1.GA release and can be used either with RF 3.3.0.GA or 3.3.1.GA Another suggestions will be reviewed for 4.0 version -- 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