Note: I'm copying jasig-ue on this so we can give the UI experts a chance to weigh in.
OK, here are the re-run stats for an empty tab: Empty Cache Primed Cache21.5K1HTML/Text 173.4K15JavaScript Files 41.5K16Stylesheet Files 19.0K18CSS Images 11.0K8Images 266.5K*Total size* *58**HTTP requests* 21.5K1HTML/Text 0.0K15JavaScript Files 0.0K16Stylesheet Files 2.9K18CSS Images 0.0K8Images 24.5K*Total size* *58**HTTP requests* For comparison, here are the stats for Yahoo's portal with a blank page (my version has a very minimalistic skin chosen): Empty Cache Primed Cache16.6K1HTML/Text 8.7K2IFrames 42.0K2Flash Objects 75.9K8JavaScript Files 13.0K3Stylesheet Files 50.1K12CSS Images 4.7K4Images 211.3K*Total size* *32**HTTP requests* 16.6K1HTML/Text 8.7K2IFrames 0.0K1Flash Object 0.05K1JavaScript File 0.08K2Images 25.5K*Total size* *7**HTTP requests* Some of the things the YSlow tool seems to take issue with don't seem to be quite accurate. For example, it assigns an "F" to the category "minify javascript", even though the majority of the javascript has been minified. Before the release, we discussed minification briefly, and ended up minifying all of the non-portal javascript (jQuery UI, in particular). At the time, it didn't seem like minifying the portal's javascript lent enough of a performance gain to justify the added confusion. I think minifying those files would probably make more sense if we gave the build the ability to do it automatically. If javascript was minified at build time, we wouldn't have to worry as much about people forgetting to re-minify after a change, etc. From our conversations, I believe this is all possible, and we could certainly re-examine these decisions for the next release. One other recommendation the YSlow tool makes is to gzip the javascript and css resources. The jQuery site recommends using minified javascript and avoiding using the gzipped versions in a production environment ( http://docs.jquery.com/Downloading_jQuery#Download_jQuery) due to the client-side performance costs of uncompressing the resources. My understanding is that we're probably best off using minified, but not gzipped, code, since much of it will be cached, and I don't think we want to increase the required per-page clientside processing load beyond what it already is. Another of the "F" category items is "Use a content delivery network." From reading Yahoo's documentation, it appears that they're advocating a network of geographically dispersed severs to improve network performance for a widespread user base. (http://developer.yahoo.com/performance/rules.html) While this makes sense, this issue probably applies less to the average university portal than to websites that are visited by a more diverse and spread out user population. - Jen On Tue, May 13, 2008 at 9:51 AM, Eric Dalquist <[EMAIL PROTECTED]> wrote: > Also as for the performance, I'd be interested to see what YSlow > recommends for fixing the performance problems. Your table looks pretty good > ... we know that with an empty cache it is a large first hit, this is the > reality that comes with people wanting a dynamic user-interface. The primed > cache shows one CSS file being loaded and the portal content being loaded, > I'm not what else could be done to improve performance out-of-the-box there. > I'd imagine setting some agressive cache headers may help cut down on the > number of requests but there is some significant implications in doing that > around people doing development work, future changes to those files and > container/http-server compatibility. I'd be very interested to hear > suggestions for how to improve that rating. > > -Eric > > > Eric Dalquist wrote: > > Nope, I don't think much testing has been done on the skin performance. > > As for validation, are they theme/skin issues or portlet/channel issues? > The hard part about being a portal is there nothing the framework can do if > one of the portlets on the page is rendering invalid markup. > > -Eric > > Tuyhang Ly wrote: > > Hi, > > Regarding the UI performance in uP3, I've seen a high number in HTTP > requests and low number in primed cache reported by Firefox YSlow. For > example, here is the performance report after rendering the first tab of the > admin layout: > > *Performance Grade: F (43)* > *Empty Cache* *Primed Cache* 49.9K 1 HTML/Text 173.4K 15 JavaScript > Files 40.9K 16 Stylesheet Files 213.1K 24 CSS Images 569.5K 13 Images > 1047.0K *Total size* *69* *HTTP requests* 49.9K 1 HTML/Text 0.0K 15 > JavaScript > Files 0.0K 16 Stylesheet Files 1.1K 24 CSS Images 0.0K 13 Images 51.0K > *Total size* *69* *HTTP requests* > Also, http://validator.w3.org/ reports 107 validation errors on this first > tab of the admin page, including incorrectly nested elements, element > "token" undefined, etc... > > Are these known issues to be addressed in the next release of uP3? > > Thanks, > Tuy. > > > -- > > You are currently subscribed to [email protected] as: [EMAIL > PROTECTED] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
