Webフォントを非同期に読むテクニックはいくつかあるけど、その理由についてまとめられた文章は少ない。僕は非同期に読み込むのは3つのそれぞれ違う分野での問題を解決するためだと考えている。どの問題も致命的なものではないので、非同期に読み込むべきかどうかはそれらをどう捉えるかで変わってくる。
最もわかりやすいのはファイルサイズ、つまり転送量の問題。日本語フォントを例に上げるまでもなく、そこそこの範囲のユニコード記号や絵文字をサポートするだけでもかなりのサイズになる。カーニングやリガチャなどを加えれば更に大きくなるだろう。非同期に読み込むことにより、ダウンロードが終了するまでページの読み込みが終わらないなどということは避けられる。
しかし、これは日本語フォントでもたかだか3から5MBほどなので、それほど気にすることではない。モバイルのことを考慮してようやく「できれば」や「なるべくなら」と付く程度の基準になるのではないかと思う。キャッシュに残せるので、何度もダウンロードするわけではないこともあり、これだけでは非同期に読み込む理由としては弱い。
ページの速度は読み込み完了までの時間だけではなく、レンダリング開始までの時間も大きなファクター。MOLではDataURIの文脈でCSSの遅延読み込みについて書かれているけど、この記事の通りレンダリングをブロックしてしまうCSSのパースを、非同期に読み込むことで解決するというのは優れた解だと思う。Webフォントのホスティング・サービスを利用するケースでは、HTTPリクエストを消費することと相まってバカにならないコストになり得る。そしてそのケースはWebフォントの利用シーンではメジャーなケース。
もちろんDataURIを含むCSSに比べればパースにかかる時間は少ないので、微々たるものとも言える。とは言うものの動的にサブセッティングを行った後DataURI化してCSSに埋め込み配信したいなどということもないことはない。そういう時はこの理由は重要度を増すだろう。
Chrome 31までではWebフォントを指定している部分は、そのWebフォントの読み込みが完了するまで空白になる。仮にWebフォントを置いているサーバーが落ちたとすると、Chromeでは接続がタイムアウトするまで文章がまったく表示されないことになる。Internet Explorer 11やFirefox 25では代替フォントを利用して表示しておき、読み込みが完了した時点で差し替わるようになっている。遅延読み込みを行わせることにより、ChromeでもIE11やFx25と同じような挙動にすることが可能になる。
ソーシャルボタンが非同期に読み込むようになっている理由と似てはいるが、問題は外部サーバーのダウンという非常にマイナーである(あるべき)事象が起こった時に表面化するだけ。そのため優先度としては低い。まず安定してWebフォントを配信してくれるサービスやサーバーを選択するべき。
Webフォントを非同期に読み込む目的は、以上に挙げた理由を総合的に評価した上でのもの。そういう意味でベスト・プラクティスになりうるような手段ではないので、とりあえず非同期に読み込んでおけば良いやという話ではない。「配信元が安定しないが、どうしても使いたいWebフォントがある」などというケースでは3つ目の理由を重視して、非同期に読み込むという決断をすることになるかもしれない。