Webフォントの表示を最適化するテクニック

Post on:2021年6月3日

はじめに

システムフォントとWebフォントの優位性については前回の記事で書きました。私はその記事でシステムフォントファーストのアプローチを推奨し、システムフォントと比較してWebフォントは(a)パフォーマンスに悪影響を及ぼし、(b)より多くのデータを使用し、(c)サイトのエネルギー消費量を増加させると解説しました。

しかし、WebフォントのないWebは、面白くありません。もしかしたら、責任を持ってWebフォントを使用することでデメリットを最小限に抑えながら、すべてのメリットを享受できるかもしれません。

この記事では、Webフォントのパフォーマンスを向上させるための5つのテクニックについて解説します。これらのテクニックは最小限の労力で、最大限のメリットをもたらすと思います。

記事を書くにあたり、Zach Leatherman氏のサイトを参考にしました。彼の記事はどれも読む価値があり、特に「The Font Loading Checklist」と「A Comprehensive Guide to Font Loading Strategies」は非常に役立ちました。

この記事では、同じ意味で使われることが多いが、従来は異なる意味を持つ2つの用語を使用しています。

タイプフェイス（Typeface）

タイプフェイスとは、共通のデザインを持つフォントの完全なファミリーのことです。1つの書体には、任意の数のウェイトやスタイルを含めることができます。例えば、ヘルベチカ（Helvetica）は書体です。フォントファミリーのようなものと考えることができます。
フォント（Font）

フォントとは、1つの書体のウェイトとスタイルのことです。物理的な活字の場合、各フォントは特定のサイズ・ウェイト・スタイルのグリフを含む専用の箱に入っていました。例えば、10ポイントのHelvetica太字イタリックです。現代のデジタルフォントはベクターベースのデザインを採用しているため、1つのフォントを無限に拡大・縮小することができますが、ウェイトやスタイルごとに個別のファイルが必要になります（可変フォントを除く）。

1. Webフォントには最新のファイルフォーマットを使用する

2021年5月現在、Web Open Font Format 2.0（woff2）がWebフォント用の最小かつ最も効率的なファイルフォーマットです。CSSの@font-faceを使用する際は、ttfなどの古くて効率の悪いフォーマットよりも前に、woff2フォントが表示されるようにします。ブラウザはファイルサイズが大きくても、リスト内で最初に定義されたフォントを使用します。

@font-face {
  font-family: 'Typefesse';
  src: url('typefesse.woff2') format('woff2'),
    url('typefesse.woff') format('woff');
}

@font-face {

font-family: 'Typefesse';

src: url('typefesse.woff2') format('woff2'),

url('typefesse.woff') format('woff');

}

IE8をサポートする必要がなければ、woff2とwoff以外は必要ありません。IE11に対応する必要がなければ、woff2だけで十分です。

また、フォントにttfファイルしかない場合（例えば、Google Fontsからフォントをダウンロードした場合）、Online Font Converterのようなツールを使って変換する必要があります。ただし、フォーマットの変換がライセンスで許可されているか必ず確認してください。

2. font-displayプロパティを使用する

フォントの読み込みを調べると、よく目にする略語があります。

FOIT (Flash of Invisible Text)

FOIT (Flash of Invisible Text)とは、ブラウザがWebフォントをダウンロードする前にテキストが非表示になる時間のことです。
FOUT (Flash of Unstyled Text)

FOUT (Flash of Unstyled Text)とは、ブラウザがWebフォントをダウンロードする前にフォールバックのフォントでテキストがレンダリングされる時間のことです。

どちらも理想的ではありませんが、Webフォントを使用している場合、ユーザーがWebサイトに初めてアクセスしたときにはいずれかが発生する可能性があります（うまくいけば、2回目のページロードではブラウザがキャッシュからフォントを提供できるようになっています）。上記の@font-faceにfont-displayを加えることで、どちらを使用するかをブラウザに指示できます。

@font-face {
  font-family: 'Typefesse';
  src: url('typefesse.woff2') format('woff2'),
    url('typefesse.woff') format('woff');
  font-display: swap;
}

@font-face {

font-family: 'Typefesse';

src: url('typefesse.woff2') format('woff2'),

url('typefesse.woff') format('woff');

font-display: swap;

}

font-displayプロパティには、5つの値があります。デフォルトはautoで、ブラウザはFOITを優先します。
他の4つの値は、下記の通りです。

