Web developers who are mindful of user experience, performance, and SEO pay attention to page speed.

If you’ve ever tested your website on Google Page Speed Insights, you may have seen a message like this:

Eliminate render-blocking JavaScript and CSS in above-the-fold content.

If you are loading Google Fonts via a normal style sheet link in the <head> , then there’s no doubt that link is being looked at a render-blocking file.

Any file that the browser needs to render the page, where it will not show the page without it, is known as part of the critical path. Normally, any CSS file is part of this critical rendering path.

Though Page Speed Insights is a good tool, remember that Google still uses what real users see as a metric for judging page speed and user experience.

So what we want to do is improve our page speed for real users first, but also reduce the number of files on that critical rendering path.

When I really starting digging into this problem, one of the first solutions I found was the Web Font Loader — a joint project between Google and Adobe Typekit. Any browser that supports @font-face can use this.

Why Use The Web Font Loader?

On good broadband networks, deferring the loading of fonts will only save a little bit of time. But on mobile devices — especially 3G devices, it will deliver much faster page rendering. Better page speed on mobile devices means over half of your potential audience will stick around on your website, and not bounce out. (Note: bounce rate is when people leave your site immediately after viewing a single page.) This leads to more conversions, more signups, and more sales.

The Web Font Loader uses a little sleight-of-hand to make site visitors feel like the page is rendering faster.

CSS blocks the rendering of the page, which gives impression of slower page speed. What the Web Font Loader does is defer the loading of Google Fonts until after other parts of the page have started to render.

Advantages of Web Font Loader:

You can use it with Google Fonts, but also Typekit, Fontdeck, or Fonts.com.

This script loads fonts after the critical path, including any CSS in the element.

Disadvantages:

This method uses JavaScript, so anyone with JavaScript disabled on their browser will be served the fallback font-families instead.

How To Use the Web Font Loader

In your page, include a link to the Web Font Loader script. You can set this link to load the latest version, but for performance, it is better if you link to a specific version of the script.

Then, indicate what font families you would like to load from which font service.This is what the code looks like on this very site (We’re using Google Fonts.)

<script src="https://ajax.googleapis.com/ajax/libs/webfont/1.5.18/webfont.js"></script> <script> WebFont.load({ google: { families: ['Source Sans Pro:400,600,700,400italic,700italic', 'Roboto Condensed:400,700'] } }); </script>

There are different methods for Typekit, Fontdeck, and Fonts.com. You can consult the documentation on Git Hub for the Web Font Loader project for specific instructions.

Another way you can use the Web Font Loader is in the head of your pages. This method uses JavaScript to load fonts ansynchronously. Google will show you this method when you go to use Google Fonts if you click on the JavaScript tab.

This is what this script looks like. (It is similar to the previous script, but utilized a different way.)

<script type="text/javascript"> WebFontConfig = { google: { families: [ 'Roboto+Condensed:400,700:latin', 'Source+Sans+Pro:400,600,400italic,700italic,700:latin' ] } }; (function() { var wf = document.createElement('script'); wf.src = ('https:' == document.location.protocol ? 'https' : 'http') + '://ajax.googleapis.com/ajax/libs/webfont/1.5.18/webfont.js'; wf.type = 'text/javascript'; wf.async = 'true'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(wf, s); })(); </script>

In my own testing, this method seemed a little slower than what I am using, putting the former script in the footer. Either way is a compromise. You must test for yourself and decide what works for your site.

The Web Font Loader defers the loading of Google Fonts until after the page starts rendering. But this is only a partial solution.

Webkit Browsers and the FOIC

Webkit browsers like iOS and Safari, will render a flash of invisible content (FOIC) while they wait for the font to load. Firefox renders the fallback font while the specialty font loads. This article by the Filament Group seemed to point towards using @font-face and data URIs to prevent this.

But about a month later, they came up with a better solution, that serves up a fallback font while waiting for the Google Fonts to load asynchronously.

This solution uses a script called Font-Face Observer to “listen” for the font to loaded, at which point, it can add a CSS class to the document, or output a message to the console log.

Font-Face Observer will also load fonts that have a @font-face declaration in the main CSS. More on that in a second.

How you get around the flash of invisible content on Safari and iOS? The Filament Group figured out they could set a style rule for the site for the fallback font-family to start with. When the specialty font finishes loading, this script can set a class of fonts-loaded directly to the <html> element. Then, a second font-family rule that applies to the fully loaded page would take over.

Here’s what everything looks like for a website loading Sans Source Pro as a specialty font:

/* CSS *//* You should be able to use @import or Google Fonts link as well, * these also generate a @font-face rule. * */ @font-face { font-family: 'source_sans_proregular'; src: url('http://www.yourwebsite.com/path-to/fonts/sourcesanspro-regular-webfont.eot'); src: url('http://www.yourwebsite.com/path-to/fonts/sourcesanspro-regular-webfont.eot?#iefix') format('embedded-opentype'), url('http://www.yourwebsite.com/path-to/fonts/sourcesanspro-regular-webfont.woff2') format('woff2'), url('http://www.yourwebsite.com/path-to/fonts/sourcesanspro-regular-webfont.woff') format('woff'), url('http://www.yourwebsite.com/path-to/fonts/sourcesanspro-regular-webfont.ttf') format('truetype'), url('http://www.yourwebsite.com/path-to/fonts/sourcesanspro-regular-webfont.svg#source_sans_proregular') format('svg'); font-weight: normal; font-style: normal; } body { font-family: Helvetica, Arial, sans-serif; } .fonts-loaded body { font-family: 'Source Sans Pro', sans-serif; }

/* JavaScript *//** * I put mine in the footer. You can experiment with where this goes. * */<script src="http://www.yourwebsite.com/path-to-file/js/fontfaceobserver.js"></script> <script> (function( w ){ // if the class is already set, we're good. if( w.document.documentElement.className.indexOf( "fonts-loaded" ) > -1 ){ return; } var fontA = new w.FontFaceObserver( "Source Sans Pro", { weight: 400 }); var fontB = new w.FontFaceObserver( "Source Sans Pro", { weight: 700 }); w.Promise .all([fontA.load(), fontB.load()]) .then(function(){ w.document.documentElement.className += " fonts-loaded"; }); }( this )); </script>

This gives page visitors the content, with a fallback font, without waiting for the Google Fonts to load, which blocks page rendering — making page rendering faster.

This also prevents Webkit browsers from having invisible content while waiting for the specialty fonts to load.

This setup probably isn’t ideal for every site. But for stripped down sites with only a couple of fonts, it can improve page speed.

Now what Filament Group did to cache the loaded fonts in a vistor’s browser was add a cookie via server-side includes that looked like this: <!--#if expr="$HTTP_COOKIE=/fonts\-loaded\=true/" --> <html lang="en" class="fonts-loaded"> <!--#else --> <html lang="en"> <!--#endif --> Now, they are running Perl server-side include scripts on flat HTML files. Unless you have a similar setup, that will be of little help to you. I’m pretty sure there is a way to do this in PHP for WordPress using $_COOKIE and set_cookie() . I’ll come back to this as I test further.