Walking down an aisle in a library, I no more than glance at the vast majority of books shelved on either side of me. Only a madman would suggest that my disregard of these books should sanction their pages being torn out. Nonetheless, because research has shown that visitors don’t read the average Web page in full, and because the “success” of a page is more easily measured by user action than cognition, we are often encouraged to marginalize our writing in favor of visual signifiers or action cues.
Sure, most people will “bounce” your content, but if you really have something to say, don’t alienate the people who are willing to give your writing a chance. Good typography does justice to your words, and good wording does justice to your ideas. If readers are comfortable reading your type, then they will more likely be comfortable with what you are writing about.
For perhaps the first time since the original Macintosh, we can get excited about using system UI fonts. They’re an interesting, fresh alternative to web typography — and one that doesn’t require a web-font delivery service or font files stored on your server. How do we use system UI fonts on a website, and what are the caveats? System UI fonts being amazing kind of snuck up on us. Google has been toiling away at Roboto with great success (including regular updates), Apple made a splash with San Francisco, and Mozilla asked renowned type designer Erik Spiekermann to create Fira Sans.
Code language: CSS
font-family: /* 1 */ -apple-system, BlinkMacSystemFont, /* 2 */ 'Segoe UI', 'Roboto', 'Oxygen', 'Ubuntu', 'Cantarell', 'Fira Sans', 'Droid Sans', /* 3 */ 'Helvetica Neue', sans-serif;
The first grouping is CSS properties that map to the system’s UI font. That covers a lot of ground, and there is no chance that these fonts will be mistaken for something else:
-apple-systemtargets San Francisco in Safari on Mac OS X and iOS, and it targets Neue Helvetica and Lucida Grande on older versions of Mac OS X. It properly selects between San Francisco Text and San Francisco Display depending on the text’s size.
BlinkMacSystemFontis the equivalent for Chrome on Mac OS X.
The second grouping is for known system UI fonts:
Segoe UItargets Windows and Windows Phone.
Robototargets Android and newer Chrome OS’. It is deliberately listed after Segoe UI so that if you’re an Android developer on Windows and have Roboto installed, Segoe UI will be used instead.
Ubuntutargets… well, you can guess, and
Cantarelltargets GNOME. This is beginning to feel futile because some Linux distributions have many of these fonts.
Fira Sanstargets Firefox OS.
Droid Sanstargets older versions of Android.
- Note that we don’t specify San Francisco by name. On both iOS and Mac OS X, San Francisco isn’t obviously accessible, but rather exists as a “hidden” font.
- We also don’t specify San Francisco using
.SFNSText-Regular, the internal PostScript name for San Francisco on Mac OS X. It only works in Chrome and is less versatile than
The third grouping is our fallback fonts:
Helvetica Neuetargets pre-El Capitan versions of Mac OS X. It is listed close to the end because it’s a popular font on other non-El Capitan computers.
sans-serifis the default sans-serif fallback font.
- Self-hosting is significantly faster. Loading a typeface from Google Fonts or other hosted font service adds an extra (blocking) network request. In my testing, I’ve found replacing Google Fonts with a self-hosted font can improve a site’s speedindex by ~300 miliseconds on desktop and 1+ seconds on 3g. This is a big deal.
- Your fonts load offline. It’s annoying to start working on a web project on the train or airplane and see your interface screwed up because you can’t access Google fonts. I remember once being in this situation and doing everything possible to avoid reloading a project as I knew I’d lose the fonts and be forced to stop working.
- Go beyond Google Fonts. Some of my favorite typefaces aren’t on Google Fonts like Clear Sans, Cooper Hewitt, and Aleo.
- All web(site|app) dependencies should be managed through NPM whenever possible. Tis the modern way.
Each typeface package ships with all the necessary font files and css to self-host an open source typeface.
All Google Fonts have been added as well as a small but growing list of other open source fonts. Open an issue if you want a font added!
Couldn’t be easier. This is how you’d add Open Sans.
npm install --save typeface-open-sans
Then in your app or site’s entry file.
And that’s it! You’re now self-hosting Open Sans!
It should take < 5 minutes to swap out Google Fonts.
Typeface assumes you’re using webpack with loaders setup for loading css and font files (you can use Typeface with other setups but webpack makes things really really simple). Assuming your webpack configuration is setup correctly you then just need to require the typeface in the entry file for your project.
If you’re not using webpack or equivalent tool that allows you to require css, then you’ll need to manually integrate the index.css and font files from the package into your build system.
This is an incredibly thorough guide to web font loading strategies, and their pros and cons.
If you’re looking for a specific approach, I’ve prepared some handy links that will take you to the section you need. Let’s say you want an approach that:
is the most well rounded approach that will be good enough for most use cases: FOUT with a Class.
is the easiest possible thing to implement: I’ve learned a lot about web fonts and at time of writing this article the current browser support is lacking for the easiest methods for effective/robust web font implementation. It is with that in mind that I will admit—if you’re looking for the easy way out already, you should consider not using web fonts. If you don’t know what web fonts are doing to improve your design, they may not be right for you. Don’t get me wrong, web fonts are great. But educate yourself on the benefit first. (In Defense of Web Fonts, The Value of a Web Font by Robin Rendle is a good start. If you have others, please leave a comment below!)
is the best performance-oriented approach: Use one of the Critical FOFT approaches. Personally, at time of writing my preference is Critical FOFT with Data URI but will shift toward Critical FOFT with
preloadas browser support for
will work well with a large number of web fonts: If you’re web font obsessed (anything more than 4 or 5 web fonts or a total file size of more than 100KB) this one is kind of tricky. I’d first recommend trying to pare your web font usage down, but if that isn’t possible stick with a standard FOFT, or FOUT with Two Stage Render approach. Use separate FOFT approaches for each typeface (grouping of Roman, Bold, Italic, et cetera).
will work with my existing cloud/web font hosting solution: FOFT approaches generally require self hosting, so stick with the tried and true FOUT with a Class approach.
This is an incredibly exhaustive list of performance tweaks, improvements, and best practices. Some may be outside the scope of smaller websites, but there are plenty of things for everyone.
Back in the day, performance was often a mere afterthought. Often deferred till the very end of the project, it would boil down to minification, concatenation, asset optimization and potentially a few fine adjustments on the server’s
configfile. Looking back now, things seem to have changed quite significantly.
Performance isn’t just a technical concern: It matters, and when baking it into the workflow, design decisions have to be informed by their performance implications. Performance has to be measured, monitored and refined continually, and the growing complexity of the web poses new challenges that make it hard to keep track of metrics, because metrics will vary significantly depending on the device, browser, protocol, network type and latency (CDNs, ISPs, caches, proxies, firewalls, load balancers and servers all play a role in performance).
So, if we created an overview of all the things we have to keep in mind when improving performance — from the very start of the process until the final release of the website — what would that list look like? Below you’ll find a (hopefully unbiased and objective) front-end performance checklist for 2017 — an overview of the issues you might need to consider to ensure that your response times are fast and your website smooth.
When text is rendered by a computer, sometimes characters are displayed as “tofu”. They are little boxes to indicate your device doesn’t have a font to display the text.
Google has been developing a font family called Noto, which aims to support all languages with a harmonious look and feel. Noto is Google’s answer to tofu. The name noto is to convey the idea that Google’s goal is to see “no more tofu”. Noto has multiple styles and weights, and is freely available to all.
font-displayproperty is landing in browsers, and this is a great introduction to using it:
If you don’t know which option to use, then go with
×character in most common fonts which you should use instead of an
xfor close, but getting it to look right across devices requires an eye for the detail.
Here’s a screenshot of the simulator vs. the real device, with exactly the same CSS applied to create the effect. Notice that the vertical align is off?
It took me a while to work out what was different, but it’s the font. The font I’m using (if you’re on a Mac - as I was), is Helvetia Neue, but my Android doesn’t have that font, so it was falling back to the next default (possibly set as
sans-serif, which could be Open Sans, or it could be something else). In this case, the different font had a slightly different letter height, so it caused (obviously) as slightly different result.
The pro tip: make sure to use a common font, probably Arial (IHMO ideally a font that doesn’t need to be downloaded) for button icons.
Yes, I know this is obvious if you’re using an icon font…but maybe not immediately obvious if you’re re-using system fonts.