While investigating youtube first paint timing, most of the time after navigation start main thread is waiting for parser to send data to it, and parser seems to be waiting for data from Necko. I don't know if Necko just doesn't get the data sooner, or if there is something to optimize.
I've been testing the new UI of youtube.com youtube.com/new
Do we start url loading in parent process when user types the url to location bar and presses enter? Since that is the testcase here, open new tab, type url, press enter.
(In reply to Olli Pettay [:smaug] from comment #2) > Do we start url loading in parent process when user types the url to > location bar and presses enter? > Since that is the testcase here, open new tab, type url, press enter. There is not much delay here. The request goes from child to parent as soon as the channel is opened. The olny thing that can delay connecting to the server is tracking protection(I do not know if tracking protection will delay anything here) we could do a bit of testing to see if we can optimize something. There is bug 1348275 that sounds relevant here. (Predictor could sometime speculatively connect to a server even earlier, but that depends on how often a site is visited)
Jason, does anyone has time to take a look? I am not sure if we can really optimize anything here, maybe location bar can speculatively connect to a server on click.
Valentin: can you poke around at this a little? It seems we have two things to look at here: 1) Profile youtube/new and see if necko is indeed the problem. It's not clear to me from what we've got here that IPC, etc is the problem, or if the server is slow, or what. 2) We have the interesting idea that we might be waiting until the child is notified of navigation before launching necko channels, and that we could skip an IPC latency via the awesomebar or some call into the predictor. #1 is more important. If #2 doesn't turn out to be the cause of #1, I'd say split it out into it own bug at some point.
Flags: needinfo?(jduell.mcbugs) → needinfo?(valentin.gosu)
FWIW, Bug 1383299 is sort of a variant of this, though only about initiating the connection. So basically (2). I wonder if there are still ways to optimize how soon parser thread in child process gets the data.
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P2
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.