Talos shows this gains us on the order of 13% on twinopen on macOS. I don't have linux/windows numbers because I think my hacky patches to check the impact of this broke something, but I wrote them on macOS where they didn't, so unsure what exactly - https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=53f0121950670da44af74b7526ad02e3b58ba921&newProject=try&newRevision=c9ca30341ad4db76ad148b8ac1f5ac0688c8c064&framework=1 .
ts_paint is very noisy so no conclusions there, but I would expect a similar win in ms (smaller in percentage terms, of course). Possibly the same kind of impact on sessionrestore many windows.
The tricky part is doing this without breaking any functionality. The wip patch I pushed ( https://hg.mozilla.org/try/rev/49fe74f15ca36743f8815c1dec683e1352793971 ) doesn't even try to be subtle about things, it was just designed to test what happens if we don't incur any of the relevant cost.
Some panels/menus/tooltips should be relatively straightforward - we could just wrap them and make the few places that access them unwrap them.
Other panels are harder, because there's existing code that assumes the panel/popup is always available and it (and its contents) can be modified (the page actions menu, site identity popup, and ctrl tabs pane, hamburger panel, etc.). While we could just delazify things as soon as they're accessed, that would likely not win us much (or perhaps lose us something, as we incur more runtime costs than if we never modified the DOM, and potentially additional ones from additional localization passes).
So we may have to do the hard work of lazifying access to some of these panels. That's annoying, but on the other hand it brings other benefits - for instance, it seems we currently update various UI items in panels when the user switches tabs or navigates, and if we could stop doing that work unless the panel is delazified and open, navigation/tabswitching costs also improve.