Re: Please review performance aspects of Incremental Font Transfer

Added some answers to Yoav's questions inline.

On Sat, Aug 3, 2024 at 4:16 PM Chris Lilley <chris@w3.org> wrote:

>
>
>
> -------- Forwarded Message --------
> Subject: Re: Please review performance aspects of Incremental Font
> Transfer
> Date: Fri, 2 Aug 2024 07:59:44 +0200
> From: Yoav Weiss <yoav.weiss@shopify.com> <yoav.weiss@shopify.com>
> To: Chris Lilley <chris@w3.org> <chris@w3.org>
> CC: public-web-perf@w3.org
>
> Thanks for sending this for review Chris! This is super interesting!!
>
> Looking at the explainer, I think it could benefit from some examples and
> flow diagrams in the part that touches on patch maps.
> Some questions that came to mind:
>
>    - Can font processors create any (reasonable) number of potential
>    patches for arbitrary codepoint ranges?
>
> Yes, it's left entirely up to the encoder to decide how to segment the
font (ie. how many patches and what codepoints are included in those
patches).


>
>    - How would the discovery process work? When would browsers load
>    patches?
>
> A couple places in the spec touch on this:

   - Overview <https://w3c.github.io/IFT/Overview.html#overview>
   - Opt-In Mechanism <https://w3c.github.io/IFT/Overview.html#opt-in>

At a very high level it works like this:
1. CSS declares a font face which uses the "tech(incremental)" keyword to
mark the font as utilizing incremental loading (allowing non-supporting
user agents to skip it).
2. The font face links to a font file which will be encoded as a ttf, otf,
or woff2 as usual.
3. The loaded font file will contain some initial glyphs plus a IFT table
which encodes a mapping from sets of codepoints to what patches to load.
4. When the user agent tries to render some content with that font it can
immediately use the initial glyph set and also use the codepoints in the
content to locate the relevant patches, load, and apply those to get data
for any glyphs which are needed but not in the initial font.


>
>    - Are there restrictions on cross-origin serving of the patches? If
>    not, is there a risk of privacy leaks? The spec's privacy section discusses
>    the risk, but doesn't mention mitigations AFAICT
>
>
Under this new approach the patch loads are just regular http loads and are
subject to all of the usual CORS restrictions. We touch on this in the Load
Patch File
<https://w3c.github.io/IFT/Overview.html#abstract-opdef-load-patch-file>
section
where it's specifically mentioned that the patch requests use fetch
<https://fetch.spec.whatwg.org/> and match the CORS loading settings of the
initial font file. Which implies that patch loads will follow CSS font
fetching requirements
<https://www.w3.org/TR/css-fonts-4/#font-fetching-requirements>.

>
>
>
> On Wed, Jul 24, 2024 at 3:27 PM Chris Lilley <chris@w3.org> wrote:
>
>> The Web Fonts WG requests review of the Incremental Font Transfer (IFT)
>> specification by the Web Performance WG. A new WD of IFT was published
>> on 9 July 2024 [1]
>>
>> This specification defines a way to incrementally transfer fonts from
>> server to client. Incremental transfer allows clients to load only the
>> portions of the font they actually need which speeds up font loads and
>> reduces data transfer needed to load the fonts. A font can be loaded
>> over multiple requests where each request incrementally adds additional
>> data.
>>
>> Earlier work [2] demonstrated the performance improvements in terms of
>> bytes transferred and reduced network delay, for various network types.
>>
>> The current draft (unlike earlier drafts) does not require a dynamic web
>> server to compute patches. Instead, a table of URLs to the pre-computed
>> patches is contained within the subsetted font itself. This means that
>> patches are applicable to multiple users, and are cacheable.
>>
>> Also (unlike earlier drafts, which used a custom patch request protocol)
>> the patches are requested with a regular HTTP GET.
>>
>> We have an Explainer [3].
>>
>> We would particularly value the review of the Web Performance WG on
>> those aspects, although review of the entire specification would of
>> course be most welcome.
>>
>> Comments should be raised as individual issues on our GitHub [4].
>>
>> [1] https://www.w3.org/TR/2024/WD-IFT-20240709/
>> [2] https://www.w3.org/TR/PFE-evaluation/
>> [3] https://github.com/w3c/IFT/blob/main/IFT-Explainer.md
>> [4] https://github.com/w3c/IFT
>>
>> --
>> Chris Lilley
>> @svgeesus
>> Technical Director @ W3C
>> W3C Strategy Team, Core Web Design
>> W3C Architecture & Technology Team, Core Web & Media
>>
>>
>>