Re: Partial loading of fonts

While developing the inxcfer simulation I spent some time looking into how
HTTP/2 handles headers and found it's quite effective at compressing them.
I did some testing on real requests and found that for most cases headers
only took up approximately 30-40 bytes. This should hopefully help shift
the balance in favour of more, but smaller requests.

On Thu, Apr 30, 2020 at 12:56 AM Mike Bremford <mike@bfo.com> wrote:

> On Thu, 30 Apr 2020 at 00:05, Myles C. Maxfield <mmaxfield@apple.com>
> wrote:
>
>>
>> The request works like this:
>>
>>    1. We request the font from the webserver as normal, but including
>>    "Range: bytes=0-" as a request header.
>>    2. If the response (includes "Accept-Ranges: bytes" AND if it has a
>>    valid Content-Length header AND if it has no "Content-Encoding" header),
>>    then close the connection after reading a respectable amount of data, but
>>    at least enough to include the initial lookup table.
>>    3. We then lazily load the blocks we need from the font depending on
>>    the tables (or parts of tables) we need, by submitting a request with an
>>    appropriate "Range" header. We break the file up into chunks (we chose 32KB)
>>
>> This is interesting - I hadn’t considered using blocks. What was the
>> motivation for using blocks?
>>
>
> Reducing overhead really. There's no point in bolting 1KB of headers onto
> a request for 100 bytes, and many individual glyphs are not much more than
> that. We did no analysis on block size though - I'm sure this could be
> tuned quite a bit, and the balance is probably quite different for HTTP/2.
>
> Oh and, for completion, I now recall that the reason we send "Range: bytes
> 0-" is not for any HTTP reason. It's to work around a Java bug - web
> servers SHOULD send "Accept-Range: bytes" unprompted.
>
> Overall, this is super interesting, thanks for posting it!
>>
>
> Glad to help! While I can't offer you web headers and timing details from
> the client, it's still possible to log the request headers received and
> data sent on the server end if you're hosting the font.
>
>

Received on Friday, 1 May 2020 23:44:22 UTC