There has been a lot more discussion recently about web font performance, and deservedly so. Custom web font usage continues to grow, but the implementation often occurs without considering real-world performance. If you’ve spent any time on the web recently, especially without the comforts of high-speed internet, this may look familiar:

Basic @font-face usage can frustrate your users and keep you from hitting more aggressive performance goals. I’ll go over @font-face and how it can be problematic, different ways to improve font loading performance, and the prospects for better font loading in the near future.

How we got here

Starting in 1998 with Internet Explorer 4, and then from from March 2008 through March of 2010, one by one, all of the “big five” desktop browsers—Safari, Firefox, Opera, and Chrome—have rolled out roughly comparable implementations of @font-face font linking. - http://alistapart.com/article/fonts-at-the-crossing



Usage of @font-face exploded in 2010. Font loading services took off. But the web was a lot different 5 years ago:

A standard @font-face declaration needed EOT, TTF, WOFF, and SVG variations to work well across major browsers.

declaration needed EOT, TTF, WOFF, and SVG variations to work well across major browsers. Mobile support was an afterthought. For example, when the iPhone 4 began shipping during the summer of 2010, Mobile Safari would crash if more than one weight or style of a font was loaded.

Today, the caniuse.com numbers for @font-face are 92.92% globally and 97.89% in the United States. You generally only need WOFF to achieve cross-browser support. Unfortunately, there’s still a major web font problem from the early years that hasn’t been properly addressed: performance.

@font-face Browser Defaults

In cases where textual content is loaded before downloadable fonts are available, user agents may render text as it would be rendered if downloadable font resources are not available or they may render text transparently with fallback fonts to avoid a flash of text using a fallback font. - http://www.w3.org/TR/2011/WD-css3-fonts-20111004/#font-face-loading



While this section of the specification was not actually present until 2011, it’s useful in framing the current font loading landscape. Some time in 2009, Firefox and Opera began shipping @font-face support with the former behavior: text would render with fallback fonts until downloadable font resources became available. But this choice frustrated many users (see the Firefox bug report) and was quickly dubbed FOUT, the Flash of Unstyled Text . Articles were written about fighting the @font-face FOUT. It wasn’t long before most browsers were hiding text while fonts downloaded.