Regarding the Flash of Unstyled Text in Chrome 50

This is old news! We’ve addressed this, and made substantial performance improvements to boot; you’ll find the full story in our updated article.

The original post is available below.

Version 50 of Google’s Chrome web browser introduced a change to asset loading behavior that affects how Typekit fonts load. Let’s look at exactly what changed in Chrome, review font loading best practices, and identify some next steps.

Google Chrome version 50 introduced a change that prevents stylesheets injected by JavaScript from blocking page loading. This is similar to the performance improvements we made here at Typekit last summer. What it means is that the browser may begin rendering a page even before it learns that web fonts are on the way.

We support the Chrome team’s decision to make this change, which follows the HTML5 spec. It makes sense to reduce the chance of a page not rendering. However, this new loading scenario has produced unpredictable results for many Typekit users — including a jarring flash of unstyled-then-invisible text.

One solution to the problem is to use Typekit’s advanced embed code. This way, visitors always see the ordinary flash of unstyled text (FOUT), which avoids a messy-looking loading scenario. That said, we’re exploring ways to resolve this issue without requiring Typekit users to manually switch to our advanced embed code.

Let’s take a look at this specific behavior in the context of web font loading in general.

Web font loading, illustrated

Considering how web browsers work, the flash of unstyled text, or FOUT, is a logical and preferable behavior. Browsers first receive page content (HTML), which may point to resources that describe how the page should look (CSS) and behave (JS). Those may point to additional resources (like font files). It takes time to request and receive these different resources, so some will be present while others are still loading.


Rendering the page using what a browser has, and updating it as new instructions arrive, means that content is accessible as quickly as possible — even if slow connections or internet access interruptions cause some resources to be delayed. Visitors may briefly see fallback fonts instead of the web fonts we intend for them to see in ideal circumstances, but we can mitigate this effect by employing font events and making good typographic choices with our fallbacks. This is good.


Some web browsers hide text until web fonts finish loading. This “Flash of Invisible Text” (FOIT) behavior means that visitors only see text when the intended web fonts are present. It makes for a smooth and good-looking experience, but visitors usually wait longer (which means many of them might leave). And in some cases, the text could stay hidden indefinitely. This is not good.


Chrome 50, with with Typekit’s default embed code.

What’s happening to some Typekit users as a result of Chrome’s new loading behavior is that unstyled text is first shown (like FOUT), and is then hidden (like FOIT) until web fonts are present. This is really not good.

The real problem, and next steps

It is not a problem that Chrome made this change to loading behavior. In fact, you can expect other browsers to make similar changes in the future. The real problem is that Typekit’s default embed code has relied too heavily on our assumptions about browser behavior.

Although Typekit offers an advanced embed code that makes font loading better in Chrome, we shouldn’t need to ask users to switch to this. We are still working on resolving the underlying issue, and will keep you posted on what we learn.

If you have any questions or concerns, we’d love to help. Send an email to, find us on Twitter, or leave a comment here.

9 Responses

  1. Great post Tim, and glad to hear this is the approach Typekit is taking (i.e. embracing how things ‘should’ work!)



  2. Yannik says:

    Any updates on this?

  3. Philipp says:

    You got to fix this. I can use the advanced code all I want and I get a Flash on every page change or reload, this can’t be normal or even ‘good’. It is horrendously ugly and I will rather revert back to a good old arial than to live with this.

    While I understand that speed is important and I agree that pages should load fast and users with slow connections on mobile or very rural regions should not have to wait for fonts to load, this notion of ‘it’s all good, actually it’s even better than it ever was’ is a bunch of baloney. It is hideous and I couldn’t care less if fonts slow down the page rendering by a tenth of a second or less.

    I will start looking for typekit alternatives right now.

    1. Tim Brown says:

      Philipp, you’re right. We do need to fix this. I’m sorry that it’s not already fixed. We are still working on resolving the underlying issue. We’ll keep you posted on what we learn, in case you are interested to continue using Typekit. If you’d like to talk about this more, or if we can help with any questions on using font events in your site, we’re here:

    2. Philipp says:

      Thanks for your offer but I don’t see how the support could possibly help me when even this very site we’re having this conversation on has a flashing text on every reload. If it would only happen when the font is loaded for the first time it would be one thing .. but on every single reload? That’s just not acceptable.

      In the beginning I tried using loading events but some certain versions of chrome on android didn’t load typekit fonts for a while at all, so hiding the text while loading was clearly not an option either.

      I brought these issues to the attention of typekits support in the end of april and got a “we’ll look into it” and it seems like not much came from that.

      I love the selection of fonts and simplicity in which typekit fonts can be managed and implemented but if it stays like this, I’ll have to switch to different providers or free fonts that I host myself or another way that I will have to figure out.

  4. IMO I’m not witnessing a lot of love for font events. It should be embraced that browsers are progressing and that typekit, et al., have font events as an option. For the sake of user experience, you don’t have to tolerate FOUC or FOIT. I’ll use Facebook as an obvious example with their mobile application. While text content loads, what would appear as text (pre-styled content is hidden using font events) is just thick gray lines giving the illusion of content being present as an interstitial before the real content appears (once the fonts loaded). The experience is even nicer when it’s animated. Once again, IMO, adapt vs. revolt.

  5. Kristian says:


  6. Phuc says:

    Hello, is there any update on this? It’s been a while now, and even this blog has the same issue (FOUT) when accessing from Chrome (v 51.0.2704.84). We’ve tried various “hacks” which either do not work as expected, or introduce new issues altogether. Still waiting (im)patiently for an official fix!!!

  7. Liz Galle says:

    Hi all, Thanks for checking in, and we are sorry for not having a progress update sooner. The work is nearly done, but it’s a significant change to font serving, so we want to test everything thoroughly and make sure it’s working as expected before sending it off to your sites. We’ll update here on the blog just as soon as it’s ready to go.

    As a couple people have mentioned, we’ve chosen to embrace the FOUT here on the blog. We’d be happy to answer any questions on implementing font events on your own site, though; you can get in touch with us at

Comments are closed.

Tim Brown

Head of Typography for Adobe Typekit & Adobe Type. Practicing typography and web design every day. I write, speak, and make tools to share what I learn. I try to be helpful. I love my wife, kids, family, friends, teachers, and dogs. I'm a volunteer firefighter.

Join us at Typographics 2016

Sally Kerrigan · May 31, 2016 · Type Community

New fonts on Typekit from BAT Foundry

Ariadne Remoundakis · June 7, 2016 · Fonts on Typekit