Webフォントを制御する、CSSプロパティ「font-display」を使ってみた

ウェブフォント CSS
開発チーム アプリケーションエンジニア 中西 健


いいね

はじめに


みなさん。Webサイトを作る時ってカスタムフォントを設定しますよね?
日本語フォントを読み込むとダウンロードに時間かかるし、描画も遅くなる。

モダンブラウザでは描画タイミングを変更するCSSプロパティ「font-display」ってのがあるんです。今回はそれの動作を確認したいと思います。

フォント描画の流れ


フォントを描画するまでには3つの期間があり、次の順番で流れます。
font-displayではこの期間の長さをある程度変更できます。

  1. ブロック期
  2. スワップ期
  3. 失敗期

ブロック期

この期間は、目には見えないフォントを描画します。
この期間にダウンロード・読み込みが完了したら、指定したフォントが描画されます。

スワップ期

この期間は、代替のフォントを描画します。
この期間にダウンロード・読み込みが完了したら、指定したフォントが描画されます。

失敗期

この期間は、代替のフォントを描画します。
この期間ではダウンロード・読み込み完了しても、指定したフォントは描画されません。

CSSプロパティ「font-display」の値によってどう変わるか


auto

ブラウザごとに実装が異なる。詳細は後述。

block

3秒のブロック期の後、無期限のスワップ期に設定。

つまり、指定のフォントを読み込むまで、不可視のフォントを描画。iconフォントのような読み込まないと意味をなさない場合に用いると良い。
(結局読み込みが遅いと代替フォントが描画されてしまうけど)

swap

0秒のブロック期の後、無期限のスワップ期に設定。

つまり、指定のフォントが読み込まれるまで、代替のフォントを描画。いきなりフォントが切り替わることが読書の妨げにならない配慮すべき。

fallback

0.1秒以下のブロック期の後、3秒のスワップ期を設定。スワップ期を過ぎると失敗期へ。

挙動はswapと似ているが、ある程度時間が経過すると代替フォントのままになる。
文量の多いコンテンツがある場合に使うと良い。

optional

0.1秒以下のブロック期の後、0秒のスワップ期を設定。スワップ期を過ぎると失敗期へ。

挙動はfallbackと似ているが、すぐに指定のフォントか代替のフォントを使うかが決まる。サイトの細かい点よりすぐに完全に使用可能なことを優先する場合に使用する。fallbackと同じく文量の多いコンテンツがある場合に使いとよい。


※フォント読み込みに時間がかかり、失敗期に入っても、バックグラウンドでダウンロードされ、次の読み込み時にはフォントが使えるようになる。

まとめるとこんな感じ



1.ブロック期2.スワップ期3.失敗期
block3秒無期限
swap0.1秒以下無期限
fallback0.1秒以下3秒無期限
optional0.1秒以下0秒無期限

表にするとわかりやすい。
最長3秒後には代替フォントを描画するんですね。

※3秒や0.1秒以下という数値は推奨する仕様であり、ブラウザはその通りに実装していない可能性がある。

実際に動きをみてみよう


サンプル:
https://jsbin.com/lozudel/edit?html,output

サンプル(fallbackのみ):
https://jsbin.com/fumutug/edit?html,output

サンプル(optionalのみ):
https://jsbin.com/fepexab/edit?html,output

(Chromeのデベロッパーツールで通信速度を変えてみたらわかりやすくなるかも)

ブラウザのサポート


2018/11/7の段階では、モダンブラウザに採用されています。
サポートされているブラウザだけでも最適化したいですね。
詳細はこちらから。

https://caniuse.com/#feat=css-font-rendering-controls

各ブラウザのデフォルト動作


Chrome : block
Opera : block
Firefox : block
safari : block

IE : swap

なんとなく納得のIEだけ挙動が違いました。

さいごに


いかがでしたでしょうか。font-displayは設定しなくても大差ない気もしますが、意図したタイミングでフォントが配信できることで、ユーザは迷わずサイトを使ってくれるようになるかもしれません。使ってみてはどうでしょうか!!

参考


Tsubasa Mouri (2018-11-08 10:58)

直感さでいうと、fallbackが最も違和感が無いのかもしれませんね!
optionalだとランディングしたページでのWEBフォント表示は切り捨ててUXを高める事ができる半面、広告用LPではこちらの意図したフォントがレンダリングされないというジレンマもあるので、中間のfallbackがいい塩梅だと思います。

中西 健 (2018-11-08 16:13)

同感です!!各リソースを読み込む時間を考えると、3秒ぐらいでフォントを確定するfallbackが良さそうです。


採用検索 - 詳細条件の設定