Efficient Web Type, c. 1556

When a developer I’m working with asks, “Why did you select that font,” they never seem to accept “Self-preservation,” as my answer. Type designer Pierre Haultin may have actually been able to get away with this claim.

Haultin lives and works in Paris during the mid-sixteenth century, designing type and printing books for a living. How the type he designs performs—how efficient the letterforms are spatially on the page—is more relevant to his personal safety, than it is to his contemporaries.

The punchcutter’s precedence

Haultin is a punchcutter. Though his craft has become significantly less common over the last few centuries, it is still relevant to the work of type designers, people who design fonts professionally, today.

Typefaces designed or revived more recently, ones you might be using on screens, probably began their life as a sketch on paper and were worked on digitally quite quickly.

A book typeface make by in the mid-1500s, however, would have started life in steel.

Haultin’s ability to print, publish, and design type in this manner affords him a more active role in what might now be called the design process; his skills enables him to explore issues of typographic efficiency through the design of type itself.

Centuries on, it’s not just printers, publishers, or type designers who are responsible for the performance of type and how it reaches readers. This group has expanded to include typographers working on the web.

You are a typographer

Whether you see yourself this way or not, you are in some sense a typographer. While type designer is the title given to the designers of typefaces themselves, typographers are the people who use them. Today, this means that designers, developers, writers, and anyone replying to Twitter mentions with this article relegated to the background, are setting type in ways that couldn’t have been anticipated back when it was being cut out of metal.

Whether you use the title graphic designer, front end developer, software engineer, or something else entirely, we still have a similar question as the 16th century punchcutters: “How might a text be received and read more efficiently?”

We can continue to suggest answers to this on the web through:

1. Practice, taking advantage of established approaches.
2. Prospects, looking to upcoming technologies.
3. Precedence, viewing the punchcutter’s process as precedence for designer’s role in web performance.

Haultin’s challenges

Depending on how long you’ve been working with fonts on the web, these may not sound like new challenges to you. Well, relatively speaking, Haultin’s challenges are even older; he’s working on the bible.

Historically, religion has driven lettering, type design, and a great deal of communication in general. The first mechanical, movable type printing press was invented by Johannes Gutenberg 100 years before Haultin is working. As the iconic 42-line bible is printed, it becomes the fastest book ever produced.

So, what could possibly make printing the bible a worthy design challenge for a designer as experience as Haultin, an entire century later?

Certainly, he knows how to create effective work; this is not where his problem lays. His ability to print, publish, and design type means he’s more than capable of producing a new version of this work.

Printer, publisher, punchcutter…

No. Haultin’s requirements come from a secret he is keeping: in addition to being a printer, publisher, and a proficient punchcutter, he is also a Protestant.

Protestantism is essentially a forbidden branch of Christianity in Paris during the mid-16th century. Its members are known as Huguenots, though Haultin has managed to keep his own beliefs a secret up until this point, largely for his own safety.

Through improvements in printing technology, and secret promotional efforts of people including Haultin, Catholics in Paris are increasingly converting to Protestantism. This does not sit well with the most powerful Catholics in the country. Protestantism is repressed in Paris, and this steadily worsens under the recently-crowned King Henry II. I’m sure there are plenty of people on either side of this conflict who could be blamed—Haultin’s hardly a guiltless figure—but still, it’s hard not to see the king, as the person in power, as the villain here.

He gets a lance through the face in about three years from now if that makes you feel any better.

In the meantime, though, this is the position Haultin finds himself in: with a desire to practice his faith, but he’s facing death in doing so.

Haultin builds tools

Like many designers and developers today, Haultin builds his own tools to solve his own problems. As the religious climate in Paris worsens for Protestants, so do Haultin’s concerns with the design of the bible itself.

I became interested in his story through the books The Palaeotypography of the French Renaissance by Hendrik DL Vervliet and Counterpunch by Fred Smeijers. In the latter, Smeijers speculates what’s going through Haultin’s mind at this trying time in his life—but I prefer to think that he would have asked god more directly:

Blasphemous web type

Thinking about this—or through divine intervention, depending on your perspective—leads Haultin to help design the first, French-language pocket bible. A significant constraint is how small the type can be while remaining easy and desirable to read; it’s spatially efficiency on the page, determines how physically small this bible can be.

