Should I Load Google Web Fonts JS API or the CSS Link?

I was checking out the source of a site that used some Google Web Fonts today and noticed they were loading them through the JavaScript FontLoadewr script. Being ever the curious one I began to wonder what the benefits were and if they were worth it. In the process I learned some new tricks to help with site performance and formed some strong opinions on how I won’t be using Google Web Fonts.

This CSS-Tricks article on the basics of Google Web Font API talks about the two main ways to load Google Web Fonts in your project. We all know them but I think a lot of us blindly follow the advice posted on CSS Tricks. Let me add some context to these tips.

Loading CSS with a <link />

Google gives you the link tag to paste into your site. Most people load their fonts this way. Is it the best way though? Spoiler alert: Yes. It is the best way with one caveat. Google gives you a link that looks like this <link href='|Muli:300' rel='stylesheet' type='text/css' />. If your site is not on HTTPS and you plan to never use a certificate to secure it then this is fine. For the rest of us, a better way is to leave off the protocol so that the link ends up looking like this instead:

`<link href='//|Muli:300' rel='stylesheet' type='text/css' />`

The difference is that we leave off the http:// part. This allows a user to load the font over whatever protocol the site is on. So if you had an HTTP and HTTPS version of your site (which you shouldn’t, pick one or the other) then the request to Google will be over whichever protocol the site is being served on. This ensures that you don’t get any mixed content warnings if you’re site is using SSL and you have the freedom to start using HTTPS without having to change any of your static asset links. Ideally, you should reference all your assets in this way. It works in every browser (yeah, including IE6).

CSS Tricks recommends following the URL in Google’s link tag and concatenating it to the top of your stylesheet. The idea here is to save another request and help speed things up. I disagree with this. In theory this suggestion is valid but in practice it can actually be hurting performance. This is because most users of the web have visited hundreds of sites using Google’s web font service for years now. This means that the stylesheet reference given to you by Google is most likely already cached in the user’s browser. This means no request is going to be made unless the fonts and/or stylesheet haven’t been encountered before. Granted, if you’re using an obscure web font reference then copying the file into your own CSS may be best after all. Your mileage may vary but in normal usage copying Google’s font stylesheet into your own is just bloating your CSS files. Really, a few external downloads shouldn’t be a big deal. I’m working on a site now that’s using more than 10 scripts and 3 stylesheets. After running it through a build system the total number of assets a user will end up downloading ends up being 3 (excluding images); one JavaScript file and two CSS files (Google’s web font stylesheet and my own).

Using the JavaScript FontLoader API

The JavaScript API sits in the head of your document and is asynchronous so it won’t block the rest of your page while it’s doing its thing. It’ll load your site’s fonts just the same as a link to a stylesheet will (in fact, the JS actually creates a link element pointing to Google’s web font stylesheets) but avoid pitfalls like the dreaded FOUT (flash of unstyles text). I wouldn’t recommend using it without a very good and well thought out reason.

FOUT should not be an issue for most of us. If you’re not providing fallback fonts then you’re asking for trouble. The web is all about text (unless you’re on YouTube). Preventing a user from reading your text because you want it to have the exact font you specified is like not selling someone your product because you want them to give you cash in a very specific way (imagine if McDonal’s would only sell you items from the dollar menu if you provided 3 quarters, a nickel, 1 dime, and 10 pennies). So first off, use a fallback and if the font fails to load your users won’t hate you.

What I don’t like about using the JavaScript API is that it encourages you to hides all of the text until the fonts have loaded. This is a bad idea. Maybe you think fallback fonts being “upgraded” to the ones the author intended is annoying or ugly but it’s far better than making a user wait. Some browsers will actually hide the text for you by default while others use the “upgrade” technique. This should really be a moot point though. Because text is such a fundamental part of the web experience its best to load any web fonts before anything else. I always load the fonts before my stylesheets even. Follow best practices and load just a few fonts, only the fonts you need and load them up as the very first asset on your page. Do this and FOUT won’t be an issue for anyone. Well, okay, it will be for some people but they’ll be on extremely slow connections or mobile devices. You should have a plan in place for those people anyway. The last reason I don’t like the HavaScript API is because besides hating scripts in my <head>, I hate the idea that I need to run JavaScript on a page to request a static asset.

In my opinion, controlling the flash of unstyled text is not worth disadvantages using the JS API brings. The worst of these disadvantages is the fact that users with JavaScript disabled won’t get the font at all. None. Just the fallback.

Front-end coding, Web design, Web development

« Apache 2.4 and 500 Errors in htaccess Terminal tricks that will change your life »