ウェブ・フォントも完全に行き渡り、今はどう効率的に配信するかについて多くの時間を割くようになった。Google Fontsの低め安定路線を見限り、TypeKitやFonts.comへ鞍替えする人々も増えた。それと同時に自前でホスティングする人々も徐々にその数を増やしており、どれが最適解なのか一応の結論が出るにはもう少しかかるだろう。まず、ウェブ・フォントの読み込みにおいてどのようなアプローチがあり、どのようなメリット、そしてデメリットがあるのだろうか。
TypeKit等に頼るにしろ、自前でホスティングするにしろ、もちろん最終的にはウェブ・フォントをブラウザーに送りつける必要がある。読み込みとはまさにその部分の話だ。話がややこしくなるので、多様な実装を意識した安全な書き方などについては触れない。
普通に@font-face定義を利用
@font-face定義をただ普通に書く場合のメリットは、基本的な知識さえあれば書けることと動かなくなる可能性が最小限に抑えられることだ。CSSが単純であることから、書きやすく、組み込みやすく、修正もしやすい。将来的に仕様が大きく変化した場合でも、実装がそれなりにフォローしてくれることも期待できるだろう。
デメリットは読み込みコストの増加と初期描画の遅延だ。
読み込みコストの増加は単純に大きめの画像へのリクエストが常に行われるということでもあるし、メモリーの圧迫ということでもある。機器の進化と環境の発展が解消してくれるであろう問題であるとも言えるが、歴史を振り返ると常に汲々として対策を練らなくてはいけない類いの問題であったので、そうはたやすく解決されないだろう。
初期描画の遅延は、古くからFOUTと呼ばれ問題視されていた現象についてがまず挙げられる。だいたいはFOUTが起こらないように実装が変化した。ウェブ・フォントのリクエストに失敗していそうな時も3秒でフォールバック・フォントで表示されるように統一されつつあるので、あまり問題ではなくなりそうだ。
しかし、3秒間文字がまったく表示されない状態が続く、と考えると致命的な遅延とも言える。実際にはCSSファイルの肥大化による遅延も重なり、空白の状態からやっと表示されたら今度は文字が見えないという状態に変化するため、ユーザーへはなかなかの違和感を与えることになる。
DataURIを使ったsrc記述子の指定
メリットはウェブ・フォントが必要な場合には必ず既に読み込み済みになっていることだ。つまりCSSファイルが読み込まれたならウェブ・フォントが適用されるだろうし、何らかの理由でCSSファイルの読み込みに失敗した場合でも文字だけ見えないというような状態には決してならない。またCSSだけで完結するのも大きいだろう。残念ながらツールの助けは必要になるだろうが、特にHTMLやJavaScriptの助けは必要としない。
デメリットはCSSファイルの肥大化だ。英数記号のみの欧文タイプフェイスのウェブ・フォントであったとしてもウェイトごとに30KBほど、和文のそれになると少なくともウェイトごとに300から1000KB前後がCSSファイルに追加されることになる。これは単にCSSファイルの読み込み自体に時間がかかるということだけではなく、そのパースに時間がかかるということでもある。つまりウェブページの描画され始めるまでに時間がかかってしまうということだ。
ウェブ・フォントに限らず巨大なData URIをCSSファイルに混ぜ込むのは悪手と言って良い。せいぜい2KB前後までのSVGファイルくらいなものだろう。
ウェブ・フォントのCSSの遅延読み込み
初期描画を遅延させないためには、JavaScriptファイルの非同期読み込みと同じように、ウェブ・フォントの読み込みとウェブページの描画を同時に行わせれば良い。CSSファイルに@font-face定義を書かず、head要素の子としても書かないことによって、遅延読み込みさせることに成功すれば、ウェブ・フォント由来の初期描画の遅延は限りなく少なくなる。
このデメリットはFOUTと呼ばれ、問題視されていた古いFirefoxの挙動と同じになることだ。まずフォールバックとして指定されたローカルのフォントで表示され、ウェブ・フォントの読み込みが完了した後にフォントが変更になるため、その切り変わる時に画面がフラッシュする。読み込みが終わるまで文字がまったく表示されないよりはフラッシュすることの方がまだ良いだろうというネガティブな選択の結果の手段ということになる。
また残念ながらCSSだけでは完結しない。JavaScriptを使うか、文法違反であることに目をつぶってbody要素の最後にウェブ・フォントを読み込むためのlink要素を突っ込む必要がある。
Web Font Loader
遅延読み込みを一歩進め、フォントの読み込みを監視することにより、FOUTを制御できるようにしたのがWeb Font Loaderだ。ウェブページの描画をブロックする・しないを選択できるので、好みで柔軟に描画のされ方を調節できる。CSSだけで完結とまではいかないが、制御ロジックそのものはクラス名を通してCSSで行えるので、保守性は高い。
標準化されているCSS Font Loading Module Level 3を利用することになる将来も、これと同じようなアプローチになることが予想される。Polyfillとは言えないが、ウェブ標準と親和性が高いものとは言えるだろう。
デメリットはこれまでに上げた手法の高度なラッパーに過ぎないということだ。柔軟でカスタマイズしやすいことは確かだが、このライブラリーに強く依存することを強いられる。名前を挙げることも憚られる某ライブラリーと似たような立ち位置のものと言うと近い。
Web Storageを使ったキャッシング
読み込みをインターネット経由で行うことがウェブ・フォントにおける多くの問題の原因である以上、高速に取り出せるローカルにキャッシュがあれば良いというのが骨子となる。Web Storage (いわゆるlocalStorage)を使いウェブ・フォントをキャッシングさせれば、インターネットを経由せずに済む。想定通りうまく動けば初期描画の遅延とFOUTという二つの大きな問題は解決される。
Web Storageの実装を見るに、保守性は非常に悪いといえるだろう。キャッシュのリフレッシュまでも視野に入れると更に厳しい。利用を単純化したライブラリーがあれば一瞬光ることはありそうだが、環境の変化(SPDY)により無に帰してしまいそうな技術とも思える。
このウェブサイトでもFOUT強制をやめることにした過程で調べたり考えたりしたことを、読み込みの部分だけに特化してざっとまとめてきた。一長一短であるが、それでもあえて選択するとしたらWeb Font Loaderではないかと僕は考える。現状で最も柔軟であることは、軌道修正をする際に非常に助かる。依存しすぎないこととその挙動をしっかりと知ることを念頭に置いてWeb Font Loaderを使うのが良いだろう。
ウェブ・フォントの利用にあたってはその読み込みが最も重要な部分であることは確かだが、他にも考慮すべき点は色々ある。例えばブランド・ロゴに専用のウェブ・フォントを利用する場合は別のタイプフェイスで表示されるということは許されない。その場合はフォールバックさせず、画像を代わりに表示する必要があることだろう。そういう場合は読み込みについては特に凝ったことをしない方がやりやすい可能性も高い。
ともあれ、ウェブ・フォントの利用はウェブサイトへ大きな変化をもたらす。それは見た目だけではなくパフォーマンスについても、だ。そのことの重要な一柱である読み込みについてはしっかりと考えて実装してやる必要があるだろう。