A typeface that reads well at extremely small sizes means a more economical number of characters per line, and less pages to print.

Haultin is actually technically skilled enough to cut a font that is so tiny, that the text is impractically small to read. Working towards a solution by experimenting with extremes is an approach still common when designing type today:

Of course, Haultin’s tools are very different from the technology type designers have access to today. Different sizes of type are physically different objects, and making sweeping changes would be challenging and impractical. By testing his design decisions along the way—holding his in-progress punches over an open flame, covering them in soot, and then making a mark on parchment—Haultin eventually finds the spatial sweet spot for his book typeface. He work goes onto help print a gorgeously inconspicuous bible.

Haultin’s performance issues in type design mirror our performance issues on the web: “How might a text be received, and read, more efficiently?”

He suggests answers to this this through the design of type itself, but that’s not the only place where this question needs an answer; we’re still facing the same question of typography efficiency today—but much more often it occurs on the web, and less so in the bible.

Existent web type

However you may referencing fonts on the web—manually hosting and writing your own @font-face declarations in CSS, or using one a service like Typotheque, Typekit, Fonts.com, Webtype, Cloud.typography, or Google Fonts—it’s clear you are referencing more fonts.

The adoption of @font-face and WOFF—the Web Open Font Format—has been rapid. It’s a metadata wrapper around a compressed OpenType font, likely the same file format fonts on your system will be using. These services also make it less likely that you’re writing @font-face declarations manually, so it’s worth reviewing how it works together with WOFF. In your CSS:

@font-face {
  font-family: "Implicate";          /* Specify the family name */
  font-style: normal;                /* Specify normal or italic */
  font-weight: 300;                  /* Specify a font weight */
  src: url("implicate-light.woff")
       format("woff");               /* Reference the file and format */
}

Then, you can actually reference the font in your CSS, using the font-family, font-weight, and font-style you specified:

h1 {
  font-family: "Implicate";
  font-weight: 300;
}

In 2009, the WOFF format’s biggest challenge was adoption; its goal was to firmly establishing a true way to use fonts on the web. Thanks to the hard work of the Web Fonts Working Group and many others, that has certainly happened,

based on the data from HTTP Archive showing a huge increase in web font usage from 1% in the end of 2010 to 50% across all sites in the beginning of 2015

WOFF’s poster child

Open Sans, a typeface released in 2011, is now more common on top Alexa sites than Lucida Grande, a commonly sanctioned, web-safe font.

Here are some things that happen less often per week, than number of times Open Sans is served:

• 350,000,000 – Estimated Facebook photo uploads per day  ¹
• 12,500,000 – Approximate one-day streams of a top YouTube video, ex. Jimmy Kimmel’s Celebrities Read Mean Tweets
• 5,000,000 – Estimated Tweets per day  ²
• 2,450,000,000 – Average number of font views of Open Sans in one day  ³

Keep in mind I’m as much of statistician as I am a French religious historian, which is to say I only investigate it when it relates to typography. I guess the point I’m really trying to make is, well, chill out with the Open Sans.

And this: clearly we can call the adoption of real web fonts a success. But in addition, we’ve adopted some performance issues, too. We are building sites that request more fonts, from an 8kb average transfer size at the beginning of 2012 to a 59kb average two years later:

The request size of web fonts, and number of requests made, are both increasing as time goes on.

In performance’s name

To mitigate the file size of WOFF files, most @font-face generators and font services and subset fonts. Subsetting removes any characters that are deemed (or assumed) to be unnecessary, regardless of what the type designer originally intended.

While subsetting is often worthwhile, or even necessary, it also imposes many limitations that aren’t immediately obvious:

The difference between what you see on keyboard and what is available in font is often staggering.

Peters noted this during a critique of Adobe’s user interface for advanced typographic features; most designers aren’t aware of the full feature set available in well-designed fonts.

This is also a problem on the web. I maintain Normalize-OpenType.css, a stylesheet that—like its namesake Normalize.css—aims to provide sounds, CSS defaults across browsers, but specifically for advanced typographic features.

With Normalize-OpenType.css, old style numerals will be used in text settings, tabular numerals used within tables, and small caps will denote acronyms. The defaults that the OpenType Specification suggests, like enabling kerning and common ligatures, will also be normalised across browsers.

