2021年8月18日

フォント読み込みの影響を軽減するための新しい方法：CSSフォントディスクリプタ

A New Way To Reduce Font Loading Impact: CSS Font Descriptors

(2021-7-6)by Barry Pollard

本記事は、原著者の許諾のもとに翻訳・掲載しております。

クイックサマリー ‐ Webフォントは往々にしてWebのパフォーマンスをひどく低下させており、この問題に対して特に効果的なフォント読み込みの戦略は存在しません。しかし、今後公表されるフォントのオプションによって、フォールバックフォントを最終的なフォントに合わせやすくなるかもしれません。

フォントの読み込みはWebのパフォーマンスにとって長年にわたる悩みの種であり、これを解決する良い方法はありません。Webフォントを使用する場合は基本的に、フォントをダウンロードするまでテキストが表示されないFOIT（Flash of Invisible Text）か、最初はフォールバック用のシステムフォントを使用し、ダウンロードが済んだらWebフォントに更新するFOUT（Flash of Unstyled Text）のどちらかを選ぶ必要があります。正直に言って、どちらの選択肢もあまり満足の行くものではなく、どちらかが特に「勝っている」わけではありません。

`font-display`はこの問題を解決するはずだったのでは？

@font-faceのfont-displayプロパティは、以前はブラウザがFOITかFOUTかを決めていたのに対して（従来はIEとEdgeがFOUTを好み、他のブラウザがFOITを好んでいました）、Web開発者に選択肢を与えました。しかし、それ以上の問題は解決しませんでした。

font-display: swapが発表された当初、多くのサイトはこれに移行し、Google Fontsに至っては2019年にデフォルトに設定しました。この背景にある考え方は、たとえフォールバックフォントであっても、テキストを可能な限り速く表示して、ダウンロードが終わってからフォントを変えるほうがパフォーマンスにとっては望ましいというものでした。

筆者もかつてはこの考え方を支持していましたが、Webフォントがダウンロードされるとフォント間の違いによって文字が拡大（または縮小）する「ハイドレーション効果」にイライラするようになりました。Smashing Magazineでは、ほとんどのパブリッシャと同様にWebフォントを使用しています。以下のスクリーンショットは最初のレンダリング（フォールバックフォント）と最終的なレンダリング（Webフォント）の差を示したものです。

Smashing Magazineの記事をフォールバックフォントで表示した場合とすべてWebフォントで表示した場合 (プレビューを拡大)

並べてみると、Webフォントはフォールバックフォントよりもかなり見た目が良く、Smashing Magazineのブランドにも適しています。しかし、2つのフォントの間にはテキストのレイアウトに大きな差があります。フォントのサイズが非常に異なるため、画面上のコンテンツが動いているのです。現在のCore Web Vitalsの時代に、（全く当然ながら）Cumulative Layout Shift（CLS）がユーザーにとってマイナスと認識されていることを踏まえると、font-display: swap はレイアウトが動くので選択肢として今ひとつです。

筆者はテキストのがたつきが本当に不快でうっとうしかったので、自分が担当したサイトはfont-display: blockに戻しました。確かにblockではがたつきを防げませんが（フォントは依然として不可視のテキストとしてレンダリングされます）、少なくともユーザーには気になりにくくなります。また筆者は、サブセット化したフォントをセルフホスティングし、プリロードするフォントを可能な限り小さくすることでフォント読み込みを最適化しており、そのため訪問者がフォールバックフォントを見る時間はごくわずかになっていました。swapでフォールバックフォントが表示される時間は非常に短く、筆者の場合、最初から正しくレンダリングさせるために少し待つほうが好みだったのです。

`font-display: optional`はFOITとFOUTを解決できるが、代償が必要

font-display: optionalを使用するという選択肢もあります。この選択肢では一般にWebフォントがオプションとなります。言い換えれば、ページが必要とする時点までにフォントが準備されていない場合、フォントを変更するかどうかをブラウザに任せることが可能です。このオプションでは、基本的にダウンロード済みのフォントのみを使用すればFOITとFOUTの両方を回避できます。

Webフォントが使用できなければ、フォールバックフォントの読み込みが行われますが、次のページへ移動するとき（または同じページを再読み込みするとき）はWebフォントが使用されます。その頃にはダウンロードが終わっているはずだからです。しかし、Webフォントがサイトにとってその程度の重要性ならば、Webフォントを完全になくしてしまうだけで良いのかもしれません。そのほうがWebのパフォーマンスにとっても望ましいのですから！

