The URL loads very slow from cache. Go to it, and follow a link, then hit back. No network activity, but it takes Mozilla 2001081715 28 seconds to finish rendering the page from memory cache. Netscape 4.7 takes 3 seconds, after it's in cache to draw the whole page. Navigating links on the page back and forth in Moz is quite unusable. P2/266MHz, 256M

This doesn't seem to be a problem anymore (or at least it isn't as severe as reported). In any case, the problem was more likely with layout than the cache, if the page was getting fetched from the memory cache. I suspect this bug has been fixed by other checkins since it was originally reported. Marking INVALID.

Send it to rendering then, dunno what component that would be. Just tried again, with 2001093021, it took *51* seconds to fully render. It says "Document: done" early on (maybe after 5-10 seconds), but progressive rendering takes forever to finish the page. Scrollbar keeps getting longer and longer, etc. Netscape 4.7 is reloading the page in THREE seconds. It's most definatly still in cache. I have 100% CPU use during those 51 seconds, and no network traffic from Moz. Maybe it optimizes badly for long and nested <ul>'s?

I tried this on the wrong platform. I'm able to reproduce the problem with my linux build, even when I save the file locally and visit it as a file: URL, which doesn't go through the cache. Changing component to layout.

Is this related to bug 77458?

Moving Mozilla 1.01 bugs to 'future' milestone with priority P1 I will be pulling bugs from 'future' milestones when scheduling later work.

So this is pp? Seems odd UNIX layout could be that drastically slower. For people who aren't opening links in new tabs, this makes ALL mailing list archives unusable (You could literally copy the location to clipboard, close Mozilla/NS6, start up IE/NS4, and paste in the URL and have it load faster then Mozilla can render it from cache when you click 'back'). Taking a shot at nsbeta1 nominiation. This is probably the worst perf bug I know of (though bookmark properties is a close second).

nsbeta1-. Engineers are overloaded with higher priority bugs and this bug will take a significant amount of time to diagnose and fix.

This problem is not as severe as 30 seconds (more like 6 seconds) for me in 0.9.9 and 2002041707 Linux but then again I can't remember if I had this problem in the first place. Reporter, has this bug become any better in newer builds?

No. Linux 2002041409 (1.0 branch). 24 seconds to render.

So this is a rendering problem. tested on local disk - no cache: 15 s Mozilla 2002051013 (1.0RC2) 2 s Netscape 4.7 This performance difference makes the difference in the browsing experience even with relatively small and uncomplicated web pages. Naturally, this problem is most visible when using the cache, because users would not expect a noticable delay. Although Mozilla (1.0RC2) is already a great browser, it still seems to have a significant problem in rendering speed. (check other bugs on slow rendering) After all, the browser is used for rendering pages.

any current stats?

6 s Mozilla 1.1 (Gecko/20020827) 2 s Netscape 4.7 Keep up the good work!

Don't compare times with Opera or you'll realize no progress whatsoever has been made. The cache should be almost instantaneous. It's loading a few K of info from the hard drive, after all. I just filed bug 186785 before finding this bug. The problem must not just be rendering. Some pages obviously would have a huge delay because they somehow cause reloading from the website. So, I don't know if my bug is a duplicate, but Mozilla must have a very fundamental problem because it cannot even be quick enough when the server is not contacted again. It is true that most pages can be reached (forward/back) within about 2 seconds from my testing, but Opera works practically instantly.

I find Mozilla reasonably usable on my P2/266; what however is definitely unusable is my P133, which takes about 30 seconds to load the bugzilla query page from offline cache. Most of that time is actually taken up by repainting the page every second - at that speed, very little processing gets done between repaints. I ended up setting the inital paint delay to 10 seconds, thus giving Mozilla sufficient time to process the page before painting it.

what's new with this bug ?

I don't know if it was said before, but there is the same bug on anchors. If you click on an anchor, the page is reloaded instead of just being scrolled.

Oops, sorry you can delete my previous message. anchors or worling very well.

Jeremy, can you test if this still fails? obtained via archive.org

FWIW: On Windows XP SP3, Fx 3.6.4 takes ~6 seconds, Chrome 5 takes ~5 seconds, Opera 10.53 is instantaneous. Can anyone check on Linux?

I've tested this under Linux, and it takes the same time of Chromium (it's more or less instantaneous). So I think we can mark this bug as resolved.

this problem again started showing in the stable & nightly version on linux pages from cache take ages to load

three of my university students also tested with new profile(linux with nothing installed except over 1k bookmarks[they study researching so :P ]) pages from cache don't seem to load fast enough & parts of the pages(like thumbnails) fail to load even if the server image has not changed & when switching to online mode the images don't load from cache properly and are downloaded again reproduce-try any site with loads of thumbnails