FOUT is back in Chrome 50 | Hacker News Reader

FOUT is back in Chrome 50

productforums.google.com

69 pointssnake_case30 comments

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/

Thanks - I really didn't feel like signing in just to read this.

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

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.

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

FWIW, I saw a flash of unstyled text on Safari for Mac.

And I'm seeing it on Edge.

'Fout' is also Dutch for 'error / mistake' ;)

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

Flash of Invisible Text?

That is the _worst_ on mobile.

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.

Here's the browser view of this brief interaction: 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 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/

Seems to be affecting google fonts too

Got any URLs where you're seeing this with Google Fonts (or any other non-JS webfont situations)?

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

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

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.

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?

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 [2] http://stackoverflow.com/questions/36876232/three-js-there-i...

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

The problem here is that you have to use Typekit because you don't actually own the fonts.

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.

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.

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.

A good example of FOUT: http://recordit.co/vsAZQc5ihD

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?

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

Reply on news.ycombinator.com