In practice, however, browser inconsistencies are not the first problem encountered. Often, those ligatures, alternate glyphs, and other versatile design considerations, are being subset out of the font file before you can ever use them with CSS.

This also interferes with multi-lingual fonts: aggressive subsetting cuts them down to only support certain languages by default. Even when they are available as separate fonts files, the performance concern remains; we aspire to reduce page weight, while simultaneously expecting more than ever of type on the web.

Familiar performance problems

When reviewing a web performance dilemmas like this, it’s common to explore the immediate context exclusively. Yet, many people have been working on similar challenges for a long time—and many of those people were actually designers.

In the mid-16th century, Haultin tackled inefficiency within his space-saving, workhorse typefaces themselves, but our current technology renders the same approach less impactful. This discovery was shared by Matthew Carter. He is a highly respected type designer, particularly well-known for making both Georgia and Verdana. When he spoke in Vancouver, he mentioned the need for efficient type in the mid-1980s: how might we use serif fonts, which required significantly data, on a machine where memory was limited?

I made a serif type, you can see it on the right, without curved serifs. I made them polygonal, out of straight line segments, chamfered brackets. And look, as economical in data as a sans serif.

With this constraint guiding the design of the type, Carter reduced the number of vector points necessary, solving the problem through the design of the type itself. The result is Charter.

So I went to the head of engineering with my numbers, and I said proudly, “I have solved your problem.”

“Oh,” he said. “What problem?”

And I said, “Well, you know, the problem of the huge data you require for serif fonts and so on.”

“Oh,” he said. “We solved that problem last week. We wrote a compaction routine that reduces the size of all fonts by an order of magnitude. You can have as many fonts on your system as you like.”

“Well, thank you for letting me know,” I said.

Foiled again. I was left with a design solution for a nonexistent technical problem.

The engineers managed to compress every font on the system. Oh.

Carter’s constraint leads to an amazing result typographically, but as he notes, this does not end up being the problem-solving approach anticipated.

This remains true on the web: the designer has a role in web performance, but solving performance inefficiencies within a single typeface—as Haultin did, as Matthew Carter pursued for other ends—no longer has the same impact. The intervention must come from the system, not within the implementation of an individual font.

Being impactful

The adoption of WOFF means the Web Fonts Working Group were able to turn their attention to refining the existing implementation. The result of their work is the aptly named WOFF2.

From a technical perspective, it sounds a little too good to be true: what if you could continue use the same interface for loading fonts you’re already familiar with—@font-face or a font service—but soon you could the fonts requested to be significantly smaller in file size?

Brotli Compression

This is possible largely because of the Brotli compression applied to WOFF2 files. Brotil is a generic-purpose lossless compression algorithm that uses a bunch of compression techniques I will never understand in my lifetime. It makes some tradeoffs in the speed it compresses at, in favour denser compression, even on mobile devices. This is completely appropriate for the WOFF2 format.

The tests

While testing this, the Web Fonts Working Group ran various font catalogues through this new algorithm. They found⁴ a:

• 14% average compression improvement with Typekit’s .ttf catalogue
• 27% average compression improvement with the remainder of Typekit’s catalogue
• 25% average compression improvement with the Fonts.com catalogue
• 60% improvement as the best observed compression for a non-latin typeface

A familiar interface

One of the best things about WOFF2 is really one of the best things about @font-face. The @font-face specification cleverly anticipated the need for supporting multiple formats simultaneously, so even though WOFF2 is new, there are no changes to the syntax within CSS itself:

@font-face {
  font-family: "Implicate";
  font-style: normal;
  font-weight: 300;
  src: url("implicate-light.woff") format("woff");
}

You may have seen this feature of @font-face used to provide fallback fonts to older browsers and devices:

@font-face {
  font-family: "Implicate";
  font-style: normal;
  font-weight: 300;
  src: url("implicate-light.eot")  format("embedded-opentype"),
       url("implicate-light.woff") format("woff"),
       url("implicate-light.ttf")  format("truetype");
}

Here, we’re loading an Embedded OpenType font for Internet Explorer (ignoring some of the other tweaks it requires for the sake of simplicity). If the browser doesn’t support .eot, then the WOFF file will be used. If that is not supported either, the TTF file will be chosen.

In the exact same way we support fallback formats through @font-face, we can optimistically support forthcoming formats, too:

