Remember FOUT? When using a custom font via @font-face, browsers used to display a fallback font in the font stack until the custom one loaded. This created a “Flash of Unstyled Text” — which was unsettling and could cause layout shifts. We worked on techniques for fighting it, for instance, making the text invisible until the font was ready.
A number of years ago, browsers started to shift their handling of this. They started to detect if text was set in a custom font that hasn’t loaded yet, and made it invisible until the font did load (or X seconds had passed). That’s FOIT: “Flash of Invisible Text”. Should a font asset fail or take a long time, those X seconds are too long for people rightfully concerned about render time performance. At worst, this behavior can lead to permanently invisible content.
These days we’re trying to fight against FOIT in various ways. In Faster Font Loading with Font Events, Jonathan Suh suggests using a library to detect if a custom font has loaded, and only then change a class name on the document to set the text in that font. This makes the behavior like FOUT – speeding up readable content at the cost of somewhat jarring visual changes.
Zach Leatherman has been writing a lot about this too. In Better @font-face with Font Load Events he also suggests waiting for the font to be loaded before setting a class to set the type. He also goes into what it takes to trigger a font download (it’s not as simple as a @font-face declaration). Scott Jehl corroborates this in Font Loading Revisited with Font Events, including a bit about cookies and caching.
Zach’s latest trick involved FOFT: “Flash of Faux Text”. The idea here is only waiting for the Roman variant of the custom font to load, and setting text in that right away. You force the browser to create “faux bold” and “faux italic” where needed, which are replaced by the real versions as soon as those are downloaded.
Vitaly Friedman wrote about their approach on Smashing Magazine where they actually use localStorage to cache the font. It ends up being like FOUT on the first page load and (a fast) FOIT on subsequent loads.
I just think it’s interesting how we flip around on this stuff every so often. The browser behaves one way and we trick it into behaving another way. It changes to that way, and we trick it into behaving the old way.
This is pretty cool.
I wonder what would the outcome be if we mixed this method with the old media=’none’ attribute trick to download resources asynchronously. Would it be worth it ?
In case you missed that subjec – here’s the link Loading CSS withou blocking render
Thanks for the mentions!
Yeah, a global timeout for FOUT just doesn’t work—while it was intended for content fonts and may work well enough there, it does not work for icon fonts (whose unstyled fallback characters may not relate to the icon the web font contains).
Luckily, the font-rendering API is coming. It will allow proper configuration for this using only CSS: https://github.com/KenjiBaheux/css-font-rendering
Ironic that I fought against FOUT then, but now as I fight against FOIT, FOUT isn’t so bad. Wild how mobile has changed the landscape of the web.
The localStorage approach is interesting—definitely need to do some experimentation as another solution to push for the ideal scenario.
Thanks for the mention along with providing the other resources!
I feel the client’s content is more important than the typography :)
Remember sIFR it was famous for FOUT? Folks just put up with it in trade for custom fonts… we educated our clients that it was normal behavior in trade for a cool font.
Now perhaps, until a solid solution hits the table, we educate our clients that FOUT is a tradeoff for ensuring their users are treated with their content quickly and in a more predictable fashion which sure beats a TSFONC – Three Second Flash of No Content.
I feel like I care more about the FOUT than the client. I bet if I saw the FOUT pattern more I’d care less.
You might care more than your client. But what about the future users? ;)
A “unique” or “nicer looking font” can play a larger role than some people think in user-retention. For example, I wouldn’t likely stick around any modern-newsform media site that had a font uncomfortable for reading. Although most sites pick a sensible default, so that isn’t the issue.
So let’s look at the flip side of the coin:
Am I more likely to stay at a website that has taken very specific interest in their typography, going so far as to A/B test various line heights and font faces?
The answer is probably “yes”. If they provide a better reading experience I’ll be more likely to choose them over others (even if I’m not specifically avoiding the others)
I just think all users should install all the fonts in the world. That way every font is a system font. Good bye
@font-face, FOUT, FOIT, FOFT. And good-bye all web font services too :p, yikes!For a second I thought FOFT meant “Flash of F@#$!-up Text” >_<. I did, seriously.
Ricardo Zea: In that vein, you should have a look at http://fontfamily.io/
@Zach, dude that’s awesome!
I used this old list for a while there http://www.ampsoft.net/webdesign-l/WindowsMacFonts.html, but http://fontfamily.io/ is like CanIUse.com for system fonts :)
Thanks for sharing!