Re: Please review performance aspects of Incremental Font Transfer

Are there any other comments on IFT from Web Perf WG, or should we mark 
this review as closed?

  - https://github.com/w3c/IFT/issues/193

On 2024-08-06 19:28, Garret Rieger wrote:
>
> 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>
>     <mailto:yoav.weiss@shopify.com>
>     To:  Chris Lilley <chris@w3.org> <mailto: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
>
>
-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media