ウェブフォントの読み込み方法を比較してみた

このページは比較結果を書いたページで、日本語ウェブフォントは読み込みません。


1. ウェブフォント無し

サンプルコンテンツ 1 ←クリック

PageSpeed Insights結果 1
ウェブフォント無しなので、当然だけど読み込みは速く、PageSpeed Insightsの結果は「モバイル」「パソコン」ともに100点となる。
(このページの結果画像は全て点数の出にくい「モバイル」の結果)




2. Google Fonts推奨の利用方法をそのまま採用したら

サンプルコンテンツ 2 ← クリック

PageSpeed Insights結果 2

Google Fonts推奨の利用方法に従ったウェブフォント表示方法だが、PageSpeed Insightの評価は低くなる。Chrome系ブラウザではウェブフォント適用部分はウェブフォントがダウンロードされるまで空白表示される。回線の細い閲覧者の離脱が心配。Firefoxではスライスされた個別のフォントを読み取り次第適用表示となるが、適用前は空白表示であるのは変わらない。




3. Google Fonts推奨の利用方法を非同期で

サンプルコンテンツ 3 ← クリック

PageSpeed Insights結果 3
CSSファイルやJavascriptファイルを非同期で読み込むのと同じ方法で「つい」やりたくなってしまうが、メインのフォントをこの方法で読み込むとフォント切り替わりまでに文字が表示されない時間が発生する。回線の遅い環境の閲覧者に嫌われることは間違いないので採用しない方が無難。非同期読み込みなのでPage Speed Insightsは高評価になる。
この方法はpreloadがが使えるChrome系ブラウザ以外では機能しません。つまりChrome系ブラウザ以外では指定したウェブフォントが適用されないのでインターネットに公開するウェブサイトでは採用はできないでしょう。




4. サーバにウェブフォントファイルを置いて普通にCSSファイルで指定

サンプルコンテンツ 4 ← クリック

PageSpeed Insights結果 4
ウェブサーバにウェブフォントファイルを置いて、CSSで普通に指定しているので最も遅い表示となる。Chrome系ブラウザではウェブフォントファイル(特に日本語のフルセット版は巨大)のダウンロードが終わるまでは、ウェブフォントが適用される筈の部分には何も表示されない。回線の細い閲覧者の多くは待ちきれずに離脱することになる。Firefoxでは標準フォントで表示してからウェブフォントが準備しだい表示切り替えとなる。つまりFirefoxでは次の5番と同じ動作?
PageSpeed Insightsでは先の2番より点数が低くて当然かと思われるが、何故か高得点になるよう。Chrome系ブラウザで非表示待ち問題があるのでインターネットで公開するウェブサイトでは採用してはいけない方法だと思われる。




5. サーバにウェブフォントファイルを置いてCSSファイルで遅延読み込み

サンプルコンテンツ 5 ← クリック

PageSpeed Insights結果 5
1つ前の通常読み込みではなく、CSS側の@font-face内にfont-display: swap;を指定して遅延表示させている。閲覧者のブラウザでは最初にブラウザ内蔵のフォントで1度表示してからウェブフォントをダウンロードし終わってフォント表示を切り替える。切り替え時間は1瞬なので閲覧者のストレスは少ない。ただし、指定したウェブフォントの文字幅が代替フォントと大きく異なると、フォントが切り替わったときに視線の先がそれまで読んでいた部分と全く違うという問題が起こるのでその点は注意が必要。
PageSpeed Insightsでは当然高得点。閲覧者側からしても前述の点とウェブフォントファイルが巨大という問題を除いては筋が良い部類の筈。Chrome, Firefox共に同じような動作と思われる。




6. Google Fonts配布のCSSを改変してフォントを遅延読み込みにする

サンプルコンテンツ 6 ← クリック

PageSpeed Insights結果 6
Google Fontsで推奨しているNoto系ウェブフォントは近頃は120個程度にスライスされたもののようだが、この推奨CSSファイルを改変して各スライスの@font-face内にfont-display: swap;を書き込んでサーバに置く。フォント自体はGoogleのCDNから読み込まれるのでサーバの負荷は高くはならない筈。
Chromeでは標準(代替)フォントで表示してウェブフォント必要分を全て読み取り後に切り替え表示。ウェブフォントへの切り替えは1瞬。Firefoxでは空白表示からスライスされたウェブフォント読み取り次第に順次表示となる。
CSSの読み込みが同期(しかもCSSとしては巨大)なのでPageSpeed Insightsの評価は「レンダリングを妨げるリソース」となり点数は低くなるが、それでも筋は良い部類の筈。




7. Google Fonts配布のCSSを改変してフォントを遅延読み込みにする+CSS非同期

サンプルコンテンツ 7 ← クリック

PageSpeed Insights結果 7
つ前の6番のフォント遅延読み込みをベースに、CSSの読み込みは3番の非同期読み込みにした。Chromeでは閲覧者側からすると6番と殆ど変わらないように思われるだろう。Chrome系以外のブラウザはPreloadが無効なので3番と同じくこの方法ではウェブフォントに切り替わらない。
PageSpeed Insightsの評価は上の画像では高い点数となっているが、実行の度に大きく採点結果が変わる。悪いときには50点を下回る。理由は不明。点数がどうであってもChrome系ブラウザ以外がNGなのでインターネットに公開するウェブサイトでは採用はできないでしょう。




8. サーバにウェブフォントファイルを置いてCSS Font Loading APIで読み込む

サンプルコンテンツ 8 ← クリック

PageSpeed Insights結果 8
CSS Font Loading APIは簡単なJavascriptを数行書くだけなのでウェブサイト制作者にとってはありがたい。主なモダンブラウザで利用可能なよう。Microsoftのブラウザは把握していない。非対応ブラウザではウェブフォントが適用されないことになるので、フォントの適用を重視するならまだ採用は見送った方が良いかもしれない。
動作としては5番と同じようになるのでChromeであっても空白を眺めて待つということはない。PageSpeed Insightsの点数も高めとなる様子。




終わりに

結果としては、ウェブサーバにウェブフォントを置く場合など一般的なウェブフォントは5番を、Google FontsのNoto系ウェブフォントを使用するなら6番が良さそう。また、閲覧者の多くがモダンプラウザであるならFont Loading APIの8番もアリかと思われる。
PageSpeed Insightsは何を根拠に点数を出しているのかはよく解らないが、悪い部分は教えてくれるので、何か問題があるようであればその悪い点を潰すという使う方で、一番上に表示される総合点だけで一喜一憂しない。
一番大切なのは来てくれた閲覧者に嫌がられないことなので、ページが速く表示されること、表示が崩れないこと、なるべくChrome, Firefox, Safariブラウザで意図したように表示されることを優先してページ作りを行いたい。
日本語のウェブフォントはサイズが巨大なので、最初から適用された状態で表示されることを狙うと表示待ちが長くなり、CSS非同期読み込みではフォント切り替わり時に暫く文字が消えることがあり、フォントファイルの遅延読み込みだとフォントが切り替わった瞬間に位置がズレるという問題を抱える。どれもそれぞれ閲覧者が嫌う部分ではあるけど、最後のが一番マシかなと個人的には思っている。


ちなみにサンプルページのウェブフォントを当てるコンテンツ部分のCSSでfont-family: Arial, 'Noto Serif JP', sans-serif;という指定を行っているが、アホだからArialを先頭に指定しているということではなく、多くのフォントでルビと文字の間が空いて間抜けになることがあるのを防ぐ小技です。一切ルビを振らないということであれば先頭にArialを指定する必要はありません。