I forgot here -- this actually did not require a dummy user to repro. WPT was able to repro this by going to 

https://www.facebook.com/legal/terms

as a logged out user

This is intriguing. Self-assigning for a deep dive.

Here's a direct link to the trace file:
http://www.webpagetest.org/getgzip.php?test=160404_C5_18V6&file=1_trace.json

At a quick glance, DWriteFontProxyMessageFilter::OnGetFontFiles is taking long time.

Kulshin, can you take a look? IUC, this is in your area of expertise.


I was aware of a significant performance improvement on startup time through the introduction of the font proxy. So, I wondered if we ended up taking a hit elsewhere:
 - I looked into any potential negative impact on the loading metrics (e.g. PageLoad.Timing2.NavigationToFirstLayout / ...ContentfulPaint) but as far as I can tell it's actually a win on these as well :)


In short, this isn't a regression but a "can we do even better" kind of bug.

+gab as an fyi

(A minor update: tzik@ has tried to look into this delay (as we've been looking into similar but different fonts-related / sync-IPC related delays), but so far we had no luck to repro this on our local Windows machine.  We're interested in what kulshin@ / dwrite owners would say too)

Can you get a trace/profile of the browser process? That would help figure out why it's taking a while to respond.

This is data we are getting from production so it's unfortunately impossible for us to get detailed tracing data. We do have the webpagetest generated trace in the comments above which seems to point to font loading.

The trace file says it's on a single core machine.
I think most of the sparse slices are due to the busy CPU...

From what we saw from the given tracing data & local tracing data we think it's likely due to multiple threads contending on one core and it's not really because the particular FontProxy IPC is slow (i.e. any IPC or task could become slow due to de-sched).  This means that there're things we should do in greater context but for this particular one I'd suggest we mark this WontFix-- unless kulshin@ has other ideas.

Interesting, which process is the contention happening in Kinuko? (or is it a mix of all Chrome processes?)

No objections on WontFix.

Re: #10: Have you been able to look at a browser-side trace? Would be good to confirm if we have that data.

So for what it's worth this is just a trace that we generated to simulate what we're seeing in the field. We see that on the first layout for FB many windows users are taking hundreds of milliseconds of time. It's possible that this trace doesn't exactly represent that problem.

We're working to get some more data on our end (for example, by using a setTimeout heartbeat to detect periods of time that might be layout). Are there any more stats we could look into on the chrome end to detect if there might be long layouts on windows

#11: It spans all active Chrome processes, but mainly on the other renderer. It seems busy to execute a JS.
#12: The raw trace.json is available on #4.
http://www.webpagetest.org/getgzip.php?test=160404_C5_18V6&file=1_trace.json

Closing as WontFix as per comment 10 and 12.

 Issue 600160  has been merged into this issue.

I recently fixed  issue 631258 , which caused Chrome to load excess fonts when doing font fallback. With that change I'm seeing a significant reduction in fonts that Chrome tries to load, which should help with this case.

Closing as Won'tFix per #10 and #17.