File Under: CSS, Fonts

Dealing With the Dreaded ‘Flash of Unstyled Text’

That's a fancy-lookin' T you got there.

That's a fancy-lookin' T you got there.

The use of custom fonts on the web is finally a viable option for designers.

Browser support for CSS’s @font-face rule is pretty solid — even IE 5 can be wrangled into displaying custom fonts loaded from your server. Services like Typekit, which licenses fonts from well-known font foundries, and free services like Font Squirrel are helping to smooth the licensing issues surrounding custom fonts on the web.

However, while browser support and licensing is getting sorted quickly, there’s still one big problem with web fonts — the dreaded “Flash of Unstyled Text,” or FOUT.

The problem (despite the name, it has nothing to do with Adobe Flash) stems from how browsers render a page: progressively, prioritizing the raw content, then grabbing the stylesheet and then grabbing any external font files. The actual FOUT effect can be seen in the wild, but it varies by browser.

Internet Explorer will load the font file as soon as it encounters the @font-face in your CSS, which minimizes FOUT. However, make sure to put your @font-face declaration above any script tags, otherwise IE will hold the entire page until the font loads.

Safari and Chrome (and other WebKit browsers) hide any text styled with @font-face until the font is fully loaded. This means your styled text content is invisible at first, and then pops onto the screen later, after the font file loads.

Firefox loads all your text normally and displays it using a fallback font. Then, a half-second or so later, that text is “upgraded” when the custom font data is loaded. The result is a jarring font change, much like older, Flash-based font solutions. Mozilla is currently treating this behavior as a bug in Firefox. Mozilla plans to adopt the WebKit-style rendering in the future.

Obviously none of these cases is ideal, and the little loading hiccup, no matter what form it manifests itself in, is noticeable even to the most oblivious of web users.

FOUT sucks. So, what do you do? There are a variety of techniques that can be used to minimize — and even eliminate — the FOUT.

First, limit your pages to only one or two external fonts. While the golden age of custom fonts has indeed arrived, try not to abuse the machinery.

Another obvious solution is to minimize the size of your included font file. This starts with choosing fonts with smaller payloads when possible. Not all font packages are equal — when it comes to the web, stick to fonts in the kilobyte range rather than some of the bigger, multi-megabyte files out there.

If your server supports it, be sure to serve your font files using gzip compression. Read developer Stoyan Stefanov’s great article on gzipping font files. His tests show a 45-to-70 percent reduction in file size when using gzip to serve font files. If you’re using WOFF-formatted fonts, you can skip this step, because WOFF already includes compression.

So you’ve selected small font files and only a couple of varieties, and you’re serving them with gzip compression. But you’ve still got a FOUT. What to do?

Start with heavy caching. Set your expires header to something in the very far future, which will cause the browser to cache your font files almost indefinitely. It won’t help for the initial page load, but subsequent loads will happen faster.

Then you can get even trickier — but caution, for here be dragons. None of these techniques is 100 percent effective, and all have drawbacks like slower page-load times and incomplete browser support.

One way to trick the browser into downloading the font file sooner is to use the font declaration to style the <html> tag. For example, say you have an @font-face declaration in your stylesheet and a class “myfont” that uses it. Apply that class to the HTML element like so:

<html class="myfont">

As per the CSS spec, @font-face does not cascade, so the whole page won’t inherit the font. But both Firefox and Opera will load the font file much sooner. Unfortunately, WebKit browsers will not.

You can trick WebKit browsers into loading the font sooner by adding an element to the head of your page. Developer Paul Irish has an example of this in a post on @font-face. Irish points out that adding a tag to your header will cause WebKit to download the font file:


The problem is that obviously this is not valid HTML, and most browsers will render the element in the document body when the page loads, so you need to remove or hide it. Although it may work, we don’t suggest using this technique unless absolutely necessary.

Another possibility is to hide the entire page until the font file loads. This is one the solutions TypeKit has started to use, adding a new class to the page body tag when the font files have been loaded. Just hide the body tag, then set the loaded class to “visible,” and you’ll avoid the FOUT.

Of course, this method avoids the FOUT by holding up the entire page, which may not be the best solution.

The final — and perhaps most useful — solution to FOUT is to simply learn to live with it. Browsers load fonts in roughly the same way they load images. Slow internet connections have always meant progressive page loads, with elements staggering in as the browser draws the page.

With more and more sites adopting @font-face, services like Typekit and other custom web-font solutions in spite of the Flash of Unstyled Content, more users will become accustomed to the hiccups. This will make your own site stand out less.

These solutions aren’t perfect, but when has the web ever been a source of perfection?

See Also: