|
I was recently extended the honor of participating in the W3C Web Fonts Working Group as an Invited Expert. The group was previously responsible for bringing us the WOFF and WOFF2 font format standards, and has had its charter extended to work on something new: taking on the performance problem of font downloads. This is a really important challenge to resolve, especially with regard to the emergence of variable fonts. I’ll explain where we’re headed in a moment, but first a bit a bit of history.
Boon & bottleneck
Download performance has always been a barrier to adoption—or at least a bone of contention—with regard to using web fonts on Western-language websites, even with font file sizes of 20-50k. Arabic and some Asian sites have often had to forgo using web fonts entirely as the files could be 2.5MB for an Arabic font, to as much as 16MB or more for a typical Chinese/ Japanese/ Korean (or CJK) one due to the complexity and number of glyphs in the character sets.
For a number of years Monotype, Adobe, and Google have had the capability to dynamically subset font files on a per-page basis. This allows them to serve font files with only the glyphs necessary to render a given page. Unfortunately, due to some technical limitations, these solutions were only ever employed for CJK and some other non-Western fonts. Google has experimented with other solutions as well, including allowing font requests to include subset ranges—but they have their own challenges of range sizes and losing OpenType features across subsets.
Setting the stage
Last year TYPO Labs in Berlin hosted a W3C CSS Working Group meeting where they discussed, among other things, the emerging standards and specs for supporting variable fonts. Along the way there was discussion of Adobe, Apple, Google, Monotype, and Mozilla collaborating with the W3C to develop a better, more universal solution for serving web fonts—particularly very large ones—that would work better and in a more sustainable and reusable way. A number of other type foundries and software vendors are contributing as well—it’s truly an industry-wide collaboration.
A simplistic description would be something like ‘font streaming’ but in truth that wouldn’t actually solve the problem: users would still be constantly downloading entire font files even if they only needed a small portion to render the one or two pages they might view on a given site. The problem with existing subsetting solutions is that either the subset is thrown away with each page view or the solution requires a proprietary server resource, thereby greatly reducing the usefulness of the subset while increasing the complexity and resource requirements on the server.
The ideal solution would combine the benefits of both of these approaches: subset a font request to what’s necessary for a given page, but add to the original font asset on subsequent content requests, thereby enabling the gradual enrichment of the font file. Adobe has been doing something like this for a while with their own custom implementation, which shows it’s possible to preserve the enriched font’s cacheability and greatly enhances the viability of using web fonts with very large character sets like Arabic and CJK.
So that’s what we’re trying to do.
(And to be fair, when I say ‘we’ I really mean all the amazingly smart engineers involved from all the participating organizations)
It’s all in the name
The concept we’re trying to bring to life has been dubbed ‘progressive font enrichment’—so it’s clear that there are no marketing folk on the working group 🙂 But it does accurately describe what we feel the solution should accomplish: to enable the ability for only the required part of the font be downloaded on any given page, and for subsequent requests for that font to dynamically ‘patch’ the original download with additional sets of glyphs as required on successive page views—even if they occur on separate sites.
While there are still a number of ideas being investigated, the team at Google have created a proof of concept that illustrates the concept and potential quite well. As a group we’ve been adding details and suggestions, and this will likely continue to evolve—but since it has come up at a few events over the past weeks, we felt this was a good time to provide a bit more context along with a link to the demo itself.
The concept, proven
The Google Fonts team put the demo online here, and it is publicly available. There are a bunch of options being evaluated and researched, so I thought it would be good to annotate the interface a little bit so you can see what we’re hoping it will accomplish.
Below you can see the interface as you’ll likely find it (at least how it looks today, on 24 April, 2019). There is a brief explanation, some options to configure, a place to supply some text, and then the output showing how much font information is served and the rendered demo content.
Now we’ll step through the process.
|
