Webフォントは遅い？　実際に表示時間を計測検証してみた【動画で検証】

Webフォントは、デザイン性が高くSEOにも強い反面、「表示が遅いからダメだ」という声もある。果たしてイマドキのWebフォントの表示は遅いのか？

Webサイトのパフォーマンス測定サービス「WebPagetest」で、フォントファイル型とWebサービス型それぞれで、Webフォントを使ったページの表示速度を検証してみた。

（過去記事参照：日本語Webフォントは「遅い・重い」って思い込んでた……こんなに速くなってたなんて……）

テキストも画像も使用しているサイトをPCで

比較動画

最初に比較動画を見てみよう。左側が「TypeSquare」、右側がフォントファイル型だ。最初の描画はフォントファイル型の方が若干だけ速いが、フォントファイル型はそこから延々フォントのダウンロードが続いている。

ページ表示完了までにかかった時間

• Webフォントファイルをサーバーに配置した場合： 23秒
• クラウド型Webフォントサービス「TypeSquare」を使った場合： 5.8秒

詳しく見てみよう：Webフォントファイルの場合

まずは従来のWebフォントファイル型での描画だ。

完了（Document Complete）にかかった時間は23.080秒。テストに利用したサーバーがあまり高速ではない点を考えても、かなり厳しい。

ちなみに、フォントは1回ダウンロードすればブラウザにキャッシュされるため、2回目の描画（Repeat View）は3.801秒だった。

円グラフを見るとわかるが、ダウンロードの97％はフォントで占められている。

やはりフォント5種類で10MBバイトを超えるフォントファイルのダウンロードは、負荷が高いようだ。

利用するフォントを2種類ほどに減らしても9秒ほどかかる計算になる。

動画で見てみると、5秒を過ぎたあたりで画面は表示されるものの、その時点での表示はデバイスフォント。Webフォントに置き換わるまで15秒程度かかる。

詳しく見てみよう：TypeSquareの場合

次に「TypeSquare」サービスを利用した描画の結果を見てみよう。

完了（Document Complete）にかかった時間は5.108秒。Webフォントファイル型と比べると4倍以上のスピードだ。

フォントは1回ダウンロードすればブラウザにキャッシュされるため、2回目の描画（Repeat View）は3.173秒だった。

ダウンロードのほとんどがフォントファイルで占められていたフォントファイル型と異なり、フォントは全体の約半分の割合だ。

動画で見てみると、4秒でまず枠が描画され、ワンテンポ遅れて文字が表示されるという印象だ。

参考：Webフォントを使わない場合

参考値として、Webフォントを一切利用せずデバイスフォントのみの表示としたファイルで測定してみると、描画完了（Document Complete）にかかった時間は2.466秒であった。

テキストも画像も使用しているサイトをモバイルデバイスで

比較動画

次にモバイルでの結果を見てみよう。

比較動画では明らかに左側の「TypeSquare」を使用したファイルの方がフォントファイル型よりも描画が速くなっている（テストページがモバイル最適化されていないのはご容赦いただきたい）。

詳しく見てみよう：Webフォントファイルの場合

Webフォントファイル型をモバイルデバイス（ブラウザはChrome）で描画した結果だ。

完了（Document Complete）にかかった時間は9.453秒と、やはり初回だけは時間がかかる。

こちらが動画。5秒ほどで描画が完了した後もまだしばらくダウンロードが続く。

詳しく見てみよう：TypeSquareの場合

次に「TypeSquare」サービスを利用した描画の結果を見てみよう。

完了（Document Complete）にかかった時間は2.544秒。フォントファイル型の3倍のスピードが出ている。

このスピードだとほとんどストレスはないと言えよう。

テキスト中心サイトをPCで

比較動画

ここまではそれなりに画像も使用したファイルで試してきたが、テキスト中心のサイトだとどうなるだろうか？

ほとんど画像を含まない同条件のファイルで試してみた。

こちらも左側の「TypeSquare」の方がかなり早めにダウンロードを終えている。

詳しく見てみよう：Webフォントファイルの場合

まずはフォントファイル型。

完了（Document Complete）にかかった時間は22.612秒、画像を多く含むサイトとほとんど変わらない。やはりフォントダウンロードに負荷がかかっているようだ。

動画はこちら。4秒ほどで読めるようになるが、そのあと延々ダウンロードが続く例のパターンだ。

詳しく見てみよう：TypeSquareの場合

次に「TypeSquare」サービスを利用した描画の結果だ。

完了（Document Complete）にかかった時間は5.358秒。こちらも画像入りのファイルとほぼ同じスピードだ。この程度の画像の有無はあまり描画スピードに関係ないという結果になった。

動画も画像入りとほぼ同様だ。

テキスト中心サイトをモバイルデバイスで

比較動画

今度はモバイルデバイスでテキスト中心サイトを描画した際の比較動画。左側が「TypeSquare」、右側がフォントファイル型だ。

詳しく見てみよう：Webフォントファイルの場合

テキスト中心サイトをモバイルデバイス（ブラウザはChrome）で描画した結果だ。

フォントファイル型で完了（Document Complete）にかかった時間は13.040秒。こちらもPCより短いが、やはり時間がかかる。

動画もほぼ同様の結果。

詳しく見てみよう：TypeSquareの場合

次に「TypeSquare」サービスを利用した描画の結果を見てみよう。

完了（Document Complete）にかかった時間は2.764秒。ここまでの最速値を叩きだした。

この程度だとほぼストレスはないだろう。

まとめ

以上、「TypeSquare」の描画速度はブラウザで約5秒、モバイルで約2秒と、かなりの高速化が実現していることが実証された。

もちろんほぼ一瞬で描画されるデバイスフォントと比べると、少しだけ遅れているという印象はあるが、その遅延も初回だけ、ほぼ遅延は感じられなかった。

それにしても、5種類のWebフォントをページ内で利用しても、現実的な速度で表示できる「TypeSquare」の実力には驚かされた。

Webフォント関連のサービスは、さまざまな努力で常に改善が続けられている。昔の「遅い」という印象にこだわっていると、Web担当者として損をしてしまうのではないだろうか。

ちなみに、今回比較のために使用したGoogleの「Noto Sans」フォントで、この結果だけを見ると少々厳しいように見えるが、

• 利用するフォント数の削減
• サブセットの作成、圧縮、キャッシュ
  参考：Webフォントをできるだけ軽く表示する圧縮の.htaccessや遅延ロードJSを作ってみた

などの工夫によって、もう少し現実的なスピードまでもっていくことは可能だ。

※このページはモリサワのWebフォントサービス「TypeSquare」の「黎ミン」「新ゴ」「ゴシックMB101」を利用しています。