paint-brush
Speeding up First Contentful Paint while loading web fonts using @font-faceby@gigacore
862 reads
862 reads

Speeding up First Contentful Paint while loading web fonts using @font-face

by Santhosh SundarNovember 29th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

One of the major concerns with loading web fonts using the <strong>@font-face</strong> rule is the increased load time. With the increased load time, the text to which the font has been applied takes longer than usual to appear on the page — that’s not good for the User Experience.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Speeding up First Contentful Paint while loading web fonts using @font-face
Santhosh Sundar HackerNoon profile picture

One of the major concerns with loading web fonts using the @font-face rule is the increased load time. With the increased load time, the text to which the font has been applied takes longer than usual to appear on the page — that’s not good for the User Experience.

We don’t want our users to wait for the content considering the fact that is already available but just isn't visible to their eyes. The modern browsers come with a mechanism called “Flash of Invisible Text” or “FOIT ”. Chrome and Firefox render invisible text for 3-seconds, if the font is still not available, they use system font as a fallback and swap once the web font is ready. The problem is more severe in Microsoft Edge and Safari browsers, the former uses a system font as a fallback and the latter waits until the font is ready with no fallback as an option. With that, the time required for the First Contentful Paint takes a toll.

This can be very useful for demographics with slower internet connections, especially on mobile devices.

Below is a demo page with FOIT in action as observed in the second frame where the text is completely invisible. Also, notice the metrics. It takes 1.7s to achieve the First Contentful Paint.

The metrics and the impact of FOIT can be severe on a complex webpage or an application.

Thankfully, there is a very simple fix to overcome this issue. And it can be achieved by just adding a few lines of code to your CSS. We now apply a technique called “Flash of Unformatted Text” or simply, “FOUT” to mitigate this issue. This allows us to display the text the moment it is ready in the DOM with a system-native font as a fallback before the custom font is loaded.

Unformatted text (left). Text using the custom font (Right).

font-display to the rescue! 🎉

Adding font-display: swap; to your @font-face rule will tell the browser to use the fallback font provided in the font-family property until the custom font is available and applied to the text. In the below example, the “sans-serif” is used as a fallback until the “WildCoorg” custom font is available.

<a href="https://medium.com/media/5671b33461781649724f867f6f6de08d/href">https://medium.com/media/5671b33461781649724f867f6f6de08d/href</a>

This significantly improves the overall load time with an almost 100% reduction in First Contentful Paint and First Meaningful Paint as well. As observed in the below Lighthouse report, you can notice that the text is already visible to the user in the second frame, unlike FOIT.

The font-display property currently has full support by major browsers excluding Internet Explorer and Edge. Hopefully, it should soon be supported on all browsers. Until then, we can leverage this to improve the UX for users with modern web browsers.

This can be very useful for demographics with slower internet connections, especially on mobile devices. The sooner the content is visible to the user, better the user experience. Additionally, the lighthouse reports yield you a better performance rating for your site.

If you like the post, share it with your team and friends. I’m @Gigacore on Twitter. Find the complete list of my articles over here.