Incremental layout displays some of a web page's content faster at the expense of slowing down the loading process as a whole. In foreground tabs this is good, as it speeds up getting information, but in background tabs it's pointless, and just wastes resources. This is especially bad when opening many tabs at once, or several large, table-heavy tabs (e.g. phpBB forum threads). It has contributed to things like bug 333734. Disabling incremental layout on background tabs would be a big help. Note that this needs to be fleshed out more. E.g. a user is more likely to switch to first or last tab, so do incremental layout on those? Perhaps half as often on those?

Certainly speaks to bug 333734 comment 2, and sounds quite sensible. Do we have a sense of what sort of performance improvement this would yield?

david / bryner, in addition to not doing incremental layout (for a tab loading in the background) are there any other things we could not do for background tabs?

I don't know about not doing other things for background tabs, but giving network priority to the currently focused tab would help load times too (bug 305402)

brendan, this was the bug i mentioned that might be able to help the "several dojo apps in different tabs" performance issue.

on a related note, see 336060

brad, this is the bug I mentioned in today's meeting.

Noming for 1.9 since improving performance/responsiveness with multiple tabs open is critical.

I'd note that there's a tradeoff between amount of work done while things are in the background and the response time when switching them back to the foreground. But I suspect we might be able to come up with a good compromise -- probably one involving reducing the priority / frequency of updates for things in background tabs but still not stopping them completely.

I guess this is critical for session restore, too.

(In reply to comment #9) > I guess this is critical for session restore, too. > Why?

I'm assuming because if you've got a lot of tabs being restored, it's possible that the browser could grind to a halt trying to render everything at the same time.

I can reproduce such behavior with current trunk on my linux box. Restoring a session freezes the browser for a ~10-15 seconds. (same happens when I start Firefox and try to write into address bar - I think it's because Firefox is trying to rebuild the smartbar autocomplete)

This would be really great.

> but in background tabs it's pointless, and just wastes resources. One thing about incremental layout is that it _does_ prevent long pauses (which would otherwise happen when the whole layout is done in one shot at the end of the page load). So it's not quite pointless even in background tabs, though I agree that rendering the content in somewhat larger chunks is almost certainly desirable.

One thing I just realized about this is that getting the page titles into tabs as quickly as possible *is* important, because those are always visible. So this should take steps (if needed) not to break that.

We should look into suspending/throttling background reflows, switching/turning off incremental reflows risks introducing longer pauses.