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.
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.
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.
[+] [-] ajdlinux|10 years ago|reply
[+] [-] huuu|10 years ago|reply
[+] [-] snake_case|10 years ago|reply
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.
http://jakedeichert.com
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.
[+] [-] djrogers|10 years ago|reply
[+] [-] SimeVidas|10 years ago|reply
[+] [-] untog|10 years ago|reply
[+] [-] ghayes|10 years ago|reply
That is the _worst_ on mobile.
[+] [-] paulirish|10 years ago|reply
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.
Loading fonts well is hard. Here's some advice on doing it well: https://gist.github.com/paulirish/d511793a1c3b74b31460
[0] You can explore the same recording here: https://frontend.chrome-dev.tools/serve_rev/@db7757b63f29696... (Chrome only. Check the screenshots checkbox)
[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.
[‽] As mentioned later by hatsix, the font-display spec introduces a CSS property to provide control over FOUT/FOIT to the site: https://tabatkins.github.io/specs/css-font-display/ It will definitely bring a lot of sanity to a something that's been a problem since at least 2009 :) http://www.paulirish.com/2009/fighting-the-font-face-fout/
[+] [-] tollmanz|10 years ago|reply
Are you getting the results from your tests in 49, 50, or both? It seems like Chrome 50 was the catalyst for the issue.
[+] [-] 33degrees|10 years ago|reply
[+] [-] hatsix|10 years ago|reply
https://tabatkins.github.io/specs/css-font-display/
The previous behavior (Flash of Invisible Text) was considered an anti-pattern, as it prevented text from being read on slower connections.
The new spec allows CSS to specify the behavior.
[+] [-] snake_case|10 years ago|reply
For me, I'm seeing a fallback in less than 100ms before flickering to my web font. So the timeout doesn't seem to be working right now maybe?
[+] [-] tmrmn|10 years ago|reply
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.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=604844 [2] http://stackoverflow.com/questions/36876232/three-js-there-i...
[+] [-] SapphireSun|10 years ago|reply
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
[+] [-] taspeotis|10 years ago|reply
Instead of @import I just base64 encode things as data URIs. One big fat CSS file with everything the browser needs.
Get the content loaded once and the cache generally takes care of making it fast enough.
[+] [-] iancarroll|10 years ago|reply
[+] [-] tiedmann|10 years ago|reply
[+] [-] signal11|10 years ago|reply
[+] [-] utternerd|10 years ago|reply
[+] [-] TazeTSchnitzel|10 years ago|reply
What if the CSS could specify basic font metrics which the fallback would be shaped to fit until the actual font loaded?
[+] [-] swrobel|10 years ago|reply