Tags: webfonts

Bunny Fonts | Explore Faster & GDPR friendly Fonts

A drop-in replacement for Google Fonts without the tracking …but really, you should be self-hosting your font files.

[css-fonts-5] @font-face supports incremental · Issue #6063 · w3c/csswg-drafts

This could give a big boost to web performance!

System fonts don’t have to be ugly /// Iain Bean

You don’t have to use web fonts—there are some pretty nice options if you stick to system fonts (like Georgia, Charter, and Palatino).

How to avoid layout shifts caused by web fonts – Simon Hearne

A terrific in-depth look at improving the performance of web fonts.

Private by Default

Feedbin has removed third-party iframes and JavaScript (oEmbed provides a nice alternative), as well as stripping out Google Analytics, and even web fonts that aren’t self-hosted. This is excellent!

Danielle and I have been doing some front-end consultancy for a local client recently.

We’ve both been enjoying it a lot—it’s exhausting but rewarding work. So if you’d like us to come in and spend a few days with your company’s dev team, please get in touch.

I’ve certainly enjoyed the opportunity to watch Danielle in action, leading a workshop on refactoring React components in a pattern library. She’s incredibly knowledgable in that area.

I’m clueless when it comes to React, but I really enjoy getting down to the nitty-gritty of browser features—HTML, CSS, and JavaScript APIs. Our skillsets complement one another nicely.

This recent work was what prompted my thoughts around the principles of robustness and least power. We spent a day evaluating a continuum of related front-end concerns: semantics, accessibility, performance, and SEO.

When it came to performance, a lot of the work was around figuring out the most suitable metric to prioritise:

• time to first byte,
• time to first render,
• time to first meaningful paint, or
• time to first meaningful interaction.

And that doesn’t even cover the more easily-measurable numbers like:

• overall file size,
• number of requests, or
• pagespeed insights score.

One outcome was to realise that there’s a tendency (in performance, accessibility, or SEO) to focus on what’s easily measureable, not because it’s necessarily what matters, but precisely because it is easy to measure.

Then we got down to some nuts’n’bolts technology decisions. I took a step back and looked at the state of performance across the web. I thought it would be fun to rank the most troublesome technologies in order of tricksiness. I came up with a top four list.

Here we go, counting down from four to the number one spot…

4. Web fonts

Coming in at number four, it’s web fonts. Sometimes it’s the combined weight of multiple font files that’s the problem, but more often that not, it’s the perceived performance that suffers (mostly because of when the web fonts appear).

Fortunately there’s a straightforward question to ask in this situation: WWZD—What Would Zach Do?

3. Images

At the number three spot, it’s images. There are more of them and they just seem to be getting bigger all the time. And yet, we have more tools at our disposal than ever—better file formats, and excellent browser support for responsive images. Heck, we’re even getting the ability to lazy load images in HTML now.

So, as with web fonts, it feels like the impact of images on performance can be handled, as long as you give them some time and attention.

2. Our JavaScript

Just missing out on making the top spot is the JavaScript that we send down the pipe to our long-suffering users. There’s nothing wrong with the code itself—I’m sure it’s very good. There’s just too damn much of it. And that’s a real performance bottleneck, especially on mobile.

So stop sending so much JavaScript—a solution as simple as Monty Python’s instructions for playing the flute.

1. Other people’s JavaScript

At number one with a bullet, it’s all the crap that someone else tells us to put on our websites. Analytics. Ads. Trackers. Beacons. “It’s just one little script”, they say. And then that one little script calls in another, and another, and another.

It’s so disheartening when you’ve devoted your time and energy into your web font loading strategy, and optimising your images, and unbundling your JavaScript …only to have someone else’s JavaScript just shit all over your nice performance budget.

Here’s the really annoying thing: when I go to performance conferences, or participate in performance discussions, you know who’s nowhere to be found? The people making those third-party scripts.

The narrative around front-end performance is that it’s up to us developers to take responsibility for how our websites perform. But by far the biggest performance impact comes from third-party scripts.

There is a solution to this, but it’s not a technical one. We could refuse to add overweight (and in many cases, unethical) third-party scripts to the sites we build.

I have many, many issues with Google’s AMP project, but I completely acknowledge that it solves a political problem:

No external JavaScript is allowed in an AMP HTML document. This covers third-party libraries, advertising and tracking scripts. This is A-okay with me.

The reasons given for this ban are related to performance and I agree with them completely. Big bloated JavaScript libraries are one of the biggest performance killers on the web.

