Yeah, I guess I'm not convinced that for a portal, the table printed out really represents an "F" grade. I'd worry most about requests after the very first one, since the portal is intended to be an interactive environment. The model of optimizing for repeat requests also seems to fit the choices we've made in the backend as well. Some of the channels/portlets tend to be slow on the very first request, then improve as their contents are cached.
If you're on the admin first tab, some of the javascript may be coming from the calendar channel, not from the portal itself. I'd recommend maybe trying the tool on an empty tab to see what's being included by the framework. Half of the download appears to be images, so all of that will be dependent on your skinning choices, as well. You could always choose to have a skin which doesn't use images for tabs, etc. - 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 > -- 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
