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

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.

--
Richard
Killing all google posts and replies to google posts
The Usenet Improvement Project: http://improve-usenet.org

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

rf <rf@invalid.com> wrote in news:QenJj.5837$n8.4510@news-
server.bigpond.net.au:


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

Er, this paragraph more correctly applies to whoever is talking about
latency in another thread/group.

--
Richard
Killing all google posts and replies to google posts
The Usenet Improvement Project: http://improve-usenet.org

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?

--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project: http://improve-usenet.org
Blinky: http://blinkynet.net

On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf@invalid.com> wrote:

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

I do see the above for 9 requests but thn there is sometimes a delay
of 2 minutes before I can use the page .. it's that bit that I want to
check on and Firebug shows nothing even after the 2 minutes ...?

There must be some software which would show up what is happening?

Cheers

Geoff

In comp.infosystems.www.authoring.html Geoff Cox wrote:
> [Firebug]
> I do see the above for 9 requests but thn there is sometimes a delay
> of 2 minutes before I can use the page .. it's that bit that I want
> to check on and Firebug shows nothing even after the 2 minutes ...?
>
> There must be some software which would show up what is happening?

Will this , prehaps?

http://www.websiteoptimization.com/services/analyze/

--
-bts
-Friends don't let friends drive Vista

rf wrote:

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

Ah! I gotcha. The cyan is just the background and the white/grey are
graph bars. That makes sense now. Thanks. You've probably seen the
black and white image (no greys) that's either a side giew of a goblet
*or* two faces in profile, almost nose to nose. I was viewing each line
"the other way" -- with the cyan portion being the object (the graph bar)
instead of the background. Like the goblet/faces image, once you see
both, you can easily flip your perception back and forth between the two.


--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project: http://improve-usenet.org
Blinky: http://blinkynet.net

Geoff Cox wrote:

> On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf@invalid.com> wrote:
>
>>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.
>
> I do see the above for 9 requests but thn there is sometimes a delay of 2
> minutes before I can use the page .. it's that bit that I want to check on
> and Firebug shows nothing even after the 2 minutes ...?
>
> There must be some software which would show up what is happening?

You don't happen to be using PHP, there, do you?


--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project: http://improve-usenet.org
Blinky: http://blinkynet.net

["Followup-To:" header set to comp.infosystems.www.authoring.html.]
On Fri, 04 Apr 2008 09:26:28 GMT, 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.

I think the YSlow Components tab shows a lot more information. Wish I
could get the expires and compression to work with my hosting provider
(Components shows no gzip and expires information for anything from my
domain).


--
Linux Home Automation Neil Cherry ncherry@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
Author of: Linux Smart Homes For Dummies

["Followup-To:" header set to comp.infosystems.www.authoring.html.]
On Fri, 04 Apr 2008 13:04:00 +0100, Geoff Cox wrote:
> On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf@invalid.com> wrote:
>
>>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.
>
> I do see the above for 9 requests but thn there is sometimes a delay
> of 2 minutes before I can use the page .. it's that bit that I want to
> check on and Firebug shows nothing even after the 2 minutes ...?
>
> There must be some software which would show up what is happening?

