yslow website stats

[Stein Ove Rosseland]

On Fri, Jan 8, 2010 at 8:35 PM, Bret McMillan <bretm at redhat.com> wrote:
> 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
>
> _______________________________________________
> Fedora-infrastructure-list mailing list
> Fedora-infrastructure-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
>

If you compress on the app servers, there will be no increase load on
the reverseproxies. And if you have a good hitratio on the proxies,
the load will probably be insignificant on the appservers as well. Id
also drop etags alltogether if you dont need them.

I can also recomend http://www.webpagetest.org/ as an alternative to
speedtracer and yslow.

Cheers
Stein Ove