とはいえ、第一印象は大切であり、最初の読み込みを全くWebフォントなしで行うのは少しやり過ぎと感じられます。また、根拠は全くないのですが、ユーザーに対してWebサイトが何か「変」だという（場合によっては無意識の）印象を与え、Webサイトの使用状況に影響を及ぼす可能性があると思われます。

したがって、Webフォントを全く使わないことや、システムフォントを使用すること（制約はありますが、多くの人が考えるほど大きな制約ではないかもしれません）を含め、フォントをめぐる選択肢にはすべて欠点があります。

フォールバックフォントを本来のフォントにより近づける

Webフォントの読み込みにおける究極の目標は、フォールバックフォントを実際のWebフォントに近づけ、目立つ変化を可能な限り小さくして、swapの使用による影響を軽減することです。変化を完全に回避するのは今後も不可能でしょうが、上記のスクリーンショットよりもうまくやる方法はあります。Monica Dinculescu(https://twitter.com/notwaldorf)のFont Style Matcher(https://meowni.ca/font-style-matcher/)アプリは、フォントの読み込みに関する記事でたびたび紹介されており、この分野の素晴らしい可能性をうかがわせてくれます。このアプリは、同じテキストを2つの異なるフォントで重ね合わせて表示し、両者の違いを確認できるようにすることで、フォントのスタイリングを調整して差を小さくするのに役立ちます。

Font Style Matcherのスクリーンショット。2つのフォントをデフォルトの同じ設定で重ね合わせた場合（上）と、両者をより近づけるように設定を調整した場合（下）（プレビューを拡大)

残念ながら、フォントのスタイルのマッチングには問題があります。これらのCSSスタイルはフォールバックフォントのみに適用することができないため、JavaScriptとFontFace.load APIを使用して、Webフォントの読み込み時にスタイルの差を適用する（あるいは元に戻す）必要があるのです。

コードの量は膨大ではありませんが、それでも必要以上に手間がかかっているように感じます。とはいえ、JavaScript APIを使用することには他の利点や可能性もあります。2018年にZach Leathermanがこの素晴らしい講演で説明した通り、JavaScript APIを通じてリフローを削減し、data-serverモードとprefers-reduced-motionを扱うことができるのです（ただし、この講演以降、data-serverモードとprefers-reduced-motionは共にCSSの影響を受けるようになっています）。

また、多様なフォールバックスタイルの違いの処理が難しいのはもちろんのこと、既にキャッシュされたフォントを扱うのも大変です。Smashing Magazineでは、さまざまなユーザーとオペレーティングシステムがインストールしているシステムフォントを最大限に活用するため、以下のように多くのフォールバックを試しています。

font-family: Mija,-apple-system,Arial,BlinkMacSystemFont,roboto slab,droid serif,segoe ui,Ubuntu,Cantarell,Georgia,serif;

どのフォントが使用されているかを把握し、各フォントを別々に調整してそれが正しく適用されるようにすることは、極めて煩雑な作業となる可能性があります。

優れたソリューションが間もなく登場

以上が現状の簡単なまとめです。しかし、地平線の向こうに変化の兆しが見え始めています。

Excited for the CSS "size-adjust" descriptor for fonts: reduce layout shifts by matching up a fallback font and primary web font through a scale factor for glyphs (percentage).

See https://t.co/mdRW2BMg6A by @cramforce for a demo (Chrome Canary/FF Nightly with flags) pic.twitter.com/hEg1HfUJlT
— Addy Osmani (@addyosmani) May 22, 2021

前述の通り、フォールバックフォントとのスタイルの差を適用する際の主な問題は、スタイルを追加して、それから削除しなければならないことでした。もしブラウザに対して、これらの差をフォールバックフォントのみに適用するように指示できたらどうでしょうか？

これこそまさにCSS Fonts Module Level 5の一部として提案されている、新たな一連のフォントディスクリプタが実現することです。このディスクリプタは個々のフォントが定義されている@font-faceの宣言に適用されます。

Simon Hearneはfont-faceディスクリプタの仕様のアップデート案について文書を執筆しており、そのアップデートの中にascent-override、descent-override、line-gap-override、advance-override（その後取り下げ）という4つの新たなディスクリプタが含まれています。Simonはフォントメトリクスの上書き用のプレイグラウンドを作成しています。ここではカスタムフォントとフォールバックフォントを読み込み、上書きによってフォントを完璧に合わせられるかを試すことができます。

