DragonI

In CSS: use pixels, not em

Precision over elegance

jgthms.com

Why you should use px, not em

Using em is a very elegant way to define both your text size and your layout. It keeps every element balanced and easily sizable. I’veused it before. It’s a pain.

Fonts need precision to look sharp

Let’s say your default font-size is set to 16px. You have titles at 2remand subtitles at 1.5rem. Fabulous! Your semantic hierarchy matches your visual one. If you were to change your default text size to 15px, you’d maintain that hierarchy.

But not all font sizes are equal… Considering the text of this website:

Every font needs its own specific size

Another problem with em arises when you want to change the font family, because every font renders differently at each size:

Just use pixels

If you want sharp precise interfaces, stick to px:

• you’ll avoid any cumbersome calculations that involve 4 decimals
• just by looking at a CSS rule, you’ll know exactly how it will look like because there’s no dependency
• preprocessors like Sass allow easy maintenance anyway: you can have global variables for sizes, or use mixins to define variations for your elements
• you’ll be able to align different types of elements that each require their own font-size

Web Fonts Performance

Web fonts are great. They are also be really bad for front-end performance because they block rendering. You may have experienced this on a slow cellular network. Staring at a blank page is no fun, especially when the content has already loaded. This talk explores why browser have placed fonts on the critical path, and how we can work around this while still delivering a good user experience. It also takes a look at what the future will bring to web font performance: preloading hints, the font-display property, and HTTP/2.

speakerdeck.com|https://www.facebook.com/GitHub

• FOUT, FOIT, FOFT
• Case Study: Analyzing Web Font Performance
• Webfont Performance, FOUT, Foit and Usability
• Webfont optimization
• Font Loading Revisited with Font Events

• Filament GrouploadCSS 
• TypeKit Web Font Loader

Optimizing Web Font Rendering Performance - igvita.com

www.igvita.com

A hands-on look at how to measure web font latencies and optimize their use: transfer latencies, time of initial fetch, and interaction with the critical rendering path.

Finally, we come to the most exciting part of this entire story: Font Load Events API. In a nutshell, this API will allow us to manage and define how and when the fonts are loaded – we can schedule font downloads at will, we can specify how and when the font will be rendered, and more. If you're familiar with the Web Font Loader JS library, then think of this API as that and more but implemented natively in the browser:

var font = new FontFace("FontA", "url(http://mysite.com/fonts/fontA.woff)", {}); font.ready().then(function() { // font loaded.. swap in the text / define own behavior. }); font.load(); // initiate immediate fetch / don't block on render tree!

Web fonts offer a lot of benefits: improved readability, accessibility (searchable, selectable, zoomable), branding, and when done well, beautiful results. It's not a question of if web fonts should be used, but how to optimize their use. To that end, a quick performance checklist:

1. Audit your font usage and keep it lean.
2. Make sure font resources are optimized - see Google Web Fonts tricks.
3. Instrument your font resources with Resource Timing: measure → optimize.
4. Optimize the transfer latency and time of initial fetch for each font.
5. Optimize your critical rendering path, eliminate unnecessary JS, etc.
6. Spend some time playing with the Font Load Events API.