Here's a profile I captured on start-up: https://perf-html.io/public/75cea1de7333eb66c69f39778d9c21d21e3c2b67/calltree/?callTreeFilters=prefix-012345Kr.4PrPsES5PuOrxWnJkxwtCLnDC4xWnOnY3xC1DVaOrxWnJkxwuCLnDC4xWnJkxwvCLnDC4xWnJkxAu&thread=0 The vast majority of the time at start-up blocking first paint appears to be spent inside AddonManager.jsm. At least in my testing profile, it's spending time initializing the manager and running the bootstrap scripts. Is it possible to run these things more lazily, or perhaps move them to initialize once the browser UI has already painted and we have some idle cycles? I would argue that, especially because these are bootstrap.js add-ons, they're likely designed to be able to disable / enable at arbitrary times during a browser session (to facilitate things like dynamic updating). Doesn't this mean we can defer their loading until after we've shown the UI? Doing so might imply that the icons / browser_actions for various add-ons show up after the browser UI. That's probably okay.

(In reply to Mike Conley (:mconley) - PTO on April 28th. from comment #0) > I would argue that, especially because these are bootstrap.js add-ons, > they're likely designed to be able to disable / enable at arbitrary times > during a browser session (to facilitate things like dynamic updating). > Doesn't this mean we can defer their loading until after we've shown the UI?

(In reply to Mike Conley (:mconley) - PTO on April 28th. from comment #0) > I would argue that, especially because these are bootstrap.js add-ons, > they're likely designed to be able to disable / enable at arbitrary times > during a browser session (to facilitate things like dynamic updating). > Doesn't this mean we can defer their loading until after we've shown the UI? No. See bug 1301392 comment 29. SDK add-ons already mostly defer initialization until after firstpaint, and I'm working on delaying initialization of WebExtensions until they need to load content scripts or modify network requests, but ordinary bootstrapped add-ons need to load early and handle their own lazy initialization. Most of the time currently taken up at startup by default is in initializing system add-ons. Some of those can probably be improved (and I've already talked to the SHIELD team). But some of that is also deceptive, since one of the largest chunks of time even there is in loading CustomizableUI.jsm, which needs to happen before first paint in any case. System add-ons just happen to be the first things to do it. See also bug 1356825.

(In reply to Kris Maglione [:kmag] from comment #2) > But some of that is also deceptive, since one of > the largest chunks of time even there is in loading CustomizableUI.jsm, > which needs to happen before first paint in any case. System add-ons just > happen to be the first things to do it. I agree that loading CustomizableUI.jsm will happen anyway, but any add-on using it before the first window even exists is doing something wrong IMHO. Pocket and flyweb use it.