@font-face is an established staple in the diet of almost half the web. According to the HTTP Archive, 47% of websites make a request for at least one custom web font, and the page weight of these fonts is only growing.
In this talk, we’ll discuss why current implementations of @font-face are actually harmful to the performance and usability of the web. Hiding the fallback text while the font is loading means the content will be unreadable until the font loads. Some browsers have implemented a three-second timeout on font requests; but one performance survey has stated that 57% of users abandon a site if it’s not usable in three seconds.
High latency cellular networks and use of multiple fonts can mean disjointed repaints and reflows, which can cause serious damage to the usability and fidelity of your content. These problems are exacerbated when @font-face is used for both content fonts and icon fonts, which need to be handled differently.
But there is hope. The CSS Font Loading API is currently expanding its browser support base and can be used today with polyfills. Or embed your font files as data URIs in an asynchronously-loaded stylesheet. Another exciting proposal is the CSS font-rendering property.
We can use these approaches to make small changes to how these fonts load to mitigate our drawbacks and make the web work better for everyone.
Comments on this page are now closed.