font-display: swap;

swap値は、Webフォントが読み込まれるまでの間、フォールバックのフォントを使用してテキストを表示するようにブラウザに指示します（つまり、FOUTを優先）。これに5秒かからろうか5分かかろうが、フォントが読み込まれるとすぐにスワップされます。そのためWebサイトを訪問したユーザーがすぐにコンテンツを読み始めることができるため、優れた値です。ただし、Webフォントに入れ替わった時にレイアウトが大きく変化しないように、必ず同様のフォールバックを選択してください。

font-display: block;

Webフォントが読み込まれるまでテキストを非表示にする場合（つまり、FOIT）は、block値を使用します。ただし、テキストが永久に非表示のままになることはありません。一定の時間（通常は3秒）以内にフォントが読み込まれなかった場合は、ブラウザはフォールバックのフォントを使用し、読み込まれたらWebフォントに入れ替わります。

もし、この値が最良の選択肢だと思われる場合は、テキストが非表示になると、コンテンツが読めなくなることを覚えておいてください。

font-display: fallback;

fallback値はswapと似ていますが、2つの違いがあります。

テキストは非常に小さい（～100ms）ブロック時間でテキストが非表示になり、その後フォールバックのフォントが表示されます。
短時間（～3s）の間にWebフォントが読み込まれなかった場合、ページの残り期間はフォールバックのフォントが使用されます。

ユーザーが初めてサイトを訪れたときにWebフォントが表示されているかどうかを気にしない場合（ユーザー自身が気にしていない可能性もありますが）、フォールバックを選択することをお勧めします。

font-display: optional;

optional値はfallback似ていますが、フォントの読み込みに非常に短い時間（～100ms）が与えられ、その後スワップはされません。ただし、追加機能があり、回線が遅すぎてフォントが読み込めない場合にブラウザがフォントのリクエストを中止することができます。

ページ上の各フォントは、それぞれ独自のFOITとFOUTの期間があります。フォントはすべてが読み込まれたときではなく、読み込まれるたびに個別に交換されます。これにより、残念な動作が発生することがあります（参考: Mitt Romney Web Font Problem）。フォントの読み込みを完全にコントロールするには、JavaScriptによる解決策を検討する必要があります。

3. Webフォントをプリロードする

FOITとFOUTの期間を最小限に抑えるためには、Webフォントのファイルをできるだけ早く読み込む必要があります。HTMLの<head>に<link rel="preload">を使用すると、ブラウザにフォントの取得を早く開始するように指示することができます。<head>内の上部（CSSのより上）に下記のコードを記述し、href属性にフォントファイルのURLを記述します。

<link rel="preload" href="/typefesse.woff2" as="font" type="font/woff2" crossorigin>

1	<link rel="preload" href="/typefesse.woff2" as="font" type="font/woff2" crossorigin>

このコードを追加することで、ブラウザにフォントファイルの読み込みをすぐに開始するように指示しています。通常は、CSSの中で特定のフォントへの参照を見つけ、そのフォントを使用するDOM要素を見つけるまでは読み込みを開始しません。

ブラウザは通常、現在のページで必要な場合にのみフォントをダウンロードするようになっています。preloadを使用すると、その動作が無効になり、フォントが使用されていなくてもブラウザにフォントをダウンロードさせることになります。そのため、プリロードするフォントのフォーマットは1つだけにしてください（woff2を推奨）。

プリロードするフォントの数が多ければ多いほど、このテクニックから得られるメリットは少なくなるので、ページの折り目より上（スクロールせずにユーザーが最初に目にする100vh）に表示されるフォントを優先します。

プリロードについての詳細は、Yoav Weiss氏の記事をご覧ください。
参考: Preload: What Is It Good For?

4. Webフォントをサブセット化する

フォントはサブセット化することで、必要なグリフ（個々の文字や記号）のみを含むより小さなフォントファイルを生成できます。私はFont Subsetterをよく使用して、フォントファイルをサブセット化しています。例えば、私のブログではSpace Grotesk Boldをサブセット化し、Basic Latinの範囲の文字だけを含むようにしました。これにより、woff2のファイルサイズは、30kBからわずか7kBに軽量化されました。

