Hey Sean, it seems the issue was caused by YepNope’s async loading. When I switched to the Typekit async code (and moved it way up to right after Modernizr), it no longer experienced a FOUT.

Tim: Just to clarify, the asynchronous embed code doesn’t necessarily make it easier to hide the FOUT. Font events are available when using both the default and advanced embed code styles, so you should be able to eliminate flashy text no matter what.

Faruk: I’m curious about the delay in font events that you’re seeing with the async code. None of the JS font event callbacks will trigger until the initial JS is finished downloading and executing, but the “wf-loading” CSS font event classname should be applied to the html element immediately when the embed code executes. If the embed code is in the head of your page, that should be before the browser gets a chance to render any part of your page. So, if you have CSS that hides elements with web fonts while “wf-loading” is present, there should be absolutely no FOUT visible, even though you’re using async loading.

Were you trying to use the JS callbacks instead of the CSS classnames, perhaps? Or were you using some other library or tool that was somehow delaying execution of the embed code?

Update on this: I think the slowdown is exacerbated when using YepNope, as I see a much more significant flash/delay when doing so. Using Typekit’s own native embed code works a lot better. Since this was not a reduced test case, I can’t quite be conclusive either way. However, I am posting this here to correct my earlier statement—it was *not* the asynchronous loading (alone?) that caused the problem.

If you aren’t trying to have no FOUT, the async is great, but if you *are* trying to hide text until the fonts have loaded, I recommend not using async. Fast machines + fast browsers will be too fast for your code. 🙂

That said, modernizr.com is now using the new embed code. Hooray! (it also got some other much-needed improvements.)