Font loading essentially comes down to two parameters: “font block timeout” and “font swap timeout”. The real goal is to strike a balance between the two.
- Font block timeout: For how long do we hide the text before displaying a fallback font?
- Font swap timeout: For how long do we allow the browser to swap the font after the fallback font has been displayed?
In my opinion, this is a superior way to talk about font loading, because it is more clear that both concepts can be in effect on the same page load. If we break down these two parameters, the default browser behaviour looks like this:
|Browser||Block timeout||Swap timeout|
|Chrome 35+||3 seconds||Infinite|
Now, once we know what parameters we should be thinking about, we can try and decide what timeout periods results in the best user experience for a specific project. In other words: We can make decisions on how we want to handle the time before the fonts have loaded, and what to do when the fonts have finished downloading.
Performance vs design
Picking a strategy is essentially about finding a balance between performance and design. This is where different strategies may be correct on different projects. At the moment I think we’re trying to find a golden go-to solution, which may not exist. Too many factors play into the decision. What fonts are being used? how big are they? How important is the design to the user experience? How big is the budget? and so on.
The trend that we’re currently seeing among performance-minded developers, is to emulate the behaviour from Explorer across all browsers. The belief here is that “Content is king” and should be served to the user as fast as possible. If that means showing a fallback font first, and then swap the fonts when they’re ready, so be it. Even if it is causing a reflow on the page. We’re essentially choosing a 0 second block period, and an infinite swap period.
Designers, on the other hand, might not find this experience optimal, as we are serving the user a “flash” of a design that isn’t how we intended it. And then after the page looks like it is ready, we reflow the page with the intended font. In some cases, this can cause the user to lose their place for a second, as they may already have begun consuming the content.
This is why I think the correct solution depends on the project’s priorities between performance and design. If the design isn’t critical to the experience, then it probably isn’t the best idea to allow for up to 3 seconds of invisible text. 3 seconds is probably too long for any project as that is a long time to block the user from the content. However, I don’t always think it is correct to show a fallback immediately either. Because in a lot of cases this will result in a quick FOUT on computers with fast connections too, which just doesn’t look great. In some cases, this will even happen on every single page load, which really shouldn’t be the case, as the web font should already be loaded into memory after the initial load.
But perhaps the invisible text and the unstyled text isn’t the problem at all. Perhaps the real problem only happens when the “flash” is longer than a flash.