Re: Please review HTTP performance aspects of Incremental Font Transfer

Hi Chris,

This is not the first time that I've seen this specification, but I've not commented before.

It seems fairly obvious (more so with the research referred to) that being able to obtain a subset of large fonts is good for performance.  So work in this area is appreciated.

However, there are a number of aspects of this design that are neither obvious nor explained.

The most obvious question is about why you would provide *two* mechanisms.  Nothing explores why you might prefer one over the other, at server or client.  It is simply taken for granted there there are two.  I don't know how a client might be expected to use this specification in a sensible fashion based on the information presented.  Nor how a server might choose to deploy one or the other.

There is a lot of text on a format for expressing subsets of fonts that I did not read, but the idea that you might just put those in a query parameter on any font request is ... (I'm struggling to find the right word here) ...irresponsible.  Grossly so.  Mark has already entreated you to read RFC 8820, but I will quote from Section 2.4 so that there is no mistaking the error:

> Extensions MUST NOT constrain the format or semantics of queries, to avoid collisions and erroneous client assumptions.

This spec violates that assumption. offers some alternative designs that I encourage you to explore.  This one is not acceptable.

There are a bunch of other issues that are apparent to me as a non-expert:

1. The issue Mark raised about connection management ( is a case of over-specification.  The general strategy for retrieving enough of a font to learn where pieces of it might live might be useful, but you can specify too much and this very much does so.

2. The use of transfer coding for compression won't work in most cases.  Transfer coding isn't available in all versions of HTTP.

3. There is a lot of NIH evident in the specification.  You are inventing new integer encodings and an entire data format.  I also see what appears to be a novel checksum algorithm.

I do like the idea of specifying how a font might be laid out to make it easier to process in pieces, but some of this seems very optimistic about what people will be able to do with fonts to make them faster for pages.  Do you really want to have a different font for every page?  Is that a good outcome when every page has its own font to download?  We are dealing with similar issues with bundling of JS.  The result seems to be that you can optimize for one page, or optimize for many pages, but not both.  This specification contains none of that sort of nuance.

As for being able to produce a complete font in response to a query that specifies codepoint and feature subsets, that has some very poor caching properties, in addition to the query semantics issues already identified.  I can't see anywhere that the specification addresses those concerns.


On Tue, Jun 28, 2022, at 22:34, Chris Lilley wrote:
> The Web Fonts WG requests review of the Incremental Font Transfer (IFT) 
> specification by the IETF HTTP WG. A new WD of IFT was published today [1]
> This specification defines two methods 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 work proposes a specific networking mechanism by which the 
> client and server can negotiate  which IFT method to use [3], and to 
> transfer requested subsets of the entire font [4][5]. Note too that Mark 
> Nottingham has raised a performance concern for the Range Request method [6]
> We would particularly value the review of the IETF HTTP WG on those 
> aspects, although review of the entire specification would of course be 
> most welcome.
> Please feel free to raise issues on our GitHub repo [7].
> [1]
> [2]
> [3]
> [4]
> [5] 
> [6]
> [7]
> -- 
> Chris Lilley
> @svgeesus
> Technical Director @ W3C
> W3C Strategy Team, Core Web Design
> W3C Architecture & Technology Team, Core Web & Media

Received on Wednesday, 29 June 2022 01:50:16 UTC