112145 - extremely slow pages

Status: RESOLVED WORKSFORME

(Core :: Layout, enhancement)

Description

[lode leroy]

viewing the result of the belgian online yellow pages
(called golden pages) is extremely slow.

Comment 1

[Karl Johan Kleist]

Lode: Please always include the "Build ID" in your bug reports. Thank you.

Comment 2

[Karl Johan Kleist]

Build ID: 2001 11 26 03. Windows 2000. 850 MHz / 256 MB.

Renders in less than one second for me. But I can note that the server
is somewhat slow when responding the request.

Comment 3

[Jo Hermans]

Lode: de Gouden Gids is altijd een trage website geweest.

WFM build 2001112009 (regular 0.9.6) on NT. This is a ratrher slow webserver,
even when accessed from Belgian networks. It's build with Microshaft ASP's btw
... :-)

Comment 4

[lode leroy]

BUILD ID: 2001112009 / NT4.0SP6 
The problem I notice is the results page after performin a query,
when scrolling down one page by clicking in the vertical scrollbar on the right, 
it takes 5 seconds to display the next part of the page.
Since the HTML is not reloaded, I think this has nothing to do with a slow
network connection to that site, or a slow server.

Comment 5

[Asa Dotzler [:asa]]

->layout

Comment 6

[rubydoo123]

I can't even access the site, I get a server error so the site must be down. You 
might want to try loading this page again once the server comes back online.

Comment 7

[Andrew Hagen]

When I first went to the site, Mozilla appeared to be finish downloading the
page, but the screen was blank and white. Then I hit the back button to return
to bugzilla. Then I hit the forward button to go back to the site. At that time
the site began to download, and rendering began. 

Later, when I have went to the site in the same browser session, the site
downloaded and rendered normally. I can't reproduce the above behavior, even
after deleting memory and disc cache.

Once I got past the above events, I experienced quick, if not instant rendering
on Build ID 2001120303, Windows 98, 383MHz K6-2, DSL connection. The slowness
referred to in the original report could be caused by a slow or unresponsive
server. 

Mozilla seems to have trouble starting downloads on some sites, however, such as
drudgereport.com. Maybe this site creates a similar problem. Without having
exact steps to reproduce the problem, however, we can't narrow it down. 

Can anyone reliably reproduce this problem?

Comment 8

[rubydoo123]

I tried going to http://www.drudgereport.com/ and it loaded up very quickly, I 
am accessing the web through a cable modem though. There was a short period 
where the plug-in was getting loaded, maybe that is the slowness that you are 
experiencing. I believe that we have several other open bugs referring to the 
page load slowness in some areas. I am closing this one out, you may wish to 
make comments/entries in one of the other perf bugs

Comment 9

[rubydoo123]

Well, I somehow made a comment for anotehr bug in this one, so please ignore 
comment #8.

Comment 10

[Chris Petersen]

Marking WFM in the Jan 24th build Windows ME, OS X, and Linux Redhat 6.2.

Comment 11

[lode leroy]

After installing 0.9.8 on NT4, (build=2002020406)
I quickly checked if the problem is resolved, and it's still there.
This time I dug a bit deeper into it, since other people have reported
that they do not see the problem. Here are my findings:

The problem is that their background image is HUGE (a 1000x4600 GIF),
because viewing just the background image, and trying to scroll trough it
gives the exact same performance 'problems':
after clicking in the vertical scrollbar, under the handle 
(having the equivalent of 'pagedown') it takes about 3 seconds to react.
The problem is most noticable when using the page after the link "rubriek of
trefwoord [raadpleeg index]".

Maybe it's due to the fact that NT4's memory management is not that fast?
From the "task manager" I see that the time is mostly spent in "kernel time".