IE instantly displays a page when hitting the back or forward keys. It appears as if they are storing the HTML and the page objects in memory. A common customer request is to improve the speed at which the browser displays pages when hitting the forward and back key. This is especially important over a modem. I think this should be a P1 perf feature for Beta 2.
Adding perf keyword and setting P1 priority
I think the first thing to do is Quantify the performance of the Back button so we can find out where the time is going and file bugs. Who can do that?
This looks like a duplicate of bug 32469 And a major bug it is indeed... it's the thing i miss most in Moz currently. Most other stuff is in place but as for user experience, this one's a real bummer.
I agree. I was looking at a "links" page last night, where I was back'ing a lot, and this was a serious problem. After facing this, combined with a host of other "back" problems (e.g. bug 12550, bug 29609, bug 28142, bug 33690, bug 34911...), *and* the problem that the "back" button always put you back at the top of the page instead of where you left from, I gave up and went back to IE. Any way to raise the priority on getting this stuff working right?
gehlhaar - those issues you mention are filed with other bugs.
*** Bug 33442 has been marked as a duplicate of this bug. ***
Reassigning for Don
*** Bug 38733 has been marked as a duplicate of this bug. ***
Move to M21 target milestone.
I humbly submit that it's a big mistake to continue pushing this one back. I think that you should try reading cnn.com (or similar) over a 28.8 modem before saying "we can wait 'til M21" (four more months?). To me, this is dogfood.
Could this bug be moved to networking cache?
the cache code got hooked up recently for the back/forward buttons. Right now, going back/forward, involves a extra step of getting a History transaction from a in-memory cache and doing the usual loads. may be david matiskella can elaborate more on what we do with the cache and if it has helped the situation.
A comment: Supposedly IE displays a stored screen image of the page you were last at, so that when you hit back, it dumps the image into the display (FAST) and loads all the content in behind it from cache. This has the result of making back/forward appear to work instantly. At least this is what someone told me...
Ben: From examining the behaviour of IE 5.5 on Windows, I doubt that they do this. Going back and forward does not slow down if you change the window size or the font size, for instance.
I fail to see why a comparision with IE is done. NC 4.75 also goes back/forward in a fraction of a sec. Going back to this bug with moz, for instance, took me 20 seconds on a P3/500. Approximately 60 times slower than NC 4.75.
Any chance to get this into NS6? It's the *only* reason I don't use Mozilla as my browser. Even with a cable modem, the forward-back page performance is very, very slow compared to IE (or NS4.75). Am I the only one who things so?!
nominating for m0.9 (as M21 will never exist).
Giving to chofmann, who is leading the performance efforts. Some work is already going on in improving performance while doing back/forward. chofmann's team knows to handle this better.
need to profile this and figure out a way to monitor with daily tests.
I did some testing for this. Summary: we seem to be doing (most) everything correctly, with one exception being a few unnecessary GET's that are likely coming out of imglib. Whatever "slowness" there is, is just the current cost of laying out the page content (but just wait for libpr0n to land :-]). I stuck in some calls to dump current time into the parts of navigator.js where the back/forward buttons are called, and also to where the onload event is handled in the browser. I then set up a series of pages that also dumped timer's in the console when an anchor was clicked. [This was tested on Win2k, 128MB RAM, 500MHz, 100Mbps network]. (And I stuck another printf into nsDocShell::InternalLoad() at the point that it is about to call nsDocShell::DoURILoad(), which in turns calls nsDocShell::DoChannelLoad() which spins off the asynch load of a new document.) I then started the browser (once with cache pref 'Once per session' and a second time with 'Every time'). I visited the pages that i had set up one time, and then I visited each a subsequent time by (a) click on a link, (b) back button, (c) forward button. During this time I also watched the server logs for which HTTP requests were made. Here are the times that I collected. "Event" click back forward Visit # 1 2 1 2 1 2 Policy: Once per session espn.go.com 1.22 1.19 1.23 1.20 1.20 1.20 home.netscape.com 1.17 1.09 1.20 1.22 1.19 1.11 hotwired.lycos.com 0.83 0.64 0.61 0.84 0.80 0.64 lxr.mozilla.org 1.88 2.27 1.81 1.84 1.92 1.83 Policy: Every Time espn.go.com 1.27 1.22 1.23 1.24 1.22 1.27 home.netscape.com 1.22 1.17 1.22 1.25 1.24 1.16 hotwired.lycos.com 0.86 0.67 0.64 0.86 0.84 0.67 lxr.mozilla.org 1.94 1.88 1.84 1.88 1.94 1.86 As far as I can tell, the event is handled immediately (the native event triggers the JS event handler which calls through to native code). I also could measure no difference in whether the code path was through the back button or via a HTML link. The SHistory code executes in an unmeasurable amount of time (i.e., the JS handler and the printf in InternalLoad report the "same" time [note: NT timer has a resolution of minimum 16ms]). Looking at the server logs: 1) there are a few images that were fetched with "If-modified-since" on every visit to the same page, under either caching policy. This would seem to be some problem where the cache and/or imglib is having some kind of problem. 2) we fetch .js and .css everytime since we don't (yet) cache those files (but we knew that). 3) Under policy "Every Time", clicking on a link would trigger an "If-mod.." GET for the images in the page (I'll leave the task of checking that all images were checked to another day, probably after libpr0n and/or the new, new cache comes on line). Under policy "Every Time", clicking Back or Forward did _not_ trigger the same "If-mod..." GET for the images, which is expected behaviour. (However, on a fast network, the cost of two short HTTP transfers per image makes no measurable difference (see numbers above). It would make a difference on a 56Kbps connection, but I'm not set up to test for that. [I have a "slow" proxy server setup, but it can't meter tiny (<1000 byte) transfers, so it wouldn't be a valid test].
so should this bug go to pav/saari?
It could go to them, although I don't think there really is something explicit for them to do. When imglib2/new-cache lands, we (me, or maybe tever) should go through and check that no spurious image GET's remain (for the various possible cache policies).
> When imglib2/new-cache lands Just for clarity, are there any specific bug numbers for tracking imglib2 and/or new-cache progress? Both of these topics interest me, but a query to Bugzilla came up empty when searching for each of those in the summary field. Primarily, I'm interested in how imglib2 and new-cache will be different or better than imblib1 and current-cache, respectively.
Offhand, I don't know a query that would get the list for these two subsystems-in-progress. But, the lead developers for imglib are pavlov with saari, pnunn, email@example.com, and for cache are gordon, darin, with help from beard, so combing their bug lists will lead to these bugs (but also to other bugs they have on their plate(s)).
needs component and qa update.
Update: I spent some time looking at back/forward, checking network activity with a packet sniffer. We now do not ping the network for anything on a back/forward, except for some ad banners that are purposely defeating caching, either through HTTP headers, or JS like document.write("<img src=somefile.gif?" + (new Date()).getTime() + ">"); On win2k, we do not ping for DNS names either (at least not external to the PC). I couldn't see my Mac which is on the same hub/subnet for some reason. My linux box is on a different subnet, so I couldn't see what was happening there either. (In other words, I'm lazy). So, we seem to Do the Right Thing, in terms of not validating content on back forward. I don't think that execution of the actual button-click+code is an issue. On win2k, we don't re-resolve DNS names, and with the DNS cache forthcoming, we won't be on any platform. But, testing an arbitrary group of four pages from netscape.com on win2k/mac/linux, I would subjectively say that we are faster than 4.7, but somewhat slower than IE5.5 (on win2k). So that leaves this as a general layout response time issue in my opinion, but it is not a glaring defect (again in my opinion).
Under Mac in Back/Forward Page Performance: #1 Opera #2 IE ... #3 Moz #4 NS4.7 Moz and NS lag far behind... around 40% of nav is made with the back button I think beat IE and Opera should be one of the first goal of Moz.
*** Bug 104627 has been marked as a duplicate of this bug. ***
same on linux (RH 7.1) PIII (450 Mhz) 256 Mb mozilla 0.9.5 forward/back is much slower (1-2 seconds) than netscape 4.77 (instantanious)
I hate the fact that the summary for this bug compares the perfomance to that of IE. What I want to see is Mozilla beat the back/forward performance of Opera (windows version.) Now that would be something to be truly proud of. Does anyone have any clue how Opera manages to do back and forward so quick? I swear they use some evil power that drains my soul everytime I mouse gesture back..
Btw, that comment applies to Opera 5. Opera 6 seems to do something different...
From the mailing list "LangaList" comes this insight on IE's caching: " IE will exceed your cache limit if it needs more cache than that during a particular session (the time you open the browser window to the time you close it). IE is supposed to bring the cache size back down below your limit when you close the browser window, but it often seems to "forget" to do that. There's a KB article that refers to this problem: http://support.microsoft.com/support/kb/articles/Q301/0/57.ASP " (http://www.langa.com/newsletters/2001/2001-11-19.htm#9) So, it appears that IE's disk-cache size is effectively boundless, limited only by available disk space. And, while that policy does explain some things, I can't say that I fully disagree with it either :-/. BTW, should this bug's component be moved to something besides Browser-General? Its current Component makes it rather difficult to find in a query ;).
xah: That would, of course, only make one back or forward operation faster, which would be an improvement, but not perfect. Think of the cases where most users will find the speed here to be a problem. For me, it's using any Web-Bulletin board, or things like bugzilla. In NS4, I would navigate these types of things normally, start at the list of posts (or bugs), and then click on the bug or post of interest, perhaps click on a follow-up (or attachment, dependent bug, etc), and then click back a few times to get back to the list. With Mozilla/NS6, that's unworkable. Instead, I end up opening a new browser window, keeping the list in one window, and then dragging links to the new "reading" window for viewing. In the end, this is probably _more_ resource intensive than having mozilla cache rendered views of the pages, or more fully-parsed representations of the page. I don't think that caching a bitmap of the page is the right idea, although it might be a "quick fix". And choosing how far back(forward) to cache is a policy decisions and obviously shouldn't be hardcoded (it might not even be a static number of pages; perhaps it is an amount of memory to allocate to such a pool). Subjectively, I think this is still a problem -- in my usage, it's Mozilla's biggest performance weakness, especially for the large pages where I find myself going "back" to the most.
See an alternate idea in bug 113721 to improve back/forward
A chance to get this speedier in 1.0 ?
*** Bug 128884 has been marked as a duplicate of this bug. ***
I see everyone talking about the performance of IE in the back/forward department but I don't think that's even good enough. Opera is the real performance target in this regard. I've clicked on many, many links and then can hit back as fast as my fingers can click the button (or do a mouse gesture -- i use left click hold, right click for forward and the opposite for back) and there is no delay that I can perceive. It's like light. Well maybe not that fast, but still. The one downside I've seen with Opera in this regard is that some pages can go back very fast but are almost never updated from the server when I do go back unless I force a reload. Anyway, I just wanted to say that I think it's Opera's performance more than IE's that we should be considering in the back/forward perf issues. IE wins in a lot of other places over Opera, but not in this regard... not even close.
Either we do full tree caching, which is what Mac IE does and I suspect opera as well, or we make load out of cache fast enough that it doesn't matter. I perfer faster out of cache, but that will never match full tree caching. On the other had, it takes less memory so as usual we have a trade off.
Well then I suggest full tree for the "quick and dirty" fix, and the fast cache version replacing it when it closely matches the full tree implementation. That way we get a fast back / forward performance boost ASAP, and later when a memory saving cache implementation is finished, we can get the speed and memory saving benefit.
I'm guessing (just guessing, but it looks very likely from the fact that fwd/back time seems proportional to the complexity of the page, not its size) that it's the re-parsing and re-layout that's killing back/forward performance, not really the pulling of the raw data from cache. Perhaps the 'trees' could be cached in the same way (or even the same place) as the raw data, subject to the same limits and eviction pressures? I suppose that'd mean that the these 'trees' (what are they, content-trees, layout structures?) would have to be serializable if we let them get flushed out to disk. Maybe there's code for that already.
Adam, Robert, et al: The cache-the-full-tree suggestion is bug 38486 (which is also a dependency for this bug).
IF this was supposed to be done by M21 why is it still not done?
*** This bug has been marked as a duplicate of 38486 ***
Of course, I think that fixing bug 38486 would be a waste of engineering effort. But the other way to 'fix' this bug is what we've been doing for 18 months: just make layout incrementally faster by finding tangible things to fix. In the meantime, this bug has just become a dumping ground for inane comments, like the one just above.
*** Bug 186785 has been marked as a duplicate of this bug. ***
*** Bug 212181 has been marked as a duplicate of this bug. ***