Closed Bug 496458 Opened 13 years ago Closed 10 years ago
Improve perceived performance: Load frontmost tab first, and group loading
When restoring a browser session with multiple tabs (especially when restoring 10+ tabs), there's a feeling of the browser grinding to a halt while this happens. Proposal to increase perceived performance and time before you can interact with the first page: - Load the visible tab (or first + second if this makes more sense) completely before starting on the others. - If switching to a new tab while this is in process, start loading/rendering that tab too. - We should store the tab titles if possible from the previous session (if we don't do that already), so it doesn't feel like there are a bunch of blank tabs while completing the first tab load — even if we haven't actually started loading them yet. - Group the loading 2-3 tabs at a time to avoid the "grinds to a halt" perception. I'm not sure what the correct number here would be, but I'm sure we can reach a sensible default based on completion of the page, network latency or similar. This is similar in spirit to bug #480148.
It would also be interesting to load background tabs in MRU order -- no sense in aggressively loading a tab that hadn't been looked at for a long time.
Good suggestion, MRU should be the default order as long as it has the capability of switching priority to a tab "mid-air" if you switch to it.
"We should store the tab titles if possible from the previous session" Caching favicons would be also great.
What about tabs which open a http auth prompt? We switch immediately to those and they are not in the MRU order.
@Henrik, Do you mean the auth prompt shows regardless of whether or not the tab is loading? If so, perhaps the code should be changed to show the prompt at the time the tab is scheduled to be loaded?
I agree with using an MRU list. You could do something like: 1. Load the selected/last used tab. 2. After the above has loaded, load the next X (pref - default 1 to 3) tabs in the MRU list in the background. 3. If a random tab is selected, push it to the top of the loading queue. This bug is referenced by bug #505214: "It should be possible to prioritize the loading of the current workspace when restoring a session/starting Firefox. Other workspaces could load slowly in the background and get priority when selected (or not load until the workspace is opened [pref.]). Individual tabs should be loaded using strategies similar to the ones described in bug #496458." Related to this bug: bug #141615, bug #257453.
(In reply to comment #5) > Do you mean the auth prompt shows regardless of whether or not the tab is > loading? If so, perhaps the code should be changed to show the prompt at the > time the tab is scheduled to be loaded? The tab is always loaded and set as the active tab. It will destroy the MRU order.
A tab that's selected automatically won't destroy the MRU order, but simply change it.
(In reply to comment #7) > The tab is always loaded and set as the active tab. It will destroy the MRU > order. I'm not sure I understand – are all authentication dialogs displayed when FF starts, or only when each authenticated tab begins to load? If it's the latter, then the MRU list for tab loading won't be affected because the tab would already have been pulled off the MRU queue for loading. (if that makes any sense)
It would affect the next startup.
(In reply to comment #10) > It would affect the next startup. Good point. Here are two options: 1. Use a "click-to-activate" mechanism for tabs which require authentication. i.e. Tabs which require authentication are excluded from the MRU tab loading, and only load when selected. 2. Make auth prompts modal to the tab so that the prompts are visible only when the tab is open, and don't automatically move to the tab if an auth prompt is displayed within it. Any other ideas?
(In reply to comment #11) > don't automatically move to the tab if an auth prompt is > displayed within it. Right, that's the real issue with that UI. And there's certainly a bug for that. Let's not discuss it here any further.
Component: General → Session Restore
QA Contact: general → session.restore
So with bug 480148 and bug 586068 fixed, the only thing left unimplemented from comment 0, as far as I can see, is the MRU loading. It's mentioned in bug 586067. Can this bug be closed or clarified?
(In reply to Nickolay_Ponomarev from comment #13) > So with bug 480148 and bug 586068 fixed, the only thing left unimplemented > from comment 0, as far as I can see, is the MRU loading. It's mentioned in > bug 586067. Can this bug be closed or clarified? I filed bug 701090 for MRU, but I'm not sold on the wins we would get from it. I'm going to close this bug in the meantime since we've done the spirit of everything in this bug, mostly in bug 586068.
Status: NEW → RESOLVED
Closed: 10 years ago
Depends on: 586068
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.