Resent-Date: Wed, 24 Jul 2024 17:03:18 +0000
Resent-Message-Id: <E1sWfOY-004vgX-1S@mab.w3.org>
Received-SPF: pass (puck.w3.org: domain of gmail.com designates 2a00:1450:4864:20::62b as permitted sender) client-ip=2a00:1450:4864:20::62b; envelope-from=patmeenan@gmail.com; helo=mail-ej1-x62b.google.com;
MIME-Version: 1.0
References: <132cd8d5-d1d0-4912-97c3-9144e814725f@w3.org>
In-Reply-To: <132cd8d5-d1d0-4912-97c3-9144e814725f@w3.org>
From: Patrick Meenan <patmeenan@gmail.com>
Date: Wed, 24 Jul 2024 13:02:58 -0400
Message-ID: <CAJV+MGxinyW8-PMNKSSSh49nYOvOoJuSHJZU5tYFKRS9BC9-4g@mail.gmail.com>
To: Chris Lilley <chris@w3.org>
Cc: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="000000000000b337c2061e0140a5"
Subject: Re: Please review HTTP performance aspects of Incremental Font Transfer
Archived-At: <https://www.w3.org/mid/CAJV+MGxinyW8-PMNKSSSh49nYOvOoJuSHJZU5tYFKRS9BC9-4g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--000000000000b337c2061e0140a5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks. From the looks of it, the actual fetching of the incremental font
files and patches don't do anything special with HTTP itself (and it looks
like there was work done to minimize round trips by processing and
generating a de-duped list of patches). 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.

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).

Thanks,

-Pat

On Wed, Jul 24, 2024 at 9:36=E2=80=AFAM Chris Lilley <chris@w3.org> wrote:

> The Web Fonts WG requests review of the Incremental Font Transfer (IFT)
> specification by the IETF HTTP WG. A new Working Draft of IFT was publish=
ed
> 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 IETF HTTP WG on the
> networking 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
>
>

--000000000000b337c2061e0140a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks. From the looks of it, the actual fetching of the i=
ncremental font files and patches don&#39;t do anything special with HTTP i=
tself (and it looks like there was work done to minimize round trips by pro=
cessing and generating a de-duped list of patches). Moving to stand-alone p=
atch files on larg(ish) boundaries will help with the edge caching of the f=
iles. It&#39;s great to see the evolution from some of the earlier drafts.<=
div><br></div><div>I filed an issue but the one part that looked like it mi=
ght 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 patc=
hed files vs re-processing all of the patches every time).</div><div><br></=
div><div>Thanks,</div><div><br></div><div>-Pat</div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 24, 2024 at=
 9:36=E2=80=AFAM Chris Lilley &lt;<a href=3D"mailto:chris@w3.org">chris@w3.=
org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><u></u>

 =20

   =20
 =20
  <div>
    <p>
    </p>
    <div style=3D"font-size:14px" lang=3D"x-unicode">The Web Fonts WG reque=
sts review of the
      Incremental Font Transfer (IFT)=C2=A0 specification by the IETF HTTP
      WG. A new Working Draft of IFT was published on 9 July 2024 [1]
      <br>
      <br>
      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.
      <br>
      <br>
      Earlier work [2] demonstrated the performance improvements in
      terms of bytes transferred and reduced network delay, for various
      network types.
      <br>
      <br>
      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.
      <br>
      <br>
      Also (unlike earlier drafts, which used a custom patch request
      protocol) the patches are requested with a regular HTTP GET.
      <br>
      <br>
      We have an Explainer [3].
      <br>
      <br>
      We would particularly value the review of the IETF HTTP WG on the
      networking aspects, although review of the entire specification
      would of course be most welcome.=C2=A0</div>
    <div style=3D"font-size:14px" lang=3D"x-unicode"><br>
    </div>
    <div style=3D"font-family:-moz-fixed;font-size:14px" lang=3D"x-unicode"=
>Comments
      should be raised as individual issues on our GitHub [4].
      <br>
      <br>
      [1] <a href=3D"https://www.w3.org/TR/2024/WD-IFT-20240709/" target=3D=
"_blank">https://www.w3.org/TR/2024/WD-IFT-20240709/</a>
      <br>
      [2] <a href=3D"https://www.w3.org/TR/PFE-evaluation/" target=3D"_blan=
k">https://www.w3.org/TR/PFE-evaluation/</a>
      <br>
      [3] <a href=3D"https://github.com/w3c/IFT/blob/main/IFT-Explainer.md"=
 target=3D"_blank">https://github.com/w3c/IFT/blob/main/IFT-Explainer.md</a=
>
      <br>
      [4] <a href=3D"https://github.com/w3c/IFT" target=3D"_blank">https://=
github.com/w3c/IFT</a>
      <br>
      <br>
      <div><br>
      </div>
    </div>
    <pre cols=3D"72">--=20
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture &amp; Technology Team, Core Web &amp; Media</pre>
  </div>

</blockquote></div>

--000000000000b337c2061e0140a5--