Font Face Best Practices Guide

Typography (the artistic use of letters) is extremely important in great web design. We spend hours trying to find the perfect font for our various projects to ensure that the text looks just as beautiful as the rest of the design. There is one big problem with using pretty fonts on the web: every operating system renders fonts differently. That means that the look of your website can change dramatically from Windows, to Ubuntu, to Mac. Many companies use “web safe” fonts to avoid the trouble of font rendering variations. They use simple fonts like Arial, Tahoma, or Verdana; those fonts are great but they don’t define a brand’s identity. An alternative would be to use cufón font replacement, but that adds multiple layers of complexity. We’re not okay with that so we decided to figure out the best way to ensure everything renders well… everywhere. Surprisingly, we didn’t find a definitive guide to make that happen. So, we’re creating our Font Face Best Practices Guide. We’ll keep it updated as we find newer ways to render fonts in the future (and as you give us feedback).

Every browser renders each font differently, but we’ve found a relatively general technique to get the best possible results (so far) across all browsers. We tested these rules on the latest versions of Chrome, Firefox, Safari, Opera, Internet Explorer, and Edge. We also tested the rules on Windows, Mac, and Ubuntu. We’ll first show you our code and then explain why we do it. After that, we’ll tell you how to get the same results.

@font-face {
	font-family: font;
	font-weight: normal;
	font-style: normal;
	src: url('/fonts/font.eot');
	src: url('/fonts/font.eot?#iefix') format('embedded-opentype'),
	url('/fonts/font.woff2') format('woff2'),
	url('/fonts/font.svg#font') format('svg');
	url('/fonts/font.otf') format('opentype'),
	url('/fonts/font.ttf') format('truetype'),
	url('/fonts/font.woff') format('woff'),
}

@media screen and (-webkit-min-device-pixel-ratio:0) {
@font-face {
	font-family: font;
	font-weight: normal;
	font-style: normal;
	src: url('/fonts/font.svg') format('svg');
}
}

body {
	-webkit-font-smoothing: antialiased;
}

That specific order will net you the best possible font rendering results across all browsers. Ultimately, most browsers try to use the first font in the source list. If it’s not compatible, it looks for the font file type it wants. Here’s how we came up with our recommended order:

The font.eot file is a generally accepted practice for using @font-face within older versions of Internet Explorer.
The font.woff2 works the best in most modern browsers, but isn’t compatible with older browsers.
The font.svg file is the second best way to render fonts on compatible browsers (very few support it).
The font.otf file is next because older versions of Firefox don’t render ttf, woff, or svg well on Windows.
The font.ttf file works okay nearly everywhere, so we left it in as a fallback… but most browsers won’t use it.
The font.woff file works great in most modern browsers and is the fall-back for woff2.

At this point, these rules work great everywhere except a few older versions of Chrome on Windows. These versions of Chrome on Windows always load the older woff file instead of the svg format – event though it’s compatible. In fact, if you use Google Fonts for your @font-face, it will only serve the woff file to compatible browsers. Since woff looks generally awful on Chrome in Windows, this makes Google Fonts practically useless. That’s why we added the chrome-specific @media query under the normal @font-face code.

The @media query allows us to target Chrome (and other WebKit browsers like Safari) specifically. By eliminating the other sources, we can force compatible versions of Chrome/Safari to load the font.svg file. The font.svg file renders beautifully because it has built-in anti-aliasing, but most browsers can’t use it.

Ultimately, we have to add all of these font files to our @font-face declaration because there is no single file type that works with every browser. Almost all modern browsers support woff/woff2, but developers and designers need to think about older browsers too. If a website doesn’t work well on an older browser, it could force people to ignore the content. At Drift, we build every site with as much backwards-compatibility as possible to reach the largest audience possible. That’s why we needed to write this Font Face Best Practices Guide in the first place.

We’re still not quite finished. Our Font Face Best Practices Guide would not be complete without adding the font-smoothing options to the body element. If any of our compatible browsers use something besides the font.svg file, we want them to smooth the font using ant-aliasing. That helps us maintain the look of the font across all browsers and platforms.

Converting a Font for the Best Font Face Compatibility

This is an art all by itself. We recommend starting with a font.ttf file and converting it to the rest of the formats with free online conversion tools. But… you can’t use a single converter to get all of the formats you need. So here’s what you should do:

First start off with Font Squirrel – choose expert settings and check the boxes for TrueType, EOT Lite, and SVG. Everything else is fine.
Never use Font2Web – their render/conversion techniques do not produce good results.
We’re still missing the font.otf format, so go to FontConverter, upload the font.ttf again, and have it output font.otf.
Now that you have all of the necessary files, upload them to your server and start building the CSS.
Do not – I repeat do not – use the Font Squirrel CSS. That defeats the purpose of this article.
Copy our CSS code and modify it for your font’s name and location.

Using Multiple Weights of the Same Font Family

It’s not possible to use the same font-family CSS declaration for multiple weights in @font-face. They won’t render properly if you try it. If you want to use multiple weights of the same font, you’ll still need to start with a font.ttf file and convert each weight using the instructions above. After you finish converting the different weights, you’ll need to add them as separate @font-face declarations, define the new source URLs for each new weight, and set the font-weight to normal, bold, etc. for each. To use them in the content, you’ll need to make sure that you’re using the right font-weight property for the right text. Here’s an example of how to make your h1 elements bold and p elements normal:

h1 {
font-family: font;
font-weight: bold;
}

p {
font-family: font;
font-weight: normal;
}

Don’t forget to add the extra @font-face declarations to the @media query for Chrome so it loads the font.svg file for each weight. You can use a single @media query for all of the @font-face rules. That’s it! You can now add beautiful typography to any website without hesitation thanks to our Font Face Best Practices Guide.

A Word of Caution

What? You said I didn’t have to hesitate. Yes, you’re right… because you should be using proper optimization techniques so this next section doesn’t matter. If you’re not, you have to decide what is more important: fast loading or beautiful fonts.

Using this technique is slightly slower than a service like Google Fonts. As we mentioned, Google doesn’t serve the fonts beautifully to all web browsers, so you’re sacrificing beauty for speed… unless you know how to properly optimize a website. Our Font Face Best Practices Guide doesn’t cover optimization, but we’ll give you a couple pointers.

You should be caching your website and using a CDN (Content Delivery or Distribution Network) to serve all static files to your visitors. If you’re doing that, this shouldn’t make a big difference in your website’s loading time… just don’t go nuts and add 10 fonts via @font-face. That would create a rather large, unnecessary download.

If you’re using WordPress, but not optimizing your site, we can help. We use W3 Total Cache for our optimizations. It can be a royal pain to configure properly, but we’re awesome at it. If you’d like help making your website faster (and prettier), just let us know.

That’s it – for real this time. Please be sure to bookmark our Font Face Best Practices Guide for future reference and share it with your friends. We’ll update it as necessary when font support across all of the browsers improves. We wish that everything supported svg, but it doesn’t look like that will ever happen. If you have suggestions or problems, let us know via our contact options. Be sure to clear your cache before reaching out; that could be causing the problem.

Font Face Best Practices Guide – Updated 2016