Simonが書いている通り、この4つのディスクリプタを組み合わせれば、フォールバックフォントのレイアウトを上書きしてWebフォントに近づけることが可能ですが、これらは行間と垂直位置の調整しかできません。そのため、字送りについては別途CSSの設定が必要になります。

しかし、状況は再び変わりつつあるようです。つい最近、advance-overrideの導入が中止され、代わりにsize-adjustディスクリプタが採用される予定です。このディスクリプタでは、グリフのスケールファクタ（パーセンテージ）を通じてフォールバックフォントと主要なWebフォントを一致させ、レイアウトの移動を減らすことができます。

どのような仕組みになっているのでしょうか？以下のCSSを想定してみましょう。

@font-face {
  font-family: 'Lato';
  src: url('/static/fonts/Lato.woff2') format('woff2');
  font-weight: 400;
}

h1 {
    font-family: Lato, Arial, sans-serif;
}

次にArialをフォールバックフォントとする@font-faceを作成し、size-adjustディスクリプタを適用します。CSSスニペットは以下のようになります。

@font-face {
  font-family: 'Lato';
  src: url('/static/fonts/Lato.woff2') format('woff2');
  font-weight: 400;
}

@font-face {
    font-family: "Lato-fallback";
    size-adjust: 97.38%;
    ascent-override: 99%;
    src: local("Arial");
}

h1 {
    font-family: Lato, Lato-fallback, sans-serif;
}

これは、元々Lato-fallbackが使用されている場合（Arialはlocalフォントであり、何も追加でダウンロードしなくても即座に使用できます）、size-adjustとascent-overrideの設定によってフォールバックフォントをLatoフォントに近づけられることを意味します。@font-face宣言を余分に書く必要がありますが、以前まで必要だった手順に比べればずっと簡単であるのは間違いありません。

全体として、この仕様にはsize-adjust、ascent-override、descent-override、line-gap-overrideの4つの主要な@font-faceディスクリプタが含まれており、他にも下付き文字や上付き文字などの用途向けにいくつかのディスクリプタが検討されています。

Malte Ublは、任意の2つのフォントと上記の新たな設定をサポートするブラウザ（後ほど説明します）について、これらの設定を自動的に計算する非常に便利なツールを作成しました。Malteが指摘している通り、コンピュータはこの種の作業が大得意です。うまくいけば、よく使われているフォントについて、これらの設定をWeb開発者に公開できるかもしれません（例えばGoogle Fontsのようなフォントコレクションでヒントを公開するなど）。そうすれば、きっと採用される機会が増えるでしょう。

現在はオペレーティングシステムごとにフォントの設定がわずかに異なる場合があり、完璧な調整は基本的に不可能なのですが、それを目指しているわけではありません。目的はギャップを埋め、font-display: swapの利用体験を不快でないものにすることです。そのためにoptionalを使用する、あるいはWebフォントを全くなくしてしまうという極端な行動に走る必要はありません。

いつから使用できるか？

上記のうち3つの設定はChromeのバージョン87からすでに組み込まれていますが、カギとなるsize-adjustディスクリプタはどの安定版のブラウザでもまだ使用できません。しかし、Chrome Canaryには搭載されており、Firefoxにもflags（試験運用機能）として実装されています。ですから、これはただのアイデアでも非現実的なコンセプトでもなく、すぐに実現し得るものです。

現時点の仕様にはあらゆる種類の免責事項と警告が記載されており、まだリアルタイムで使用する準備は整っていないと書かれていますが、その実現が近づいているのは確実だと思います。いつものように、われわれデザイナーと開発者の間には、一方がテストを実施してフィードバックを提供し、一方が使用をやめるように促すというバランスが存在します。ですから、あまりに多くの人が初期のドラフト版を使用しているからという理由で、実装が滞る心配はありません。

Chromeは7月20日にリリース予定のChrome 92でsize-adjustを使用できるようにするつもりだと述べており、恐らく実現まであと一歩であることを示しています。

ですから、今すぐではなくても近い将来には使用できるようです。それまでにChrome Canaryでデモを試し、フォントの読み込みをめぐる問題や、それによるCLSへの影響を少しでも解消できるのかについて確かめてみましょう。