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 support@typekit.com, find us on Twitter, or leave a comment here.