yslow website stats

[Bret McMillan]

On 01/08/2010 01:59 PM, Mike McGrath wrote:
> On Fri, 8 Jan 2010, Matt Domsch wrote:
>
>> On Fri, Jan 08, 2010 at 11:07:53AM -0600, Mike McGrath wrote:
>>> On Fri, 8 Jan 2010, Bert Desmet wrote:
>>>
>>>> Hi
>>>>
>>>> mmcgrath asked me to collect some statistics about the fedora website.
>>>> He asked me to use yahoo's yslow.
>>>> You can find the results here: http://bdesmet.be/upload/finished.pdf
>>>> yahoo's page with extra information on every test:
>>>> http://developer.yahoo.com/performance/rules.html
>>>>
>>>
>>> Thanks bert.  I'm wondering how much of these we can do something about
>>> (the low hanging fruit)
>>
>> The "Use a CDN" messages all disappear with a config file setting
>> stating that fp.o _is_ a CDN.
>>
>> Setting up better expiry times on /static/ and /web/static/ should be
>> low-hanging fruit.
>>
>> Adding compression should be low-hanging fruit, but will increase the
>> CPU needed on the app/proxy servers.
>>
>
> I've wondered about this, we should get some metrics.  I've tested
> compression between the browser and the proxy servers and the good news is
> the proxy servers didn't seem to notice.  The question I'd have is if
> compression between app servers and the proxy servers would help.

Unlikely (it might even slow stuff down, depending).  +1 to enabling it 
a the proxy layer, and leaving the rest alone.

>> CSS at top, and javascript at the bottom, I can't say, having not
>> looked at the pages in question.  May be easy.
>>
>
> Is this just bad practice or does it actually cause some issue?

Doing things this way tends to allow browsers to do progressive 
rendering, speeding up the perceived rendering speed of the page. 
Generally speaking, going to get bigger gains from:

   * implementing CDN where applicable
   * minimizing overall # of needed http requests
   * proper caching semantics (including damnable etags)
   * gzip compression

If you knock out all of those, then maybe look at CSS & jscript 
optimization as a next tier of effort.


Google has also produced a pretty neat tool called Speed Tracer:

http://code.google.com/webtoolkit/speedtracer/

Might be worth poking around w/ that too.


--Bret