
FOUT is back in Chrome 50 - snake_case
https://productforums.google.com/forum/#!topic/chrome/kBzYJZV-qMM;context-place=topicsearchin/chrome/category$3Amac%7Csort:relevance%7Cspell:false
======
ajdlinux
For those of us who aren't in the know, apparently FOUT stands for "Flash of
Unstyled Text": [https://css-tricks.com/fout-foit-foft/](https://css-
tricks.com/fout-foit-foft/)

~~~
snake_case
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.

[http://jakedeichert.com](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.

~~~
paulirish
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.

~~~
snake_case
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.

~~~
SimeVidas
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.

~~~
snake_case
Okay this is a logical explanation. I am probably wrong then.

------
SimeVidas
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

~~~
untog
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.

------
paulirish
Here's the browser view of this brief interaction:
[http://i.imgur.com/IWFEKGt.png](http://i.imgur.com/IWFEKGt.png) [0]

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](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](https://gist.github.com/paulirish/d511793a1c3b74b31460)

[0] You can explore the same recording here: [https://frontend.chrome-
dev.tools/serve_rev/@db7757b63f29696...](https://frontend.chrome-
dev.tools/serve_rev/@db7757b63f29696b9b465949f9704a0d9d149f2b/inspector.html?loadTimelineFromURL=https://dl.dropboxusercontent.com/u/39519/fout-
trace.json&experiments=true) (Chrome only. Check the screenshots checkbox)

[1] [https://drafts.csswg.org/css-font-loading/](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/](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/](http://www.paulirish.com/2009/fighting-the-font-face-fout/)

~~~
tollmanz
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.

~~~
paulirish
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](https://crbug.com/607788)

------
hatsix
I believe this is intentional, and part of the CSS-Font-Display spec.

[https://tabatkins.github.io/specs/css-font-
display/](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
At first glance, that document states that Chrome (and the other browsers)
have a 3 second timeout before showing the fallback font.

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
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.

[1]
[https://bugs.chromium.org/p/chromium/issues/detail?id=604844](https://bugs.chromium.org/p/chromium/issues/detail?id=604844)
[2] [http://stackoverflow.com/questions/36876232/three-js-
there-i...](http://stackoverflow.com/questions/36876232/three-js-there-is-no-
texture-bound-to-the-unit-0-error)

~~~
SapphireSun
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...](https://developers.google.com/web/updates/2016/03/createimagebitmap-
in-chrome-50)), 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

------
taspeotis
I know it's "bad" but my solution to this is just to stuff everything in the
head tag.

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
The problem here is that you have to use Typekit because you don't actually
own the fonts.

~~~
taspeotis
I'm not familiar with Typekit, but from the link it applies more broadly.

> I've discovered a bug when using the Webfont Loader for Google Fonts or
> Typekit.

I've found most of the Google Web Fonts permit transformation and embedding.
You just need to read the licenses closely.

------
tiedmann
If they could review webfont rendering in Chrome on Windows overall I would be
so happy - it really is much worse than FF, IE and Edge.

~~~
signal11
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.

------
utternerd
A good example of FOUT:
[http://recordit.co/vsAZQc5ihD](http://recordit.co/vsAZQc5ihD)

------
TazeTSchnitzel
It'd be nice if unstyled text wouldn't be as distracting, or rather, that the
transition from fallback font to desired font wouldn't look bad.

What if the CSS could specify basic font metrics which the fallback would be
shaped to fit until the actual font loaded?

------
swrobel
Got really excited when I thought this was FAUT (Find As U Type) like Firefox
has