@font-face {
  font-family: "Implicate";
  font-style: normal;
  font-weight: 300;
  src: url("implicate-light.woff2") format("woff2"),
       url("implicate-light.woff")  format("woff");
}

Here, if the browser supports WOFF2, the .woff2 file will be requested. If not, the browser moves onto the next item, falling back to the original flavour of .woff instead.

Trying .woff2 today

If you are using a service to provide your fonts, a file with similar @font-face declarations is being generated for you. When you drop in the JavaScript snipped or the CSS link tag your service provides, that’s what you are requesting.

<link href="https://typefound.ry/css?family=Klinic+Slab" rel="stylesheet">

It also means that you may already be using WOFF2 and not realise it.

Google Fonts have been serving WOFF2 files for their Early Access fonts since 2014, and have since made it available for all fonts. If you are using Google Fonts, you are already serving WOFF2 files.

If you wanted to use Open Sans Hebrew from Google Fonts, you have the option of loading the font with a JavaScript snippet the Google Fonts website provides, like this:

<script type="text/javascript">
  WebFontConfig = {
    custom: { families: ['Open Sans Hebrew'],
      urls: ['http://fonts.googleapis.com/earlyaccess/OpenSansHebrew.css']
    }
  };
  (function() {
    var wf = document.createElement('script');
    wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
      '://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
    wf.type = 'text/javascript';
    wf.async = 'true';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(wf, s);
  })(); </script>

You may notice the url is actually pointing to a CSS file. When we take a look at what that CSS file contains, it’s just the @font-face declarations you’re now familiar with:

/* OpenSansHebrew.css */

@font-face {
  font-family: "Open Sans Hebrew";
  font-style: normal;
  font-weight: 400;
  src: url("OpenSansHebrew-Regular.woff2") format("woff2"),
       url("OpenSansHebrew-Regular.woff")  format("woff");
}

…and they include WOFF2 files. Hopefully other web font services will follow suit soon. Typekit hasn’t announced a timeline for adding WOFF2 support, but it appears as though it will arrive soon.

Self-hosting

If you are self hosting your fonts or just want to experiment, it’s possible to generate WOFF2 files locally as well. The most up-to-date way is to use Google’s implementation of WOFF2 locally:

$ git clone https://github.com/google/woff2
$ cd woff2
$ make
# Convert your-font.ttf to your-font.woff2…
$ ./woff_compress path/to/your-font.ttf

Running these commands in your terminal will build the library and allow you to convert TTF into WOFF2.

Alternatively, you can use sites like Font Squirrel or Everything Fonts which will convert back and forth between WOFF and many other formats. Type design programs like Glyphs even allow type designers to export WOFF2 files directly now.

If you are self-hosting fonts, it’s important to check and see what your license allows. Most foundries or distributors are usually run by fairly small, personable teams. Getting in touch with them directly, and asking them when they will be distributing WOFF2 files, is a great excuse to say how much you appreciate their work, and also encourage a performance improvement for everyone using their fonts.

Browser support

The only negative part of WOFF2 is its browser support, which is still quite good:

• Chrome 36 & Opera 23 (Released July 2014) ^{5  6}
• Android Browser 37
• Firefox 39 (Released June 2015)  ⁷
• IE’s implementation is marked “Under Consideration”  ⁸

Unsurprisingly, Safari is absent from this list, without even an intent to implement. (Safari doesn’t properly support the advanced typographic features I mentioned earlier, either; a small selection of them are enabled by default, but the font-feature-settings property is not supported.)

WOFF2 is an opportunity

With Firefox’s recent addition to the list of browsers supporting WOFF2, and a built-in way to fallback to WOFF, it is certainly worth using now. Hopefully browsers, type foundries, and web font services will increasingly make WOFF2 support easier on developers.

This might make it seem like the performance of web fonts is purely an engineering challenge; As Matthew Carter described, software engineers are capable of creating massive performance improvements within systems, often making specific, one-off improvements seem ineffective. I see WOFF2 as an opportunity to reconsider what’s really important about loading fonts. With WOFF2 files dramatically smaller, there is a chance for designers and front-end developers to turn focus more on perceived performance, and other client-side optimisations, instead:

1. Why you should load fonts with JavaScript
2. Making Sensible request
3. Not loading fonts
4. Font stacks still matter

Load fonts with JavaScript

