Yeah... I probably should have commented that earlier.
If anyone wants to see an example of FOUT, you might be able to on my website with Chrome 50. I am currently experiencing this and then I found this bug report. Reload a few times if you don't see it at first.
edit: FOUT usually means a fallback font is briefly shown before flickering and rendering a loaded web font.
edit: As people have pointed out below, my situation likely has nothing to do with this possible bug. My website layout is very lightweight and Chrome is rendering it probably faster than the other browsers I tried which explains why I'm seeing FOUT more often in it. And yes, I'm loading my CSS asynchronously which is the main reason behind my FOUT.
You are using loadCSS to load the font from google fonts. loadCSS is designed to asynchronously load a stylesheet. Given an asynchronous load of the font, I'm not surprised you're seeing occasional FOUT. You should adopt the recommended <link> tag technique for your webfonts, unless you're willing to follow the more advanced font performance / FOUT guidance from Zach Leatherman.
I just switched from using a blocking link tag to loadCSS today which indeed loads it asynchronously. I'd say 1/5 times I am not seeing FOUT.
However I'm not seeing FOUT on Safari for Mac and iOS and Firefox for Mac at the moment.
*edit: I definitely understand that you're right Paul. If the website loads slow, FOUT is expected. However, I'm seeing it more than what I expected to with loadCSS combined with this bug report I found. So I'm kind of leaning toward the idea that it is a bug in Chrome 50. If not, I'm wrong and it's only my loadCSS causing it.
When you load web fonts asynchronously, you’re allowing the browser to render the page without them. Since your site is very light, Chrome is able to perform the first render practically immediately (like within 100ms), so the FOUT is very noticeable.
Btw, once the CSS `font-display` property becomes available, you’ll be able to control web font rendering to some extent, but as of now, this type of FOUT is the best approach, since, if you went with FOIT, you’d risk up to 3 seconds of whitespace in case your fonts experienced network congestion.
Better FOUT than FOIT. When I have to look at large areas of whitespace while the page loads, I get irritated. Just let me read the text, you stupid website! :P
It seems there is no good answer (short of not using custom fonts) - while FOIT irritates me as well, the inevitable repositioning of everything on the page when the custom font loads is also deeply infuriating.
Basically, the stylesheet finished transferring and the browser followed up with laying out the page. Some data:uri requests were in flight and when they finished (200ms later) the page was laid out again and now applied the fonts.
Typekit has historically detect in JavaScript when a font loads because they like to ensure the text stays invisible (across browsers) while the page hasn't finished loading the fonts. But in this case, it looks like there's a problem with either Typekit not finding the load "events"[1] of these fonts, or Chrome mishandling data uri fonts in some way. We've filed https://crbug.com/607788 to investigate further.
[1] https://drafts.csswg.org/css-font-loading/ was standardized for these purposes. It's available in Chrome, Opera and Firefox to reliably detect when a font has finished loading.
I've been hearing reports of increased FOUT lately and noticed it myself. I just so happened to use someone else's computer this evening tonight and did not see the issue. Turns out that I am seeing FOUT on every page load with Typekit fonts in Chrome 50, but not Chrome 49 or Firefox.
Are you getting the results from your tests in 49, 50, or both? It seems like Chrome 50 was the catalyst for the issue.
I'm digging in a little more and seeing some odd behavior, but it's unclear if this stuff is new to 50. Star this ticket to follow along: https://crbug.com/607788
Chrome 50 also introduced some overly eager GC bugs [1] and throws weird new WebGL warnings [2].
Basically all our WebGL projects are affected and clients already started to complain that textures aren't showing or that preloaders are stuck. Hopefully the fixed release gets shipped soon.
Interesting, I encountered problems with image decoding. Image.src = dataURL stopped being reliable. I suspect that the code was refactored to support createImageBitmap (https://developers.google.com/web/updates/2016/03/createimag...), and some kind of race condition or something causes some decoded images to be correctly sized but blank.
We fixed this by making users that support it use createImageBitmap, but I've also seen some Windows Chrome crashes that I suspect are from that call.
EDIT1: Also, thanks for the tip about the WebGL error. I've been seeing that too.
EDIT2: D'oh it looks like you also spotted the reason for the src attribute as well. I should have clicked the link before responding. ;D
I have difficulty viewing very thin text, and unfortunately the way Chrome renders common fonts like 10-12pt Arial and Verdana makes me strain my eyes. Firefox and Edge work okay for me.
