Afficher un message
Vieux 04/04/2008, 11h17   #3
rf
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: How to check why page slow?

Blinky the Shark <no.spam@box.invalid> wrote in
news:pan.2008.04.04.10.36.09.280916@thurston.blink ynet.net:

> rf wrote:
>
>> Geoff Cox <gcox@freeuk.notcom> wrote in
>> news:r1sbv3taf2mcem76n9co28ps1j9c3t3lbo@4ax.com:
>>
>>> Hello,
>>>
>>> I have a page for which downloading into the browser is very slow.
>>>
>>> I have tried using YSlow and firebug but is there any way in which I
>>> can actually see which files are taking a long time to be
>>> downloaded?
>>>
>>> Cheers
>>>
>>> Geoff
>>>
>>>

>> Does not the firebug Net tab tell you this? It does for me.

>
> Nifty. Never dug far enough into FB to see that. For each file I get
> a graph bar whose length is proportional to the file's d/l time. But
> that bar is broken into two parts -- a grey left side and a teal right
> side. What does this split indicate?
>


Er. It's actually broken into three, a white bit, a grey bit and a cyan
(teal?) bit.

From what I can determine the white bit is that particular file waiting
for an available connection to the host (as in a TCP/IP socket, assuming
the client only has a few to hand). The grey bit is from posting the
request to receiving the entire object. The teal bit is where they post
the milliseconds.

It looks a lot better if you hit a site in another country (as we in the
Antipodes often do). For example, loading the google logo from wherever
they are in .au takes 31ms. Loading the same image from the U S of A
takes 375ms. The grey bit is a whole lot larger.

The OP seems to think that the hole in the wall that his cat5 cable is
plugged into is in direct and close connection to every host out there.
Not so. Over her we *expect* a turnaround time of 300ms for *every*
request we make to most of the rest of the world.

--
Richard
Killing all google posts and replies to google posts
The Usenet Improvement Project: http://improve-usenet.org
  Réponse avec citation
 
Page generated in 0,05971 seconds with 9 queries