Bugzilla

Here's a profile of what happens when I enter "google.com" in the Fenix URL bar and press enter, on the way to the first network request:
https://perfht.ml/2S2b567 (with sampling, easier to read but slowed down by profiler overhead)
https://perfht.ml/31yaXOD (without sampling, much less overhead)

This is in an existing about:blank tab. (I entered the URL about:blank manually.)

You can see that there's activity in the parent process a long time before the network chart in the parent process shows the network request starting.

I can see a number of problems:
 - The parent process knows about the URL we want to go to first, but it initiates the navigation through the content process which will bounce the network request back to the parent process. I think we do the same on desktop, so this is probably not straightforward to fix. However, maybe we can start a speculative connect in the parent and absorb some of the latency that way.
 - While the URL bar is focused, the browser has a different size. When enter is pressed, the browser is first resized to its regular size, and then the navigation is initiated.
 - This resize triggers at least two sets of restyle+reflow+paint in the content process (~24ms). These delay the initiation of the network request. (The first paint is from UpdateDimensions+RenderLayers, the second from UpdateEffects once the parent process has painted and knows how much of the browser is revealed on screen.)
 - AsyncOpen in the content process takes another 16ms before it propagates the request to the parent process. Half of that (8ms) seem to be spent notifying "http-on-opening-request" observers inside the content process.

Here's a profile of what happens when I enter "google.com" in the Fenix URL bar and press enter, on the way to the first network request:
https://perfht.ml/2S2b567 (with sampling, easier to read but slowed down by profiler overhead)
https://perfht.ml/31yaXOD (without sampling, much less overhead)

This is in an existing about:blank tab. (I entered the URL about:blank manually.)

You can see that there's activity in the parent process a long time before the network chart in the parent process shows the network request starting.

I can see a number of problems:
 - The parent process knows about the URL we want to go to first, but it initiates the navigation through the content process which will bounce the network request back to the parent process. I think we do the same on desktop, so this is probably not straightforward to fix. However, maybe we can start a speculative connect in the parent and absorb some of the latency that way.
 - Bug 1613484: While the URL bar is focused, the browser has a different size. When enter is pressed, the browser is first resized to its regular size, and then the navigation is initiated.
 - This resize triggers at least two sets of restyle+reflow+paint in the content process (~24ms). These delay the initiation of the network request. (The first paint is from UpdateDimensions+RenderLayers, the second from UpdateEffects once the parent process has painted and knows how much of the browser is revealed on screen.)
 - AsyncOpen in the content process takes another 16ms before it propagates the request to the parent process. Half of that (8ms) seem to be spent notifying "http-on-opening-request" observers inside the content process.