The first time you switch to a panel in DevTools, the new panel can be blank for a few millisecond before the UI loads.

We could try preloading panels on ToolboxTab mouseover to make this initial load time less noticeable.

Shows the difference without/with preload. Tool opening was slowed down to highlight the blank/janky frames without preload. (recorded on a pretty powerful machine though, would be interesting to get the same kind of video on a reference hardware)

WIP - Preload tools on tab mouseover, except for the inspector, which seems to be janky.

We spent a bit of time with Nicolas testing this with different hardware and test cases (thanks for the help by the way!)

It seems promising. Even on the reference hardware for a typical usage (understand: without leaving the mouse for too long on the tab before clicking) it allows to show the display the panels immediately without any "blank frame".

However, we also tested this with a heavier toolboxes, eg 10k messages in the Console (http://console-10000.glitch.me/).
In this case the behavior is not great, mounting the ConsoleOutput will actually hang the parent process for a good 700ms on my machine.
This is acceptable when you are actively switching to the Console, but as a preload operation, it's not.

You can see a profile of this at https://perfht.ml/2MPDjx7
The preload starts ~10.0s, the freeze occurs at ~11.0s (the 1s it takes to reach this is also surprising)

Basically I think this means that even though this is promising, we need to allow panels to do less when doing a "preload" than when they really get displayed.

This is amazing, I would love to try this out in the wild soon.

Is this using similar heuristics as browser.tabs.remote.warmup.enabled? This might help to figure out the tricky heuristics for hitting a good success rate?

Basically I think this means that even though this is promising, we need to allow panels to do less when doing a "preload" than when they really get displayed.

Right, maybe for some panels, just loading the skeleton might be enough, avoiding the potential performance cliffs that loading content gives. Alternatively, we can have a low confidence trigger (mouse trajectory?) that loads the basics and a high confidence trigger (mousedown) that triggers the heavy load.

(In reply to Julian Descottes [:jdescottes] from comment #3)

Basically I think this means that even though this is promising, we need to allow panels to do less when doing a "preload" than when they really get displayed.

Work from bug 1471754 may help doing that.
We may delay the time before we hand over the target(s) to the panel.
If we delay the calls to TargetList.listen to the point where the panel is really opened, we can start:

• loading most modules (including React!)
• load basic react/redux setup
• render the empty UI for the panel
  Then, once we open the panel we call TargetList.listen, receive the target(s), fetch the data from the server and render document specifics.
  Document specifics are the typical things that we don't control and may be big enough to introduce freezes.