4 ms·

FOUT is back in Chrome 50

69 points by snake_case 10y ago

ajdlinux 10y ago
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/
- djrogers 10y ago
  Thanks - I really didn't feel like signing in just to read this.
- snake_case 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        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 10y ago
        Okay this is a logical explanation. I am probably wrong then.
      - panic 10y ago
        FWIW, I saw a flash of unstyled text on Safari for Mac.
        cwyers 10y ago
        And I'm seeing it on Edge.
- huuu 10y ago
  'Fout' is also Dutch for 'error / mistake' ;)
taspeotis 10y ago
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 10y ago
  The problem here is that you have to use Typekit because you don't actually own the fonts.
  - taspeotis 10y ago
    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.
hatsix 10y ago
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 10y ago
  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?
utternerd 10y ago
A good example of FOUT: http://recordit.co/vsAZQc5ihD http://recordit.co/vsAZQc5ihD
tmrmn 10y ago
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-is-no-texture-bound-to-the-unit-0-error http://stackoverflow.com/questions/36876232/three-js-there-i...
- SapphireSun 10y ago
  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/createimagebitmap-in-chrome-50 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
paulirish 10y ago
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/@db7757b63f29696b9b465949f9704a0d9d149f2b/inspector.html?loadTimelineFromURL=https://dl.dropboxusercontent.com/u/39519/fout-trace.json&experiments=true https://frontend.chrome-dev.tools/serve_rev/@db7757b63f29696... (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/
- 33degrees 10y ago
  Seems to be affecting google fonts too
  - paulirish 10y ago
    Got any URLs where you're seeing this with Google Fonts (or any other non-JS webfont situations)?
- tollmanz 10y ago
SimeVidas 10y ago
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
- ghayes 10y ago
  Flash of Invisible Text? That is the _worst_ on mobile.
- untog 10y ago
  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.
swrobel 10y ago
Got really excited when I thought this was FAUT (Find As U Type) like Firefox has
tiedmann 10y ago
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 10y ago
  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.
TazeTSchnitzel 10y ago
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?

69 points by snake_case 10y ago

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/

djrogers 10y ago
Thanks - I really didn't feel like signing in just to read this.
snake_case 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        Okay this is a logical explanation. I am probably wrong then.
    - panic 10y ago
      FWIW, I saw a flash of unstyled text on Safari for Mac.
      - cwyers 10y ago
        And I'm seeing it on Edge.
huuu 10y ago
'Fout' is also Dutch for 'error / mistake' ;)

taspeotis 10y ago

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

hatsix 10y ago

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 10y ago
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?

utternerd 10y ago

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

tmrmn 10y ago

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-is-no-texture-bound-to-the-unit-0-error http://stackoverflow.com/questions/36876232/three-js-there-i...

SapphireSun 10y ago
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/createimagebitmap-in-chrome-50 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

paulirish 10y ago

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/@db7757b63f29696b9b465949f9704a0d9d149f2b/inspector.html?loadTimelineFromURL=https://dl.dropboxusercontent.com/u/39519/fout-trace.json&experiments=true https://frontend.chrome-dev.tools/serve_rev/@db7757b63f29696... (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/

33degrees 10y ago
Seems to be affecting google fonts too
- paulirish 10y ago
  Got any URLs where you're seeing this with Google Fonts (or any other non-JS webfont situations)?
tollmanz 10y ago

SimeVidas 10y ago

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

ghayes 10y ago
Flash of Invisible Text? That is the _worst_ on mobile.
untog 10y ago
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.

swrobel 10y ago

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

tiedmann 10y ago

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 10y ago
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.

TazeTSchnitzel 10y ago

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?