Looked into this a little bit. 

Here's a devtools trace of the maker.me page:

https://frontend.chrome-dev.tools/serve_rev/@db7757b63f29696b9b465949f9704a0d9d149f2b/inspector.html?loadTimelineFromURL=https://dl.dropboxusercontent.com/u/39519/fout-trace.json&experiments=true   -- Protip: Go into DevTools Settings and then experiments.. Shift key 6 times and turn on Network Requests on Timeline. 

Screenshot of the same trace attached.


The stylesheet is received, and the datauri requests are started in the next Style Recalc. (Issue 502371 tracks an optimization here).
Blink thinks these data uri requests take 300ms in total. But looking at the net layer, it appears the data uri requests were delayed a bit. Perhaps the new prioritization at play here? (cc pmeenan)

Regardless, the network is taking longer than you'd expect and in the meantime, we appear to paint a frame while we wait for those datauri requests to complete.  I'm surprised by that as our 3s timeout should be applying to datauri fonts just the same.


TLDR - two issues I'm seeing.
1. Download of datauri fonts is being deferred quite a bit.
2. Our 3s invisible text timeout doesnt seem to be applied during the requests of these fonts.

Deleted: Screen Shot 2016-04-28 at 9.04.43 PM.png 496 KB

	Screen Shot 2016-04-28 at 9.04.43 PM.png 496 KB View Download

Deleted: FOUT frame during datauri download.png 175 KB

	FOUT frame during datauri download.png 175 KB View Download

This may be happening because Typekit's JS contains some code to work around a font-related bug that was fixed in M50--perhaps there's some bad interaction between the workaround and the fix:

https://bugs.chromium.org/p/chromium/issues/detail?id=592226

"""
I had to work around this issue in the Web Font Loader (https://github.com/typekit/webfontloader/blob/master/src/core/nativefontwatchrunner.js#L39) by repeatedly calling document.fonts.load until a font is recognised and loaded (instead of calling it once, after receiving the "load" event from a stylesheet containing fonts).
"""

Resource scheduling and prioritization is only applied to http(s) URLs: https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/loader/resource_scheduler.cc&q=ResourceScheduler&sq=package:chromium&l=586

I have heard there is a fast-path in blink for Image data-uri's but in general it's unfortunate that we have to bounce them off of the browser process at all.  

+Ksakamoto to look into the apparent absence of a 3s FOIT when fonts are data:URI based. See comment #1.

Bram: is there anything in Typekit or its use on this website that would explain the absence of the regular 3s FOIT behavior?

It is not just TypeKit related. 

I now see it in fonts.com script tags, and I believe I saw it with regular CSS @import in stylesheet from Google Fonts. It's only matter of time when it becomes issue as more users start reporting about it.

Toyoshim:
 - any chance that this is the font intervention mis-triggering?
 - what would be the command line to turn it off in order to get a confirmation?

Assigning to toyoshim for now in case it's related to font intervention. Please reassign as necessary.

The intervention can be disabled completely by chrome://flags/#enable-webfonts-intervention.
But I confirmed that the issue still exists even the feature is completely disabled.

I discussed with Sakamoto-san offline, but we do not have any idea what could make this in m50. Let us ask bisect to find a suspicious change.

let me release the ownership so that a proper developer can take it when the bisect finishes.

Unable to reproduce the issue on windows 7, Linux Ubuntu 14.04 using chrome version 50.0.2661.94 and canary 52.0.2730.0 with the below steps

1.Go to URL https://maker.me/bohemianguitars/your-brain-on-music-why-it-s-good-for-mind-and-soul
2.Record the timeline
3.Observed the loading time in canary 4.65s and stable 6.75s

Not able to find any difference.Please find the attached screen shot and confirm anything missed here.

Please provide us the specific repro steps,and expected screenshot would help us to provide the bisect.

Thank you!

Deleted: 607788.png 1.6 MB

	607788.png 1.6 MB View Download

#10, can you try reload operation at the page?
The headline text "Your Brain on Music: ..." would be shown in a different font at the first place, but you will see that it is quickly replaced with another font. If I understand the issue correctly, this is the reported problem starting from m50.

Kenji: Do you think we would start showing a log in DevTools console when the intervention is triggered? That wold help to triage this kind of issue that may be reported more often once v2 gets to be under experiment.

Yes, we should have a clear notice (but not spammy)

I think this is working as intended.

See attached scheenshot of the maker.me page timeline view.

First, Typekit's JS is loaded by a <script> tag in <head>. The JS injects a <link> to a stylesheet which includes @font-face definitions. Note that stylesheets injected in this way is non-blocking in M50 or later [1], so it does not block first paint.

Actually the first paint was BEFORE the stylesheet load finishes. At this point the browser does not know about the "freight-sans-pro" font, so the headline text is rendered with fallback (sans-serif) font.

Then the stylesheet is fully loaded and parsed. It causes style recalc because it changes @font-face set of the document, and the browser recognizes "freight-sans-pro" is a web font and triggers fonts load.

Fonts are loaded in async-style even with data: URLs. In the second paint (with recalculated style), the headline text is blank because the font requests are still in flight.
It might be possible to make data:URL fonts loaded synchronously, but it wouldn't fix the first paint with fallback font.

After the second paint, fonts' response handlers are invoked, and finally web fonts are rendered.


TL;DR
This is caused by blocking behavior change of injected stylesheets. Typekit stylesheets are now loaded asynchronously, and page is rendered before the font definition is loaded.

[1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/xvxa1WaFuFc

Deleted: Screenshot from 2016-05-12 14-09-47.png 321 KB

	Screenshot from 2016-05-12 14-09-47.png 321 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/62cdfb92ab962c0c8678000b1265037209b33c65

commit 62cdfb92ab962c0c8678000b1265037209b33c65
Author: toyoshim <toyoshim@chromium.org>
Date: Thu May 19 04:39:27 2016

WebFonts: show a console message when an intervention is triggered

To be clear when and for what the intervention happens, let me show
a console message in DevTools. This will help to triage bug reports
from users for coming v2 implementation.

This change also fixes a bug that enable-webfonts-intervention-trigger
flag wasn't propageted from the browser to renderers.

BUG= 607788 ,  578029 

Review-Url: https://codereview.chromium.org/1987193002
Cr-Commit-Position: refs/heads/master@{#394674}

[modify] https://crrev.com/62cdfb92ab962c0c8678000b1265037209b33c65/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/62cdfb92ab962c0c8678000b1265037209b33c65/third_party/WebKit/Source/core/css/RemoteFontFaceSource.cpp