Skip

Demonstration of Incremental Font Transfer

Presenter: Garret Rieger
Duration: 5 min

An overview of the upcoming incremental font transfer technology. Plus a demonstration of incremental font transfer in use in a browser compared to existing font loading techniques.

All demos

Skip

Video

The web fonts working group, and I'm here to give you a demonstration of incremental font transfer.

So really quickly, before we start, what incremental font transfer is is it's a new technology that allows browsers to partially load fonts.

More specifically, it allows them to load part of a font, and then as more content is encountered, patch that font to extend it to cover the additional content.

So based on the specification work we've done so far we've built an actual in-browser demo of this.

So this has a real incremental transfer client running in JavaScript, talking to a real server that's producing the patches, and that's all happening in real time.

Okay then, in addition, this demo also in parallel will load the fonts using a more traditional approach where the fonts have been split up into one subset per script, and then the the script subsets that are specifically needed are loaded, and that's called the Unicode-range method.

Okay, so here we can go to the first bit of content.

So there's the content on the left and then behind the scenes, the client will have gone and loaded the data for the characters via incremental transfer, and then also loaded whatever fonts that would be needed via Unicode-range, and so we can see already that incremental font transferred has transferred less data than the Unicode-range which pulled down to full script subset.

So if we go to some additional content now there'll be some new characters in this that weren't on the previous page.

So incremental font transfer will have gone to the server and patched in the little bit of extra data that was needed, and so on, as we go through some additional content.

Now, things get kind of interesting when we go to a new script here.

So incremental font transfer was able to pull down just the data needed for the additional accented characters.

Whereas with Unicode-range, we had to pull in a whole new script subset, which almost doubled the amount of data that's transferred so far.

And similarly, with some Cyrillic text here, so we're able to pull in just some extra data for the Cyrillic characters that are currently displayed.

Whereas Unicode-range had to pull down an entire new Cyrillic subset.

Oh, one of the other interesting things that incremental font transfer enables, other than just increasing performance is that it allows all of the layout rules in the font, especially ones between script characters and different script subsets to work together.

So with Unicode-range, since we've split the font into multiple pieces, any layout rules that cross those script boundaries will no longer work.

And so if we look at the text as rendered by Unicode-range versus incremental font transfer, and if you look closely, for example, at these two characters at the end of the title, you'll notice that the kerning between the punctuation and the character changes with Unicode-range.

And that's because the kerning rule for the period, which is in the Latin subset, does not work with the Cyrillic characters, whereas with incremental transfer, it will.

Okay, so another interesting example is using this for loading Chinese fonts.

So as you can see, incremental font transfer loaded significantly less data than we needed to load with Unicode-range to display this text.

Then as we go through some more content, the gap between the two further increases.

So we've loaded a little over 10% of what Unicode-range had to load.

Okay, and lastly, another really interesting case which we think that incremental transfer could be quite useful for, is with emoji.

So emoji fonts have an extremely large set of emojis.

You typically only need a small set in any kind of given place.

So being able to load the data just for the emojis that you actually need, you can save significant amounts of bytes transferred.

This particularly is quite effective with things like the skin tone emojis, where you have many different variations on the same emoji.

So with the Unicode-range approach, you're forced to load them all, all the different variants all at the same time.

Whereas with incremental transfer, you can load just the ones that you need.

Okay, thank you.

That's the end of the demo.

Skip

All demos

Skip

Sponsors

Support TPAC 2022 and get great benefits from our Sponsorship packages.
For further details, contact sponsorship@w3.org

Many thanks for sponsoring TPAC:

Silver sponsors

Gooroomee Coil Technologies,

Bronze sponsor

Igalia

Media sponsor

Legible