When loading fonts, we have the opportunity to use CSS alone, or to use JavaScript and CSS together. Conventional web development wisdom often suggests that we should only turn JavaScript when we need to. In this situation, JavaScript is necessary to influence how readers perception of how quickly the fonts have loaded, based on the state they are.

A CSS-only approach, recommended by default on Google Fonts and some other services, would have you drop in a <link> tag or use a CSS @import statement:

<link href="http://typefound.ry/css?family=Klinic+Slab" rel="stylesheet">

@import url(http://typefound.ry/css?family=Klinic+Slab);

Despite this, choose the JavaScript-based option. If you are using a web font service that asks you to drop in a CSS link tag, there is probably an “Advanced Option,” too, that lets you paste in a JavaScript snippet. The later is going to be more beneficial to you.

Typekit is similar:

Sensible requests

Both Google Fonts’ and Typekit’s advanced snippet, along with many other web font service snippets, are actually using the typekit/webfontloader, maintained by the amazing Bram Stein. It is also available for to use directly.

One reason you might do this is to mix web fonts from different services. The WebFontLoader can take care of this for you, without the need to include nearly identical JavaScript snippets from multiple services. You’d never want to load this many fonts at once, but to make a point about what the WebFontLoader can do, let’s load:

• Ross Milne’s Charlie & Echo, served by Typotheque
• Nadine Chahine’s Frutiger Arabic, served by Fonts.com
• Alisa Nowak’s Eskapade from TypeTogether, served by Typekit
• James T. Edmondson’s Lavanderia from Lost Type, self-hosted
• Yanek Iontef’s Open Sans Hebrew served by Google Fonts

This translates to the following WebFontLoader configuration:

WebFont.load({
  google: { families: ['Open Sans Hebrew'] },
  typekit: { kitId: 'okd4rym' },
  monotype: { projectId: '4351838b…' },
  custom: { families: ['Lavanderia:n3,n4,n6'] }
  custom: { families: ['Echo'],
   urls: ['//wf.typotheque.com/WF-n3wst47-o4n9y']
  }
});

Without the WebFontLoader, each of those services would have asked you to drop in a JavaScript snippet, which would have brought in slightly different versions of the WebFontLoader, anyway.

Of course, you’re unlikely to want to load that many web fonts on a page, at one time. The WebFontLoader gives you the control to take care of this problem too. If Echo is the project’s primary typeface, you could load that first. Then, use the WebFontLoader again to defer the other fonts, based on a different condition:

WebFont.load({
 custom: { families: ['Echo'],
   urls: ['//wf.typotheque.com/WF-n3wst47-o4n9y']
  }
});

// Later or conditionally…

WebFont.load({
  google: { families: ['Open Sans Hebrew'] },
  typekit: { kitId: 'okd4rym' },
  monotype: { projectId: '4351838b…' },
  custom: { families: ['Lavanderia:n3,n4,n6'] }
});

The WebFontLoader can also be loaded asynchronously, this is a script similar to what most web font service providers will give you as a JavaScript-based option:

<script>
  WebFontConfig = {
    typekit: { id: 'okd4rym' }
  };
  (function() {
    var wf = document.createElement('script');
    wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
              '://ajax.googleapis.com/ajax/libs/webfont/1.5.18/webfont.js';
    wf.type = 'text/javascript';
    wf.async = 'true';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(wf, s);
  })();
</script>

Alternatively, you can use the async attribute instead:

<script>
  WebFontConfig = {
    typekit: { id: 'okd4rym' }
  };
</script>
<script async defer src="//ajax.googleapis.com/ajax/libs/webfont/1.5.18/webfont.js">
</script>

The WebFontLoader provides more convenience, with shortcuts for loading fonts from Google Fonts, Fonts.com, Typekit, and Fontdeck. It also automatically applies .wf-loading, .wf-active, and .wf-inactive classes depending on the state of your web fonts.

An lighter-weight alternative to the WebFontLoader is Font Face Observer, also developed by Bram Stein. It is significantly smaller in file size, and leaves it open to you to take care of adding classes, or taking any other actions, based on the state of your fonts. If you need more control, it is a great option. Scott Jehl has written about how Filament Group uses Font Face Observer to

specify a font family and other identifying details such as the font’s weight and style. Once the observer is created, you just need to check() it, and then get a callback when it finishes loading (which is easy to do through the then() method).

JavaScript-based web font loading libraries are really a way to interact with the CSS Font Loading API (@font-face declarations) within JavaScript. True JavaScript font loading events will be supported in browsers soon, and Font Face Observer and the WebFontLoader will become polyfills for them. They will remain relevant for the foreseeable future.

Not loading fonts

Now that the WebFontLoader or Font Face Observer is loading fonts asynchronously, visible content may load before your fonts. This is an opportunity for a Flash of Unstyled Text—and yes, it’s an opportunity. As Tim Brown of Typekit points out, our view of typography should still be,

centered on the principle of progressive enhancement—that a text itself is fundamentally more important than our suggestions about how it should be typeset.

When truly designing for readers, we recognise the type is there to serve the text, the words written. It’s tough for a typographer like me to admit it, but on the web we have to prioritise the text, and the font, independently.

FOUT is a feature and a condition everyone should anticipate and design for.

The Flash of Unstyled Text was often presented as a negative, as WOFF and @font-face first came into use; developers and designers (myself included) are finally coming around to the idea that it is a feature. Asynchronously loading fonts improves the perceived performance by showing the text almost as soon as it’s available, even in situations where the correct fonts haven’t loaded yet.

When a browser is waiting for a font that didn’t load quickly—perhaps you are reading the page offline, or the connection is poor—it will usually give up after 3000ms. The Firefox team smartly built this in from the beginning, but it was only mirrored in Chrome more recently. Safari and IE don’t have a timeout at all. If your readers lose their connection before receiving your web fonts, they could potentially wait a very long time to see your text if something goes wrong (and we know it’s unlikely they will).

Luckily, the WebFontLoader and Font Face Observer allow you to specify you own timeout value:

<script>
  WebFontConfig = {
    typekit: { id: 'okd4rym' },
    timeout: 3000
  };
</script>
<script async defer src="//ajax.googleapis.com/ajax/libs/webfont/1.5.18/webfont.js">
</script>

I would even recommend lowering it:

timeout: 1500

Now, you can bail out of showing the fonts if they haven’t loaded in the first 1.5 seconds. This can dramatically improve perceived performance, and is why…

Font stacks still matter

When I see a font stack like this:

body {
  font-family: "Soleil", sans-serif;
}

…I feel just got a lance through the face.

I’m not even sure if two items counts as a stack, anyway. It’s frustrating because, like @font-face, font-family is a CSS property where graceful degradation was always built-in, but it seems to be used less often than ever.

Perhaps this is because almost every web font service makes this same, incomplete recommendation:

Something more appropriate might look like this:

body {
  font-family: "Soleil", "Avenir Next",
               "AvenirNext-SemiBold",
               "Futura-Medium", Futura,
               "Futura Std", "Droid Sans",
               "Trebuchet MS", Helvetica,
                Arial, sans-serif;
}

As long as you leave defining fallback fonts until later in your design process, after other typographic decisions have been established, I think it can actually be fun to work within this weird set of constraints.

Additionally, you now have a font stack ready for any email newsletters you might need to send using the same visual identity in the future. Web fonts have slowly become a viable option in email newsletters, but it’s even less likely web fonts will be supported there. By saving your font stack to a variable in your preprocessor, you can share this work across projects:

$font-heading: "Soleil", "Avenir Next",
               "AvenirNext-SemiBold",
               "Futura-Medium", Futura,
               "Futura Std", "Droid Sans",
               "Trebuchet MS", Helvetica,
                Arial, sans-serif;

Solace in precedence

Haultin’s endeavours to improve spatial efficiency enabled more contextually appropriate communication. Though the issues driving our optimisations are not always as dire, it’s clear there’s a need and a precedence for designers improving performance problems.

By looking ahead to new technologies—WOFF2 and the inherit performance improvements it will bring—and taking it as an opportunity to re-commit to other best practices in the meantime, we can make our own suggestions at how text might be read and received more efficiently. There’s precedence for designers’ role in the performance of type on the web.

Too often, the way we view and present our work, it can be easy to get caught up—that what we’re designing and developing is entirely new—and I’m as guilty of that as as anyone. But to me, there’s something more wonderful about being reminded we’re far from the first to try and intervene, to improve the effectiveness of our communication: whether you’re working on cutting the smallest, readable, metal type, or trying to make fonts feel like they’ve loaded faster.

Thanks.