Several times in the past we've discussed the possible benefits of a streamed WOFF2 decoder on the client side. Basically, streamed decoding allows access to certain tables "earlier", which can reduce in-practice "round-trip time". If the tables needed to make the first patch request after loading the initial font file (usually IFT, IFTX, and cmap?) are early in the stream, the client could kick off those requests before downloading the whole file.
Something I don't think we have discussed yet is that the same is, or could be, true for per-table-dependent patches. If the data for those tables is early in the stream (which I believe will not be a continuous brotli stream, but separate streams for different tables), the client can kick off a subsequent patch request before downloading the full patch. And because the sweet-spot for per-table-dependent patches is probably more coarse-grained than fine, the typical sizes will be substantial enough that this could be a significant gain.
I believe my IFT documentation had language to encourage, but not require, putting the relevant tables early in the stream. I don't see that carried over into the current spec. Given that encoders and clients will be written independently, I think it would be good to have some of this language in the Encoding section to encourage (but not require) table data placement in both the initial file and the per-table-brotli patches along these lines. And then maybe some of the content of this issue can be copied over to the prototype repository in case we want to do some of this work ourselves.
Several times in the past we've discussed the possible benefits of a streamed WOFF2 decoder on the client side. Basically, streamed decoding allows access to certain tables "earlier", which can reduce in-practice "round-trip time". If the tables needed to make the first patch request after loading the initial font file (usually IFT, IFTX, and cmap?) are early in the stream, the client could kick off those requests before downloading the whole file.
Something I don't think we have discussed yet is that the same is, or could be, true for per-table-dependent patches. If the data for those tables is early in the stream (which I believe will not be a continuous brotli stream, but separate streams for different tables), the client can kick off a subsequent patch request before downloading the full patch. And because the sweet-spot for per-table-dependent patches is probably more coarse-grained than fine, the typical sizes will be substantial enough that this could be a significant gain.
I believe my IFT documentation had language to encourage, but not require, putting the relevant tables early in the stream. I don't see that carried over into the current spec. Given that encoders and clients will be written independently, I think it would be good to have some of this language in the Encoding section to encourage (but not require) table data placement in both the initial file and the per-table-brotli patches along these lines. And then maybe some of the content of this issue can be copied over to the prototype repository in case we want to do some of this work ourselves.