Incremental Font Transfer via Range Request

1. Introduction

This section is not normative.

Incremental Font Transfer (IFT) is a collection of technologies to improve the latency of remote fonts (or "web fonts") on the web. Without this technology, a browser needs to download every last byte of a font before it can render any characters using that font. IFT allows the browser to download only some of the bytes in the file, thereby decreasing the perceived latency between the time when a browser realizes it needs a font and when the necessary text can be rendered with that font.

There are two technologies inside the IFT collection of technologies. This document describes one of them: the "Range-request method." In this method, the browser uses HTTP range requests to download only specific regions of the font file that it needs. In order for this method to be as effective as possible, the font file itself should be arranged in a particular way, in order to decrease the number of requests the browser needs to make.

The range-request IFT method has best performance on Chinese, Japanese, and Korean languages. These languages usually have the largest font files, and usually include many glyphs which are generally independent.

The range-request method was designed to be as easy as possible to deploy, and doesn’t require any server-side software. Deploying this method involves two steps:

1. Modifying the CSS of the webpage to opt-in, by adding a particular keyword to particular places in the CSS file, and

2. Optionally, rearranging the data inside the font file to optimize loading performance. This rearrangement process is a process by which a valid font file is input to the process and a valid font file is output from the process. When being served, the optimized font simply replaces the unoptimized font on the server. Every step in the optimization process is optional, but each should improve performance if performed. The optimization process is lossless, and no contours are affected.

A rearranged font file is still a valid font file following existing formats; this specification does *not* describe a new font file format. The guidelines simply list strategies for organizing the data within the file to achieve the best performance with the range request method.

2. Opt-In Mechanism

This section is general to both IFT methods, and is not specific to the range-request method.

The collection of IFT technologies utilizes a single shared opt-in mechanism. Each method does not use its own opt-in mechanism; instead, the webpage opts into the IFT technologies as a whole, and the browser and server negotiate to decide which specific method will be employed.

The opt-in mechanism is the incremental keyword inside the @font-face block. Websites specify this keyword inside their @font-face block, and the browser is then responsible for using IFT technologies, and for negotiating with the server to determine which specific IFT method to use.

@font-face {
    font-family: "MyCoolWebFont";
    src: url("MyCoolWebFont.otf") tech(incremental);
}

Note: Each individual @font-face block may or may not opt-in to IFT. This is due to the variety of ways fonts are used on web pages. Authors have control over which fonts they want to use this technology with, and which they do not.

3. IFT Method Selection

This section is general to both IFT methods, and is not specific to the range-request method.

When a page has indicated that a particular font should utilize IFT technology, the browser must determine which method to use. Different browsers may support different IFT methods, and different servers may support different IFT methods, so a negotation occurs as such:

1. The browser makes the first request to the server. If the client prefers the patch-subset method, it sends the relevant query parameter. If the client prefers the range-request method, it does not send the query parameter.

2. If the server receives the patch-subset query parameter and wishes to honor it, the server may reply with a valid patch subset response which includes the patch-subset magic number. Otherwise, the server may reply with the [RFC7233] Accept-Ranges header.

3. If the client receives the patch-subset magic number, it commences using the patch-subset method. Otherwise, if the client receives the Accept-Ranges: bytes header, it commences using the range-request method. Otherwise, the whole font file is downloaded, and the current non-incremental loading behavior is used.

3.1. IFT Method Fallback

This section is not normative.

This summarizes behaviors that result from the above method selection.

4. Font organization

4.1. Background

This section is not normative.

A particular organization of font files is beneficial for improving the performance of the range-request IFT method. The range-request IFT method only works with [TRUETYPE], [OPENTYPE], [WOFF], or [WOFF2] files. All of these file formats use an sfnt wrapper which provides a directory of tables inside the font file. A sfnt-based font file is mainly composed of a collection of independent tables.

Using WOFF2 files with range-request mechanism doesn’t seem to be a viable option

4.2. Introduction

The term range-request optimized font is used to describe a font file organized for use with the range-request IFT method. Optimizing a font for the range-request IFT method does not change the file format of the font.

Note: Because optimizing a font does not change its file format, no new additional tooling is necessary to interact with these optimized fonts. They are still valid fonts, but with a particular internal organization.

Note: There are no MUST-level requirements on the organization of a range-request optimized font. Any arbitrary font file may be considered to be a range-request optimized font. However, additional optimizations should increase the performance of loading in a browser via the range-request IFT method. Font creators are encouraged to enact as many of the optimizations listed in this section as are reasonable for the fonts they create.

4.3. Compression

Servers supporting the range-request IFT method should support compression via the [RFC7231] Content-Encoding header or the [RFC7230] Transfer-Encoding header, rather than having the font file itself be statically compressed.

A range-request optimized font file (the file itself) should not use any kind of compression other than [RFC7932] (commonly referred to as "Brotli") compression.

If Brotli compression is used in a range-request optimized font, it should use only one meta-block.

If Brotli compression is used in a range-request optimized font, its one meta-block should have the ISUNCOMPRESSED bit set to 1.

Static file compression compatibility with range-request method

4.4. Table Ordering

No two tables in a range-request optimized font should share a tag name.

A range-request optimized font should have only one of these tables:

• The CFF table

• The CFF2 table

• The glyf table

The term outline table is used to describe the one table which is either a CFF table, CFF2 table, or glyf table.

The outline table data in a range-request optimized font should lie at the end of the file.

If a CFF table exists, the CharString data should lie at the end of the CFF table.

If a CFF2 table exists, the CharString data should lie at the end of the CFF2 table.