I think either using YSlow -> Components might give you a hint or you
could use something like wireshark (and network sniffer) to see how
long things actually take (you'll need to break out everything by
hand.


--
Linux Home Automation Neil Cherry ncherry@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
Author of: Linux Smart Homes For Dummies

On Fri, 04 Apr 2008 13:36:27 GMT, "Beauregard T. Shagnasty"
<a.nony.mous@example.invalid> wrote:

>In comp.infosystems.www.authoring.html Geoff Cox wrote:
>> [Firebug]
>> I do see the above for 9 requests but thn there is sometimes a delay
>> of 2 minutes before I can use the page .. it's that bit that I want
>> to check on and Firebug shows nothing even after the 2 minutes ...?
>>
>> There must be some software which would show up what is happening?
>
>Will this , prehaps?
>
>http://www.websiteoptimization.com/services/analyze/


Thanks - that's very useful.

Cheers

Geoff

On Fri, 04 Apr 2008 08:19:50 -0800, Blinky the Shark
<no.spam@box.invalid> wrote:

>Geoff Cox wrote:
>
>> On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf@invalid.com> wrote:
>>
>>>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.
>>
>> I do see the above for 9 requests but thn there is sometimes a delay of 2
>> minutes before I can use the page .. it's that bit that I want to check on
>> and Firebug shows nothing even after the 2 minutes ...?
>>
>> There must be some software which would show up what is happening?
>
>You don't happen to be using PHP, there, do you?

Yes - in order to access MySQL ...

Why do you ask?

Cheers

Geoff

On Fri, 04 Apr 2008 14:23:55 -0500, Neil Cherry <njc@.uucp>
wrote:

>["Followup-To:" header set to comp.infosystems.www.authoring.html.]
>On Fri, 04 Apr 2008 13:04:00 +0100, Geoff Cox wrote:
>> On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf@invalid.com> wrote:
>>
>>>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.
>>
>> I do see the above for 9 requests but thn there is sometimes a delay
>> of 2 minutes before I can use the page .. it's that bit that I want to
>> check on and Firebug shows nothing even after the 2 minutes ...?
>>
>> There must be some software which would show up what is happening?
>
>I think either using YSlow -> Components might give you a hint or you
>could use something like wireshark (and network sniffer) to see how
>long things actually take (you'll need to break out everything by
>hand.

Thanks Neil - will follow up on these ..

Cheers

Geoff

On 4/4/2008 4:04 AM, Geoff Cox wrote:
> On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf@invalid.com> wrote:
>
>> 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.
>
> I do see the above for 9 requests but thn there is sometimes a delay
> of 2 minutes before I can use the page .. it's that bit that I want to
> check on and Firebug shows nothing even after the 2 minutes ...?
>
> There must be some software which would show up what is happening?
>
> Cheers
>
> Geoff


--
David Ross
<http://www.rossde.com/>

Have you been using Netscape and now feel abandoned by AOL?
Then use SeaMonkey. Go to <http://www.seamonkey-project.org/>.

On 4/4/2008 4:04 AM, Geoff Cox wrote:
> On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf@invalid.com> wrote:
>
>> 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.
>
> I do see the above for 9 requests but thn there is sometimes a delay
> of 2 minutes before I can use the page .. it's that bit that I want to
> check on and Firebug shows nothing even after the 2 minutes ...?
>
> There must be some software which would show up what is happening?
>
> Cheers
>
> Geoff

[Please excuse the blank reply. I accidentally hit the Send button
before replying.]

The cross-posting indicates you may have some JavaScript in the pages.
Is it possible that the page with the two-minute delay has JavaScript
that accesses the Web server for data or for another JavaScript?

I see an excessive delay -- with my browser freezing even for tabs with
pages from unrelated servers -- on some pages from Vanguard Mutual
Funds. I can avoid the freeze and delay by disabling JavaScript.
However, some Vanguard pages then don't work.

--
David Ross
<http://www.rossde.com/>

Have you been using Netscape and now feel abandoned by AOL?
Then use SeaMonkey. Go to <http://www.seamonkey-project.org/>.

Geoff Cox wrote:

> On Fri, 04 Apr 2008 08:19:50 -0800, Blinky the Shark <no.spam@box.invalid>
> wrote:
>
>>Geoff Cox wrote:
>>
>>> On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf@invalid.com> wrote:
>>>
>>>>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.
>>>
>>> I do see the above for 9 requests but thn there is sometimes a delay of
>>> 2 minutes before I can use the page .. it's that bit that I want to
>>> check on and Firebug shows nothing even after the 2 minutes ...?
>>>
>>> There must be some software which would show up what is happening?
>>
>>You don't happen to be using PHP, there, do you?
>
> Yes - in order to access MySQL ...
>
> Why do you ask?

Because of your issue and something that happened to me about a year ago.

It's not a short story. Grab a beer.

Every page at the two sites in my sig require PHP. The top few elements
(which I'll loosely call the headers) and all of the footer stuff you
will see repeated on every page are PHP inclusions.

One day, with my last host, it started taking about four minutes do
download a blinkynet page. Any page. And if you go there, you'll see
that because I'm on dialup I'm very careful to not make large pages.
Those should probably average 10 or 12 seconds on a dialup. So four
minutes was just crazy. *I had changed _nothing_ from my end.* And I
noticed that this was happening: it would take a minute and a half or two
minutes for those PHP-delivered elements to render; then the body of the
page would load in a snap, just like the whole page did before this
started happening; then it would take another minute or two for those
*bottom* PHP-delivered elements to show up.

I stress: nothing at all changed from my end. Somehow, PHP was just plain
falling on its ass. Remember, the non-PHP bodies of the pages all
downloaded in an instant or two while the PHP-dependent stuff (still not
many bytes, mind you) just went chugga-chugga for minutes at a time.

Of course I couldn't get it through the thick head of that host that I had
changed nothing. So I had to leave. I moved the same code to a new host
and it worked fine from the git-go, and has ever since.

Well, once - long after I moved - I checked blinkynet and found no PHP
happening. I did live chat with them when I saw that; within a minute -
literally - they said "Try it now", and it was working that fast. They'd
accidentally disabled PHP in some fashion. NO problem: they admitted it
and, like I said, they kicked the right corner of their hardware to have
it functional in the wink of an eye.

So that's why I thought if PHP when you described your issues. I'm not
using any databases at any of my sites, so I'll grant that there are more
things to go wrong with your installation than mine. But your problem
sounded very, very familiar.

My experience was also a good lesson in how much difference a responsive
host can make.


--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project: http://improve-usenet.org
Blinky: http://blinkynet.net

David E. Ross wrote:

> Have you been using Netscape and now feel abandoned by AOL?

Being abandoned by AOL is a *bad* thing?

> Then use SeaMonkey. Go to <http://www.seamonkey-project.org/>.


--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project: http://improve-usenet.org
Blinky: http://blinkynet.net

On Fri, 04 Apr 2008 20:42:53 -0800, Blinky the Shark
<no.spam@box.invalid> wrote:


>>>You don't happen to be using PHP, there, do you?
>>
>> Yes - in order to access MySQL ...
>>
>> Why do you ask?
>
>Because of your issue and something that happened to me about a year ago.
>
>It's not a short story. Grab a beer.
>
>Every page at the two sites in my sig require PHP. The top few elements
>(which I'll loosely call the headers) and all of the footer stuff you
>will see repeated on every page are PHP inclusions.
>
>One day, with my last host, it started taking about four minutes do
>download a blinkynet page. Any page. And if you go there, you'll see
>that because I'm on dialup I'm very careful to not make large pages.
>Those should probably average 10 or 12 seconds on a dialup. So four
>minutes was just crazy. *I had changed _nothing_ from my end.* And I
>noticed that this was happening: it would take a minute and a half or two
>minutes for those PHP-delivered elements to render; then the body of the
>page would load in a snap, just like the whole page did before this
>started happening; then it would take another minute or two for those
>*bottom* PHP-delivered elements to show up.
>
>I stress: nothing at all changed from my end. Somehow, PHP was just plain
>falling on its ass. Remember, the non-PHP bodies of the pages all
>downloaded in an instant or two while the PHP-dependent stuff (still not
>many bytes, mind you) just went chugga-chugga for minutes at a time.
>
>Of course I couldn't get it through the thick head of that host that I had
>changed nothing. So I had to leave. I moved the same code to a new host
>and it worked fine from the git-go, and has ever since.
>
>Well, once - long after I moved - I checked blinkynet and found no PHP
>happening. I did live chat with them when I saw that; within a minute -
>literally - they said "Try it now", and it was working that fast. They'd
>accidentally disabled PHP in some fashion. NO problem: they admitted it
>and, like I said, they kicked the right corner of their hardware to have
>it functional in the wink of an eye.
>
>So that's why I thought if PHP when you described your issues. I'm not
>using any databases at any of my sites, so I'll grant that there are more
>things to go wrong with your installation than mine. But your problem
>sounded very, very familiar.
>
>My experience was also a good lesson in how much difference a responsive
>host can make.

I know the feeling re hosting people - I spent hours yesterday with
Webfusion trying and so far failing to password protect a folder. My
older account is on a server which appears to problems - the new
account offers no SSH access, just a control panel which will not
create password protected folders!

You have to create your own .htaccess and .htpasswd files and worse
still encrypt your passwords using web based software on the Net -
this was the hosting people's own advice!

The php is used to add data to MySQL and of course that doesn't happen
until the pages have downloaded ... so I keep looking I guess.

Cheers

Geoff

On Fri, 04 Apr 2008 17:47:39 -0800, "David E. Ross"
<nobody@nowhere.not> wrote:

>[Please excuse the blank reply. I accidentally hit the Send button
>before replying.]

David,

No problem and I'm now aware of Seamonkey!

>The cross-posting indicates you may have some JavaScript in the pages.
>Is it possible that the page with the two-minute delay has JavaScript
>that accesses the Web server for data or for another JavaScript?

The JavaScript is for making things appear/disappear and getting
values for Ajax.Updater so I don't think this falls into your
categories ..

Cheers

Geoff

>
>I see an excessive delay -- with my browser freezing even for tabs with
>pages from unrelated servers -- on some pages from Vanguard Mutual
>Funds. I can avoid the freeze and delay by disabling JavaScript.
>However, some Vanguard pages then don't work.