With staggered background tab opening [1] enabled, we want to dela background tab work if possible, in order to improve user's experience with foreground tab ( issue 730098 ). That includes delaying network requests, render process creation, page rendering, etc.

Currently staggered background tab opening uses NavigationThrottle to delay the navigation, which delays network requests and page rendering. But it cannot delay renderer process creation. With PlzNavigate, we could have the capability of not launching the process until we unblock the navigation and have it ready to commit. But this behavior requires some changes to the navigation code.

Nasko and Camille gave some thoughts before. And I copy them here to start the discussion and track the effort.

Nasko:
> With PlzNavigate, we start a process creation in parallel with the network
> request, but we do it to avoid the time taken to create a process after we
> receive the data from the network. It is quite possible that we don't create
> this speculative process if the tab is backgrounded. Maybe we can make it even
> configurable through ContentBrowserClient or WebContentsDelegate, or fully
> encapsulated inside content. There are some options : ), but let's discuss those
> in email, rather than code review comments.

Camille:
"To add to what Nasko is saying, it should be quite easy to invert the order of process creation and NavigationThrottles running once PlzNavigate is launched. The only issue I could see is that we could wait longer to create the process than we do right now because we have to wait for the BeforeUnload event. However, once we land the change to not wait for BeforeUnload to execute if there are no handlers, this shouldn't make a difference for the majority of navigations (unless throttles take a lot of time to execute...)."

[1]: https://docs.google.com/document/d/1_CS5kcY00CE3pzDTtW5Ny221gWfk4mFXYGiezoYSCBI/