This is the report for an empty tab:

*Empty Cache*   *Primed Cache*
16.2K   1       HTML/Text
173.4K  15      JavaScript Files
40.9K   16      Stylesheet Files
18.5K   17      CSS Images
7.7K    8       Images
256.9K  *Total size*
*57*    *HTTP requests*

        
16.2K   1       HTML/Text
0.0K    15      JavaScript Files
0.0K    16      Stylesheet Files
1.1K    17      CSS Images
0.0K    8       Images
17.3K   *Total size*
*57*    *HTTP requests*



Jen Bourey wrote:
> 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] <mailto:[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

-- 
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

Reply via email to