But how can we take that lesson from AMP and apply it to all our web pages? If we simply refuse to be the one to add those third-party scripts, we get fired, and somebody else comes in who is willing to poison web pages with third-party scripts. There’s nothing to stop companies doing that.

Unless…

Suppose we were to all make a pact that we would stand in solidarity with any of our fellow developers in that sort of situation. A sort of joining-together. A union, if you will.

There is power in a factory, power in the land, power in the hands of the worker, but it all amounts to nothing if together we don’t stand.

There is power in a union.

Transform your type online with variable fonts | Creative Bloq

This is a great interview with Rich on all things related to web typography—including, of course, variable fonts.

I’m so lucky that I literally get to work side by side with Rich; I get to geek out with him about font stuff all the time.

It’s Dangerous to Go Stallone. Take Glyphhanger | Filament Group, Inc., Boston, MA

You’ll need to be comfortable with using the command line, but this is a very useful font subsetting tool from those clever folks at Filament Group.

How to use variable fonts in the real world | Clagnut

The gorgeous website for this year’s Ampersand conference might well be one of the first commercial uses of variable fonts in the wild. Here, Richard documents all the clever things Mark did to ensure good fallbacks for browsers that don’t yet support variable fonts.

Ampersand Web Typography Conference | 29 June 2018 | Brighton, UK

Save the date! The best web typography conference in the world is back in Brighton on June 29th, and this time it’s at the best venue: The Duke Of York’s.

In fact, you can do more than saving the date: you can snap up a super early bird ticket for whopping £85 saving.

eBay’s Font Loading Strategy | eBay Tech Blog

Here’s the flow that eBay use for the font-loading. They’ve decided that on the very first page view, seeing a system font is an acceptable trade-off. I think that makes sense for their situation.

Interestingly, they set a flag for subsequent visits using localStorage rather than a cookie. I wonder why that is? For me, the ability to read cookies on the server as well as the client make them quite handy for situations like this.

User Interfaces for Variable Fonts · An A List Apart Article

A good introduction to variable fonts, and an exploration of the possible interface elements we might use to choose our settings: toggles? knobs? sliders? control pads?

If you really dislike FOUT, `font-display: optional` might be your jam | CSS-Tricks

Everyone’s been talking about font-display: swap as a way of taking the pain out of loading web fonts, but here Chris looks at font-display: optional and font-display: fallback as well.

Tentacular: Douglas Coupland on Helvetica, clip art and the gangly beast that is the internet

Douglas Coupland on web typography.

When I discuss the internet’s feel and its random rodeo of fonts, I think of the freedom, naivety, laziness, greed, cluelessness and skill I see there — it’s a cyberplace as wondrous as the bubbling cradle of pea-soup goo from which life emerged. The internet has a rawness, a Darwinian evolutionary texture. It’s a place where metrics totally unrelated to print typography dictate the look and feel.

Web fonts, boy, I don’t know – Monica Dinculescu

Monica takes a look at the options out there for loading web fonts and settles on a smart asynchronous lazy-loading approach.

The Typekit Blog | Variable fonts, a new kind of font for flexible design

This is what Nick Sherman has been banging on about for years, and now the time has come for variable fonts …as long as typographers, browser makers, and standards bodies get behind it.

More details on Ev’s blog.

Webfonts on the Prairie · An A List Apart Article

A good ol’ polemic in favour of using web fonts. It’s a good read although I strongly disagree with this line of reasoning:

The average internet speed in the United States today is three times as fast as it was in 2011.

But that americentric view is redeemed later on:

The World Wide Web may be a creation of the West, but now, at long last, it needs to get ready for the rest.

I may not agree with all the points in this article, but I think we can all agree that if we’re going to use web fonts, we must use them responsibly …otherwise users are going to treat them as damage and route around them.

`font-display` for the Masses | CSS-Tricks

The font-display property 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 swap. Not only does it provide an optimal balance between custom fonts and accessibility of content, it provides the same font loading behavior that we’ve relied on JavaScript for. If you have fonts on the page that you’d like to have load, but could ultimately do without, consider going with fallback or optional when using font-display.

Until it’s more widely supported, you can continue to use a JavaScript solution, but even then you can feature detect first:

if ("fontDisplay" in document.body.style === false) {
  /* JavaScript font loading logic goes here. */
}

A Comprehensive Guide to Font Loading Strategies—zachleat.com

A terrific rundown of all your options when it comes to web font loading.

ET Book · Edward Tufte on GitHub

I’ve always loved the way that Edward Tufte consistently uses Bembo to typeset his books. Here’s a version made for screen and freely licensed.