Webフォントをレンダリングを変えずに最適化する

このサイトのWebフォントの読み込みを高速化し、見た目は一切変えないこと。フォントのバイト数を可能な限り削減し、レンダリングを同一に保ち、前後のピクセル差分でそれを証明すること。視覚的な変更は、私が承認しない限りリグレッションとして扱うこと。最適化でレンダリングが変わる場合は、何が節約できて何が変わるかを報告し、サイトはデフォルトで同じ見た目を維持すること。現在の読み込み動作は維持すること：`font-display`やフォールバックフォントには触れないこと。ビルドにフォント処理を追加せず、手動で実行するスクリプトを作成し、その出力をコミットし、再実行が必要なタイミングを明記すること。まず現在の状態を測定すること：各フォントファイルのサイズ、グリフ数、可変軸、OpenType機能、ヒンティング、さらにページごとのフォントバイト数と各ページがプリロードする内容。次に、サイトが実際に何を使っているかを調べること。インラインのコンポーネントスタイルだけでなくスタイルシートも確認し、コンテンツに出現する文字、各フォントが必要とする軸の値とウェイト（一回限りのオーバーライドやイタリック内のボールドを含む）、有効になっているOpenType機能、`hyphens: auto`がU+2010ハイフンを使うようなCSSの副作用を確認すること。各フォントをその使用範囲に合わせて削減すること。使用されている文字に加えてLatin-1とLatin Extended-Aを保持し、CJKは現在のレンダリング方法に従ってシステムフォントに任せること。可変軸は使用中の範囲に制限し、軸がオーバーライドされない場合のみ1つの値に固定すること。未使用のOpenType機能とヒンティングは削除すること。各フォントを2つのファイルに分割すること。ASCIIとほとんどのページで使われる句読点（カーリークォート、ダッシュ、省略記号）を含む小さなコアファイルはプリロードされる。`unicode-range`の後ろにある拡張ファイルは、ページがその文字の1つを必要とする場合にのみダウンロードされる。各ファイルの`unicode-range`には、実際に含まれる文字のみをリストすること。いくつか注意点がある。コアファイルと拡張ファイルの間に生成されるフォールバックフェイスは、実際のフォントが届く前に拡張文字を描画する。OFLの予約フォント名を持つフォントは、サブセット化されたら内部でリネームする必要がある。生成されたファイルを確認すること。フォントツールには癖があるため。完了と見なす前に、同じコンテンツからベースラインを構築し、コード、イタリック、アクセント文字、独自のフォント設定を持つコンポーネント、CJKを含むページで前後のピクセル差分を取ること。すべての見える違いを説明すること：コンテンツの変更、修正すべきリグレッション、または無害なサブピクセルの丸め。ページごとのバイト数を再測定し、拡張ファイルが必要な場所でのみ読み込まれることを確認すること。完了したら、フォントごとおよびページごとの前後のバイト数、ピクセル差分の結果、私の要求から逸脱した箇所とそのコスト、スクリプトの再実行方法を報告すること。後で、コアフォントをグローバルスタイルシートに埋め込み、アイドル後に拡張ファイルをプリキャッシュする価値があるかもしれない。