Closed Bug 33269 Opened 24 years ago Closed 22 years ago

Back/Forward Page Performance is slow compared to IE/Opera

Categories

(Core :: DOM: Navigation, defect, P1)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 38486

People

(Reporter: chriss, Assigned: jrgmorrison)

References

Details

(Keywords: perf, topperf, Whiteboard: [nav+perf]) 

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
Keywords: perf
Priority: P3 → P1
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
Assignee: don → radha
Target Milestone: --- → M18
*** Bug 38733 has been marked as a duplicate of this bug. ***
Move to M21 target milestone.
Target Milestone: M18 → M21
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).
Keywords: mozilla0.9
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.
Assignee: radha → chofmann
Status: NEW → ASSIGNED
need to profile this and figure out a way to monitor with daily tests.
Assignee: chofmann → jrgm
Status: ASSIGNED → NEW
Keywords: topperf
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].
Status: NEW → ASSIGNED
so should this bug go to pav/saari?
Whiteboard: should get better with imagelib landing
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, tor@cs.brown.edu, 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)).
Blocks: 71668
needs component and qa update.
Whiteboard: should get better with imagelib landing → should get better with imagelib landing [nav+perf]
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).
Whiteboard: should get better with imagelib landing [nav+perf] → [nav+perf]
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..
Opera caches the entire DOM tree for each page in session history.  When you 
hit back, the page is restored without being reparsed.  Even javascript 
variables are in the same state they were in before you left the page.  (Try 
navigating session history after playing with 
http://www.gwydir.demon.co.uk/giles/javalife.htm in various browsers.)
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 ;).
Component: Browser-General → History: Session
How about keeping more than one rendered page in memory? Both the "back" and the
"forward" pages could be kept in memory, in addition to the current page, in
their rendered forms. It's not necessary to keep every rendering of every page
in memory. Just the one "back" and the one "forward" page would be enough.
They've already been rendered. Depending on the potential resource cost,
however, we could maybe keep two "back" pages, and two "forward" pages in
memory. Dealing with JavaScript could be complicated.
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.
Depends on: 105395
See an alternate idea in bug 113721 to improve back/forward
Depends on: 84286, 113721
Switching dependency to original of duplicate.
Depends on: 38486
No longer depends on: 113721
Depends on: 111036
QA Contact: asa → claudius
Hardware: PC → All
Keywords: mozilla0.9.9
Summary: Back/Forward Page Performance is slow compared to IE → Back/Forward Page Performance is slow compared to IE/Opera
Blocks: advocacybugs
A chance to get this speedier in 1.0 ?
Keywords: mozilla1.0, nsbeta1
*** 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).
Keywords: mozilla1.0 → mozilla1.1
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 ***
No longer blocks: 71668, advocacybugs
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
No longer depends on: 38486, 84286, 105395, 111036
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → VERIFIED
*** Bug 186785 has been marked as a duplicate of this bug. ***
*** Bug 212181 has been marked as a duplicate of this bug. ***
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.