Bluemix Font Stack Test

Font Smoothing Test

TL;DR

(Too long; didn't read)

The Bluemix CSS font stack could be shorter and still do the same thing across all devices. However, the font stack alone doesn't really matter that much for performance.

The more efficient font stack is:

font-family: HelveticaNeue, Helvetica Neue, Helvetica, sans-serif;

The purpose of this site is to test a hypothesis that the current Bluemix font stack is longer than it needs to be, and can be made more concise without losing functionality.

A secondary hypothesis is that the large font stack has a detrimental affect on performance.

I made several pages to test these hypotheses: one with the Current Bluemix Font Stack, one with a Simplified Font Stack, and one with an Extra-large Font Stack.

Font Stack Size and Page Load Speed

The current font stack used on Bluemix is this:

font-family: Helvetica Neue, HelveticaNeue, Helvetica, Segoe UI, Segoe, Calibri, Roboto, Droid Sans, sans-serif;

font-weight: 400; /* normal weight */

It seems kind of long, so I wanted to find whether that might be slowing down page speed. My thought was, if there are a bunch of fonts the machine is searching for, and a big row it has to go down to find the right one, that must add loading time, right?

To test my hypothesis, I created a simple page with filler text (The Declaration of Independence, because it was one of the first things I found on Project Gutenberg). For this test, I check two variations: one with a simple font stack, and one with an extra-long font stack, which included fonts that aren't on my computer (because most were made up font names).

What I forgot is that computers are really fast. The following screen shots and averages simply prove that an extra-long font stack has no easily measurable affect on page load time.

Simple Font Stack

font-family: HelveticaNeue, Helvetica Neue, Helvetica, sans-serif;

Average on screen shots: 267.75 ms

BUT the average on the next 12 reloads was 294.8113333 ms (slightly slower than the xl font stack, below).

Extra-large Font Stack

font-family: Warehouse Gothic, Tiger, Fake Font Name, Another Fake Font, Post Its, Akzidenz, Chicago, New York, Pelham Bay, Sterling Street, Gotham, sans-serif;

font-weight: 400; /* normal weight */

Average: 281.25 ms

BUT the average on the next 12 reloads was 273.4885833 ms (slightly faster than the simpler font stack, above).

So, despite my expectations, the longer font stack does not seem to have a measurable affect on page load speed.

Font Stack and Device Compatibility

Despite the fact that an extra-long font stack has little affect on page load speed, I was also curious to see if a simpler font stack would nevertheless have the same cross-device compatibility as our current font stack. I tested this with this Simplified Font Stack page, which has the following font stack:

font-family: HelveticaNeue, Helvetica Neue, Helvetica, sans-serif;

Currently, the logic of the Bluemix font stack is, of course, to load in Helvetica Neue ( pronounced "noy-uh" because it's a German word) if the user's machine has that. On Windows machines on which neither Helvetica Neue nor Helvetica is present, the fallback font Helvetica triggers Arial, because of Helvetica is mapped to Arial in Windows.

So far, so good. But why are the fallbacks Segoe UI, Segoe, Calibri, Roboto, and Droid Sans called before the default sans-serif? This is done because we're not just serving desktop users, but also mobile users. Users on iOS will simply see the site in Helvetica, but users on Windows Phone and Android platforms should also be served good typography.

However, the Windows Phone and Android platforms are easier to serve good typography than we've given them credit for. We specify Segoe fallbacks for Windows Phone, but actually, that platform maps Helvetica to Arial, just like desktop Windows (see Fig A below). Meanwhile, Android device don't have either Helvetica or Arial, but they don't need to asked to load Droid or Roboto – the default sans-serif specification will call those, because Droid and Roboto are the default sans-serif fonts on Android (see Figs B & C below). All browser emulations were done with BrowserStack.

Fig A:
Nokia Lumia 520 running Windows Phone, with simple font stack.

Font rendering: Arial.

Fig B:
Samsung Galaxy S, running Android, with simple font stack.

Font rendering: Droid.

Fig C:
Google Nexus 4, running Android, with simple font stack.

Font rendering: Roboto.

Strangely, on a tool called Font Family Reunion, it is specified that Segoe will render on either font stack (as opposed to Arial, which is indicated by BrowserStack). Honestly, though, either outcome (Segoe or Arial) seems to be fine – it's not Helvetica, but it is readable. Take a look – both font stacks render the same fonts on all these different environments:

But Arial's ugly! Why not serve Helvetica as a custom web font?

It's understandable that many designers dislike Arial. So sometimes the suggestion of serving Helvetica as a web font is given. But, web fonts slow performance and need workarounds. Also, Arial is more readable for Windows users, especially at small sizes. Finally, that shit's expensive to license. While serving Helvetica over Arial is important for such sites as IBM Design, where the type will be obsessed over by potential future-hires, on Bluemix, it stands to reason that most of our users just want to build and deploy apps, not fret over fonts.