16 years ago
16 years ago


(Reporter: lode leroy, Assigned: Marc Attinasi)



Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [, URL)



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

Comment 1

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

Comment 2

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
Assignee: asa → attinasi
Component: Browser-General → Layout
QA Contact: doronr → petersen


16 years ago
Keywords: perf

Comment 6

16 years ago
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

16 years ago
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

Mozilla seems to have trouble starting downloads on some sites, however, such as 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

16 years ago
I tried going to 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
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Whiteboard: [

Comment 9

16 years ago
Well, I somehow made a comment for anotehr bug in this one, so please ignore 
comment #8.
Resolution: WORKSFORME → ---

Comment 10

16 years ago
Marking WFM in the Jan 24th build Windows ME, OS X, and Linux Redhat 6.2.
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 11

16 years ago
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".
You need to log in before you can comment on or make changes to this bug.