サブセット化は強力なツールですが、いくつかの潜在的な欠点もあります。ユーザーが作成したコンテンツ、人名、地名などを表示するサイトを構築している場合は、英語表記で一般的な26の文字、10の数字、数種類の記号以外の文字を考慮する必要があります。

最低限知っておくべきことは、発音を変えるために文字の上下に表示されるグリフである発音記号です。これらは、フランス語、スペイン語、ベトナム語などの言語や、ギリシャ語やヘブライ語などのアルファベットから音訳された（またはローマ字化された）テキストによく見られます。また、外来語（他の言語から採用された言葉）にも見られます。

発音記号の例

幸いなことに、あなたのサイトのすべてのページに異なるグリフがあるかどうかを手動でチェックする必要はありません。Glyphhangerはコマンドラインツールで、2つの便利な機能を備えています。まずあなたのWebページを調べて、使用されているUnicode文字の範囲を決定し（範囲は、スクリプトや言語に対応しています。例えば、「Basic Latin」、「Cyrillic」、「Thai」など）、次にフォントファイルをサブセット化して、指定された範囲の文字だけを含む新しいバージョンを出力します。

Glyphhangerを使用するのは最初は難しいかもしれません（pythonとpipが必要）が、Sara SoueidanのブログにWeb用のフォントファイルを最適化および変換するためにmacOSでGlyphhangerを設定する方法の解説があります。
参考: How I set up Glyphhanger on macOS for optimizing and converting font files for the Web

最後に重要なことは、ファイルのフォーマット変更と同様に、フォントのライセンスでサブセット化が許可されていることを確認してください。

5. Webフォントをセルフホストする

これは他の多くのポイントのように、普遍的なルールではありません。Google FontsやAdobe Fontsのようなホスト型サービスを利用したいと思う理由は2つあります。

これらのホスト型サービスは、Web上で特定のタイプフェイス（書体）を使用するための最も安価で、唯一の合理的な方法です。これらのサービスのいずれかを使用する以外に選択肢がない場合は、そのサービスがサブセット化やfont-displayプロパティの記述に対応しているかどうかを確認してください。
便利です。HTMLの<head>内に一行コピペするだけで利用できます。ウェイトやスタイルごとに@font-faceでルールを定義するより早いです。

便利だからという理由だけでGoogle Fontsを使用しているのであれば、google-webfonts-helperを使用してみてください。このツールを使用すると、Google Fontsの全セットからカスタムWebフォントバンドルを構築し、必要なウェイトと文字セットを定義し、必要なCSSとフォントファイル（最新フォーマット）をすべて含む単一のダウンロードを提供してくれます。

Webフォントの迷信

Google FontsのFAQによると、「同じフォントを同じソースから読み込むサイトを以前に訪れたことがある場合、キャッシュされているのでブラウザが再度ダウンロードする必要がない」という主張を聞いたことがあるかもしれません。

これはかつては真実だったかもしれませんが、効果があるほど定期的に起こっているという証拠は見つかっていません。実際、Google ChromeとSafariはどちらもトラッキングに関する懸念から、キャッシュされたサードパーティのリソースを異なるドメイン間で共有することを明確に禁止しています（参考資料）。

ホストされたサービスを使用せず、代わりにフォントをセルフホストする理由を下記に示します。

パフォーマンス

ドメインのルックアップには時間がかかります。プリコネクトのリソースヒントを使用して問題を軽減できますが、新しいドメインへのTCP接続を開く際には常にパフォーマンスが低下します。このことがGoogleの自社サイト（web.devなど）がGoogle Fontsではなくセルフホストのフォントを使用している理由かもしれません。

プライバシー

Adobe Fontsのような有料のWebフォントサービスでは、課金のためにページビューを検出する必要がありますが、厳密には必要以上のデータを収集している可能性があります。選択肢がある場合は、JavaScript（<script>）ではなくCSS（<link rel="stylesheet">）を使ってフォントを読み込むことで、サードパーティがユーザーについて収集できるデータ量を最小限に抑えることができます。

Google Fontsは、IPアドレスやUser Agentの文字列以外には、Webサイトの訪問者に関する多くの情報を収集していないようですが、Googleはこのサービスを無料で提供することで、完全に無欲に行動しているわけではありません。Google Fontsを使用している50兆のページビューは、Webサイトがセルフホストのフォントを使用することを選択した場合、Googleにはないデータポイントになります。
参考: Google Fonts Analytics