496458 - Improve perceived performance: Load frontmost tab first, and group loading

Status: RESOLVED FIXED

(Firefox :: Session Restore, defect)

Description

[Alex Limi (:limi) — Firefox UX Team]

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.

Comment 1

[Justin Dolske [:Dolske]]

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.

Comment 2

[Alex Limi (:limi) — Firefox UX Team]

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.

Comment 3

[Vít Šesták 'v6ak']

"We should store the tab titles if possible from the previous session"
Caching favicons would be also great.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

What about tabs which open a http auth prompt? We switch immediately to those and they are not in the MRU order.

Comment 5

[Glen A.]

@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?

Comment 6

[Glen A.]

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.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(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.

Comment 8

[Dão Gottwald [:dao]]

A tab that's selected automatically won't destroy the MRU order, but simply change it.

Comment 9

[Glen A.]

(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)

Comment 10

[Dão Gottwald [:dao]]

It would affect the next startup.

Comment 11

[Glen A.]

(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?

Comment 12

[Dão Gottwald [:dao]]

(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.

Comment 13

[Nickolay_Ponomarev]

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?

Comment 14

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(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.