Re: Please review HTTP performance aspects of Incremental Font Transfer

[Chris Lilley <[e-mail]>]

On 2024-07-24 20:02, Patrick Meenan wrote:
> Thanks. From the looks of it, the actual fetching of the incremental 
> font files and patches don't do anything special with HTTP itself
Correct, that was the goal.
> (and it looks like there was work done to minimize round trips by 
> processing and generating a de-duped list of patches).
Yes, indeed. Especially on high latency connections, multiple round 
trips kills performance.
> Moving to stand-alone patch files on larg(ish) boundaries will help 
> with the edge caching of the files. It's great to see the evolution 
> from some of the earlier drafts.
There was a lot of criticism of the earlier approach, which we took very 
seriously; and we are confident that the current approach responds to 
those drawbacks (which would indeed have hampered widespread adoption) 
while still delivering the performance benefits that we are trying to 
enable.
>
> I filed an issue but the one part that looked like it might be able to 
> use some more fleshing out is the local behavior of patched font files 
> and how they interact with the on-device caches (caching of patched 
> files vs re-processing all of the patches every time).

I saw that issue, thanks and we will look into clarifying that aspect.

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media