Why We Still Need Web-safe Fonts

Dec 30 2013 by Alexander Dawson | 12 Comments

During the early days of the Web, there wasn’t a standard font that could be rendered across all platforms. However, some fonts — like Arial, Helvetica, and Times New Roman — were more likely to be installed in a person’s computer. These popular system fonts are called Web-safe fonts. It was the best practice in web design to stick to them.

Things have changed. It’s now safe to use Web fonts — a technique for rendering any remote font file in a web page using @font-face. This give us more creative freedom and a much wider range of font options.

The @font-face rule has been around for close to 13 years, first seen and supported in Internet Explorer 5.5[1].

And @font-face has been formally included in the most recent version of W3C’s CSS standards (CSS3) — it was taken out in CSS2.1 — and so modern browsers (e.g. Chrome, Safari, IE, and Firefox) support the rule.

And with services like the free Google Fonts API, implementing Web fonts is easy. For instance, using the Google Fonts web service, it takes two lines of CSS to render even a relatively unknown font such as Bigelow Rules in the vast majority of browsers:

@import url(http://fonts.googleapis.com/css?family=Bigelow+Rules);
body { font-family: 'Bigelow Rules'; }

But even with near-perfect support of the @font-face rule, as a good practice, we should still use CSS font stacks. Moreover, our CSS font stacks should still include Web-safe fonts as well as generic font families like sans-serif and serif.

For example, even if we were to use the most popular font on Google’s Web font service (which is currently Open Sans), we should still use a CSS font stack that includes similar Web-safe fonts, with the last declaration in the stack being a generic font family (sans-serif in the case of Open Sans):

body {font-family: "Open Sans", "Arial", "Helvetica", sans-serif; }

In Chrome, this is the fallback-rendering sequence:

As shown above, using a good font stack assures us that we are gracefully degrading our HTML text in case our chosen font is for some reason unable to load.

Why We Still Need a Web-safe Font Stack

Web-safe fonts and CSS font stacks seem like outdated Web design practices, especially since @font-face has great support.

Right now close to 90% of the Internet’s users use a browser that supports @font-face[2].

But if you’ve ever considered dropping your CSS font stacks, below are a few reasons that might change your mind.

Incomplete Fonts

If certain characters in your font are not available, the browser will attempt to render those unavailable characters using the next font in the stack. But if you don’t have a font stack, it will use the browser’s default standard font.

For instance, the Libre Baskerville font doesn’t have the ™ character.

The first example below shows how the missing character renders in Chrome without a font stack, while the second example stacks "Times New Roman" and serif in the style rule:

At least with a good font stack, the ™ character looks similar to the preferred Libre Baskerville font.

Network Issues

Loading a remote font using @font-face requires an Internet connection. If the web server responsible for serving the font is unavailable or is down for maintenance, the browser will use its default standard text, unless you specify a Web-safe font in your CSS font stack.

For Google Chrome, the standard text (on Windows) is "Times New Roman". This can be bad news if we were using a sans-serif font, and the web server or the content delivery network where the font file is located goes down.

For example, check out this mockup of a web design that uses the PT Sans font:

If our font stack didn’t have Web-safe fonts in the stack and a network interruption happened, our web page would render like this (in Chrome):

The web page looks completely different because Times New Roman greatly affects the visual message of the design.

But if we used a font stack that included Web-safe fonts, we can mitigate some of the aesthetic issues that come with network problems.

Using the font stack:

font-family: "PT Sans", "Helvetica", "Arial", sans-serif;

We are able to lower the visual impact caused by a network interruption:

@font-face Can Be Turned Off Client-Side

Some web browsers provide the option to disable the downloading of font files.

In most cases, disabling remote font files in a web browser is obfuscated, but it’s possible. Here’s a forum post for turning off remote font downloading in Firefox and Chrome, and here’s one for Opera.

Why would someone want to disable remote fonts? To speed up web page load times, which is especially desirable for Internet users who have slow Internet connections.

To illustrate how Web fonts impact Web performance, let’s use a display font such as "Lobster Two".

The following markup was used to test  the Lobster Two payload locally using an HTML document called "lobster-two-payload.html":

<html>
<head>
<link href='http://fonts.googleapis.com/css?family=Lobster+Two:400,400italic,700,700italic' rel='stylesheet' type='text/css'>
<style>
body { font-family:"Lobster Two"; } 
</style>
</head>
<h1>Display Font</h1>
</html>

The test conditions are a broadband Internet connection and an unprimed cache (meaning that the browser cache was cleared for each test).

#1 result. Total time: 972ms

#2 result. Total time: 1.61s

#3 result. Total time: 1.36s

In the condition tested, it would take an average of 1.3 seconds to render the <h1> tag fully for someone who has an unprimed cache.

This means staring at a blank page for 1.3 seconds before the user can read the text, because Chrome’s default behavior is to show no text while the font is still loading[3].

Consider that 1.3 seconds is the average load time using a broadband connection to download the font files from Google’s servers. Imagine how long it would take in less-than-ideal situations, such as slow mobile networks and using a shared-hosting server to serve the font.

Without the Web font, the same document would finish rendering in an average of only 0.012 seconds, which means the font increased the load time by 10,733%. That is a hefty price to pay for rendering a novelty display font that’s not functional enough to be used for critical website content. That’s why some users choose to disable remote font files from loading.

If we want to gracefully degrade our web design in situations where the user has chosen to disable remote font files, we should use Web-safe fonts in our font stack.

It must be noted here that you don’t have to load the entire font family. And if you use the Google Font service, you can selectively load just the font variations you need.

Web-safe fonts = Cheap and Easy Graceful Degradation

Though it’s rare, @font-face isn’t supported in a few web browsers, especially old ones.

Earlier, I mentioned that 90% of Internet users use a browser that supports @font-face.

Not having a font stack that includes Web-safe fonts and a generic font family means that we aren’t controlling how our web design degrades for at least 10% of the Internet’s users.

The time and effort required to use a simple CSS font stack that includes Web-safe fonts is very small, so there’s little reason not to continue doing it.

References

  1. The SitePoint CSS reference for @font-face has a table showing @font-face as being supported in Internet Explorer 5.5+.
  2. According to The Can I use @font-face Web fonts compatibility table, 89.84% of the Internet population uses a browser that has full or partial @font-face support. This data is from StatCounter Global Stats, November 2013.
  3. See the description of the browser-specific Web font rendering behaviors on the Google Developers site. This is outdated because as of Firefox 4 (officially released March 2011), loading Web fonts now behave similar to WebKit-based browsers.

Related Content

About the Author

Alexander Dawson is a freelance web designer, author and recreational software developer specializing in web standards, accessibility and UX design. As well as running a business called HiTechy and writing, he spends time on Twitter, SitePoint’s forums and other places, helping those in need.

12 Comments

Lydie Baillie Parisot

December 30th, 2013

Using Web-fonts has really opened a new door to web design for using typography as a graphic element. It’s always good to have a fallback font like sans serif in the stack.

I find the first thing I do when browsing new fonts, is to make sure the web font has all the characters necessary to display the web page. This is especially true for multilingual pages with accents for example.

Fonts sets that can be loaded on the website server locally are to be preferred to third-party hosted in my experience. This is the same principle that applies to images and videos. It optimizes web page load times and circumvents third-party service interruption issues.

Dan

December 30th, 2013

Any work arounds for circumventing disabling of downloading web fonts? I’m trying to use an icon font – where resources would need to be downloaded anyways (whether it’s a font file or a set of images). Some of our corporate users have font downloading turned off. Really don’t want to have two methods for rendering icons. And, as an aside, if the icon font file exists in local storage and ‘downloading web fonts’ is disabled, it will still load the local icon font correctly.

Bruce

December 30th, 2013

I’m not clear on why you state that “our CSS font stacks should still include Web-safe fonts as well as generic font families like sans-serif and serif.” I used to do this as a common practice, but gave up since I was generally specifying the same fallback the browser would use if I simply used the generic spec. I could see doing this if you really preferred something like Georgia or Palatino to Times for fallback rendering, but if not, why waste time and code?

Jacob Gube

December 30th, 2013

@Bruce: The reasons are stated in the article, with example scenarios and visuals.

To answer your question: In general, font stacks with Web-safe fonts allow you to gracefully degrade in case your Web font is unable to render. (This was also mentioned in the article.)

but gave up since I was generally specifying the same fallback the browser would use if I simply used the generic spec.

One point worth noting in that statement is that people can change their default fonts. So there is a reason for font stacks in that scenario. If you were expecting to fallback to Times New Roman 16pt without a font stack, you might be surprised that some folks are seeing it in Helvetica or Arial.

[...]why waste time and code?

The time, effort, and amount of code needed is extremely trivial, especially for the opportunity to give you some control over how your content will render in cases where your chosen Web font isn’t able to render.

Jacob Gube

December 30th, 2013

@Dan: That is a great question. Specifically because, as you’ve pointed out, disabling remote fonts affects icon fonts. And it seems like a notable amount of people in your user base has chosen to disable remote font downloading? Or is it corporate policy?

I can’t offer you a workaround, because I don’t know how you can force remote font downloads when the user has gone through the trouble of disabling them.

However, I can offer you a UX tip. As a good practice, especially for mission-critical user actions in your UI, it’s best to have both an icon and text at the same time.

I know in some mobile apps, they’ve forgone text and have opted for just icons (one popular example is Instagram’s Tab bar).

However, I find that text is more intuitive. And icon + text reinforces the meaning of a certain user control, as well as increases its visual weight in the UI.

I can only imagine how many people haven’t explored other screens in Instagram because they didn’t know what the icons meant. Maybe I’m just getting old, but it took me a while to understand the IA of Instagram when I first started, specifically because the icon tab bar was not informative.

Also in your case, icon + text would degrade well in instances where the user has disabled remote font downloading. On the systems of those folks, they’d at least see the associated text of the icon.

Sorry I couldn’t give you an answer to your question.

Rachel

December 31st, 2013

Yes! Web-safe fonts and font stacks are still needed. Especially in body copy. Thanks for sharing the info.

caleb

January 1st, 2014

I try to stick to web safe fonts as much as possible. Unless a client specifies a custom font I use arial all the time :)

Marush Denchev

January 2nd, 2014

Great article! Thanks for pointing out what happens if the font doesn’t support specific character – did not know that.

lolmaus

January 4th, 2014

Is there a table of which most popular Google Fonts match which web-safe fotns?

davep

January 11th, 2014

I end up just using font-family:”proxima-nova”,sans-serif; for everything if I want good web readability.

Tim

January 13th, 2014

Unfortunately, no matter what fonts you use Windows renders them terribly.

Dirck

January 18th, 2014

Web fonts have added a great value to webdesign and the creativity that it can provide.Only need to ensure its compatibility with windows. Multilingual fonts tend to be bit fussy.My favorite has been Arial and Sans Serif and used it the most unless the client has specified some other font. Thanks for bringing clarity on web fonts. The post is worth reading.

Leave a Comment

Subscribe to the comments on this article.