Reassigning to tbansal@ who provides the network quality estimator for the intervention. It seems NQE fails to estimate the network speed in this case.

Quick Question: Are you sure that font loading finishes in 3 seconds if the intervention does not happen? Regardless of the intervention, page rendering is started with a fallback font after 3 seconds from the font load request. The intervention estimates if this 3-sec timeout happens or not, and if it is likely to happen, the page is rendered with a fallback font immediately. This behavior can be controlled by font-display property. Site designers can disallow this rendering behavior with fallback fonts. Default value is 'auto' that relies on the intervention, and actually we have a problem on using it with third party fonts (issue 777846).

CC: ksakamoto@ who has worked on font-display with kenji.

primano, sorry for the bad experience. Couple of questions:

1. Do you see this on Linux platform as well?
2. Would you mind filing a in-app feedback when you see the error again? The in-app feedback would attach some UMA histograms which would make it easier to understand the problem.

The algorithm has heuristics built in to detect slow-network vs. slow-host. On this host, I see some of the requests take more than 1 second to load which could be tripping the built-in heuristics.

On Mac OS X, we do not have access to the TCP RTT samples from the kernel, and we rely on HTTP layer RTT values, and RTTs from QUIC connections (which may also not be available in some of the cases). This can cause the algorithm to incorrectly detect a slow-host as slow-network.

Fixing  Issue 823322  might solve some of these false positives: With access to HTTP2 ping timings, we should be able to more accurately distinguish between slow-connection and slow-host when TCP samples are unavailable.

Ooh, and the other possibility is  Issue 678075  where the device may be incorrectly detected as offline by Chrome. In that case, the estimator returns network quality as OFFLINE which may trigger font intervention. Having access to metrics would help tease apart these cases.

> Would you mind filing a in-app feedback when you see the error again?

In-app feedback done:
https://support.google.com/chrome/answer/186850?visit_id=1-636693276089143613-4168679859&p=feedback_confirmation&rd=1

> 1. Do you see this on Linux platform as well?

Can't tell sorry. I use my linux box only to ssh and build.

I also manually attached histograms now that it happened again (but I had a chrome session going on for a while)

Lemme know if I can help more providing traces/debug data. Unfortunately this is hard to repro and happens just randomly

Deleted: histograms.txt 5.3 MB

histograms.txt 5.3 MB View Download

Feedback report is here: http://shortn/_xSmHilIdXs (Sorry, google internal only).

I looked at the histograms attached with the feedback report. Some of the HTTP RTT samples were close  to 500 msec (probably hanging GET requests or the server was slow). However, QUIC RTT samples were all low in value.  I am duping this into  Issue 834119  which tracks the work to make use of QUIC RTT samples to further improve accuracy of estimation.

 Issue 869295  has been merged into this issue.