Font Collections support

4.5. Glyph Independence

Note: The goal of this section is to make every glyph independent from each other.

A range-request optimized font should not use Compound glyphs.

Supporting fonts with composite glyphs via range-request

Note: Compound glyphs can be flattened by inlining their component glyphs to become additional contours.

A range-request optimized font should not use Subroutines.

Note: CFF glyph CharStrings can be flattened by inlining subroutines to become additional CharString bytes.

4.6. Glyph Order

Glyphs inside a range-request optimized font should be sorted in the file to keep glyphs often used in the same documents close together in the file.

Note: Putting the most frequently used glyphs together in the font increases the likelihood that the browser can download a contiguous sequence of necessary glyphs in a single range-request, thereby minimizing overhead.

Note: Reordering glyphs in a font is the same conceptual operation as renaming glyphs to have different glyph IDs. Therefore, this operation cannot be completed if glyph IDs must be preserved. Because glyph IDs are internal to text processing procedures and are not persisted, this requirement is not expected to be particularly burdensome.

One suggested method of sorting the glyphs in the file is by usage document frequency inside a relevant corpus.

A corpus is defined to be a collection of documents, where a documents includes a collection of glyphs necessary to render some textual content.

Note: For a particular website, a corpus might be defined to be individual page loads of pages on that website.

The usage document frequency of a particular glyph inside a corpus is defined by the number of documents in the corpus which use that glyph, divided by the number of documents in the corpus.

Note: This is distinct, but similar, to the number of times the glyph is used throughout the entire corpus.

The usage document frequency of the glyphs in a range-request optimized font should be decreasing throughout the font; that is, the most frequently used glyphs should have the lowest glyph IDs.

Note: Glyph ID 0 cannot be renamed in OpenType, TrueType, WOFF, and WOFF 2 fonts. All other glyphs can be renamed.

Note: Because the goal is simply to minimize overhead by placing similarly-used glyphs together, it may actually be possible to do better than ordering by simple frequency for a particular corpus. For example, some corpuses may have cliques of glyphs which have different frequencies but which nevertheless always seem to be used together.

A suggested ordering is included in Appendix A below.

5. Browser Behaviors

5.1. First Request

When a browser encounters the CSS opt-in mechanism, it is instructed to use IFT to load the fonts. First, it follows the steps in the IFT method selection section above. If those steps result in using the range-request method, the rest of this section applies.

The IFT method selection involves a single round-trip to the server, and if the range-request method is being used, the server’s response starts sending the font file to the browser. The browser should start parsing the partial font data as it is being loaded from the server. The browser should not wait until the entire file has been received before parsing its contents.

There is a certain amount of data from the beginning of the font file which the browser should unconditionally download. The boundary at the end of this data is called the range-request threshold.

Note: The first request does not have to be a range request. If the browser expects the range-request threshold to lie within the first n bytes of the font, the first request may be a range request for the first n bytes of the font. However, a browser may instead make a non-range request, parse the data as it is being streamed from the server, and discover that it has reached the range-request threshold while data is still being streamed.

Once all the data before the range-request threshold has been loaded by the browser, the browser may either close this connection to the server, or it may choose to leave the connection open and let the font data continue loading in the background.

A browser may choose to add a [RFC7233] Range header to the initial request during the IFT method selection if it has reason to believe the range it requests will be large enough and it prefers to not close this connection to the server.

Note: Different browsers may choose different range-request thresholds. Some browsers may treat this threshold as occuring at the end of the sfnt tableDirectory. Other browsers may treat this threshold as occurring just before any outline data, provided the outline data appears at the end of the font. Other browsers may place this threshold at the very beginning of the file, thereby treating the whole file as able to be downloaded with range-requests.

5.2. Subsequent Requests

After all the data before the range-request threshold has been loaded by the browser, the browser will determine which additional byte ranges in the file are necessary to load. It will then issue [RFC7233] HTTP Range Requests for at least those ranges.

Note: Browsers are encouraged to coalesce range requests for nearby areas of the file, to minimize the amount of range-request overhead required. Browsers are encouraged to inform these coalescing decisions from network configuration parameters and bandwidth / latency observations.

Note: If the font file has followed all of the organization guidelines above, all information required for laying out content and performing shaping will lie before any of the outline data in the file, and every glyph’s outline will be independent from every other glyph. Therefore, the browser can treat the range-request threshold as being just before outline data begins, and once it has loaded up to that threshold, it can lay out page content. After laying out the page, downloading all the necessary outlines can be done with a collection of independent and parallel range requests. This works particularly well for Chinese, Japanese, and Korean fonts, where 90% or more of the font data is outline data.

Note: Another valid alternative is to treat the entire font as residing on an asynchronous virtual filesystem, and have the browser track which ranges of the font it ended up reading during its normal operation. The browser could then request those regions in range requests.

6. Server Behaviors

Servers supporting the range-request IFT method must support [RFC7233] range requests.

Servers supporting the range-request IFT method should support compression via the [RFC7231] Content-Encoding header or the [RFC7230] Transfer-Encoding header, rather than having the font file itself be statically compressed.

7. Security Considerations

8. Privacy Considerations

See Privacy Considerations

Method-specific privacy sections

Appendix A: Suggested glyph/character ordering

Note: This section describes ordering of characters, not glyph IDs, because the meaning of glyph IDs are not consistent across different fonts. To optimize a particular font according to the ordering listed here, the characters will have to be mapped to glyph IDs inside the font. This approach of mapping characters to glyphs for ordering purposes works particularly well for ideographic languages with large character sets.

Populate suggested character ordering for range-request method