ナビゲーションをスキップ
部 I 章 6

フォント

序章

ウェブフォントは、ウェブ上で美しく機能的なタイポグラフィを可能にします。ウェブフォントを使用することは、デザインに力を与えるだけでなく、デザインのサブセットを民主化します。しかし、どんなに良いことがあってもウェブフォントが適切に読み込まれていないと、サイトのパフォーマンスに大きな悪影響を及ぼすこともあります。

それらはウェブにとってプラスになるのか? それらは害よりも多くの利益を提供しているか? Web標準の牛道は、デフォルトでWebフォントの読み込みのベストプラクティスを奨励するために十分に舗装されているだろうか? そうでない場合、何を変える必要があるのでしょうか? 今日のウェブ上でウェブフォントがどのように使用されているかを調べることで、これらの疑問に答えられるかどうかをデータ駆動型で覗いてみましょう。

そのウェブフォントはどこで手に入れたの?

最初の、そして最も顕著な問題は、パフォーマンスです。パフォーマンスに特化した章がありますが、ここではフォント固有のパフォーマンスの問題について少し掘り下げてみましょう。

ホストされたWebフォントを使用すると、実装やメンテナンスが容易になりますが、セルフホスティングは最高のパフォーマンスを提供します。Webフォントはデフォルトで、Webフォントの読み込み中にテキストを非表示にする(Flash of Invisible Text、またはFOITとしても知られています)ことを考えると、Webフォントのパフォーマンスは画像のような非ブロッキング資産よりも重要になる可能性があります。

フォントは同じホストでホストされているのか、それとも別のホストでホストされているのか?

サードパーティのホスティングに対するセルフホスティングの差別化は、HTTP/2の世界ではますます重要になってきています。同一ホストのリクエストには、ウォーターフォール内の他の同一ホストのリクエストに対して優先順位をつける可能性が高いという大きな利点があります。

別のホストからウェブフォントを読み込む際のパフォーマンスコストを軽減するための推奨事項としては、preconnectdns-prefetchpreload リソースのヒントの使用がありますが、優先度の高いウェブフォントは、ウェブフォントのパフォーマンスへの影響を最小限に抑えるため、同一ホストからのリクエストにすべきです。これは視覚的に、非常に目立つコンテンツやページの大部分を占める本文コピーで使用されるフォントへ対して特に重要です。

図1. 人気のあるウェブフォントのホスティング戦略。
ウェブフォントのサードパーティおよびセルフホスティング戦略の人気を示す棒グラフ。モバイルWebページの75%がサードパーティ製ホストを使用し、25%がセルフホストを使用しています。デスクトップのウェブサイトでも、同様の利用状況です。
図 1. 人気のあるウェブフォントのホスティング戦略。font hosting strategies.

4分の3がホストされているという事実は、おそらく我々が議論するGoogle Fontsの優位性を考えると意外と知られていません以下

Googleはhttps://fonts.googleapis.comでホストされているサードパーティのCSSファイルを使ってフォントを提供しています。開発者は、マークアップの<link>タグを使ってこれらのスタイルシートにリクエストを追加します。これらのスタイルシートはレンダーブロッキングされていますが、そのサイズは非常に小さいです。しかし、フォントファイルはhttps://fonts.gstatic.comという別のドメインでホストされています。2つの異なるドメインへの2つの別々のホップを必要とするモデルでは、CSSがダウンロードされるまで発見されない2つ目のリクエストにはpreconnectが最適な選択肢となります。

preloadはリクエストのウォーターフォールの上位にフォントファイルをロードするための素晴らしい追加機能ですが(preconnectは接続を設定するもので、ファイルの内容をリクエストするものではないことを覚えておいてください)、preloadはGoogle Fontsではまだ利用できません。Google Fontsはフォントファイル用のユニークなURLを生成しますこれは変更される可能性があります

最も人気のあるサードパーティ製のホストは何ですか?

ホスト デスクトップ モバイル
fonts.gstatic.com 75.4% 74.9%
use.typekit.net 7.2% 6.6%
maxcdn.bootstrapcdn.com 1.8% 2.0%
use.fontawesome.com 1.1% 1.2%
static.parastorage.com 0.8% 1.2%
fonts.shopifycdn.com 0.6% 0.6%
cdn.shopify.com 0.5% 0.5%
cdnjs.cloudflare.com 0.4% 0.5%
use.typekit.com 0.4% 0.4%
netdna.bootstrapcdn.com 0.3% 0.4%
fast.fonts.net 0.3% 0.3%
static.dealer.com 0.2% 0.2%
themes.googleusercontent.com 0.2% 0.2%
static-v.tawk.to 0.1% 0.3%
stc.utdstc.com 0.1% 0.2%
cdn.jsdelivr.net 0.2% 0.2%
kit-free.fontawesome.com 0.2% 0.2%
open.scdn.co 0.1% 0.1%
assets.squarespace.com 0.1% 0.1%
fonts.jimstatic.com 0.1% 0.2%
図 2. リクエストの割合による上位20のフォントホスト。

ここでのGoogle Fontsの優位性は、同時に驚くべきことであると同時に意外性のないものであった。期待していたという点では予想外でしたが、サービスの圧倒的な人気の高さには驚きました。フォントリクエストの75%というのは驚異的だ。TypeKitは一桁台の遠い2位で、Bootstrapライブラリがさらに遠い3位を占めていました。

29%
図 3. ドキュメント内にGoogle Fontsスタイルシートのリンクを含むページの割合 <head>

ここでのGoogle Fontsの使用率の高さは非常に印象的だが、Google Fonts<link>要素を含むページが29%しかなかったことも注目に値する。これはいくつかのことを意味しているかもしれない。

  • ページがGoogle Fontsを使用する場合、彼らはGoogle Fontsを多く使用しています。それらは結局のところ、金銭的なコストなしで提供されています。おそらく、人気のあるWYSIWYGエディタで使われているのではないでしょうか? これは非常に可能性の高い説明のように思えます。
  • あるいは、もっとありそうにない話としては、多くの人が<link>の代わりに@importを使ってGoogle Fontsを使っているということかもしれません。
  • あるいは、超ありえないシナリオにまで踏み込んでみたいのであれば、多くの人が代わりにHTTP Link:ヘッダーを使ってGoogle Fontsを使っているということになるかもしれません。
0.4%
図 4. ドキュメントの最初の子としてGoogle Fontsスタイルシートのリンクを含むページの割合 <head>

Google Fontsのドキュメントでは、Google Fonts CSSの<link>はページの<head>の最初の子として配置することを推奨しています。これは大きなお願いです! 実際、これは一般的でありません。全ページの半分のパーセント(約20,000ページ)しかこのアドバイスを受けていないので、これは一般的でありません。

さらに言えば、ページがpreconnectdns-prefetch<link>要素として使用している場合、これらはいずれにしてもGoogle Fonts CSSの前へ来ることになります。これらのリソースのヒントについては、続きを読んでください。

サードパーティホスティングの高速化

上述したように、サードパーティホストへのウェブフォント要求を高速化する超簡単な方法は、preconnectリソースヒントを使用することです。

1.7%
図 5. モバイルページがウェブフォントホストにプリコネクティングしている割合。

うわー! 2%未満のページがpreconnectを使用している! Google Fontsが75%であることを考えると、これはもっと高いはずです! 開発者の皆さん: Google Fontsを使うなら、preconnectを使いましょう! Google Fonts:preconnectをもっと宣伝しよう!

実際、もしあなたがGoogle Fontsを使っているのであれば、<head>にこれを追加してください。

<link rel="preconnect" href="https://fonts.gstatic.com/">

最も人気のある書体

ランク フォントファミリー デスクトップ モバイル
1 Open Sans 24% 22%
2 Roboto 15% 19%
3 Montserrat 5% 4%
4 Source Sans Pro 4% 3%
5 Noto Sans JP 3% 3%
6 Lato 3% 3%
7 Nanum Gothic 4% 2%
8 Noto Sans KR 3% 2%
9 Roboto Condensed 2% 2%
10 Raleway 2% 2%
11 FontAwesome 1% 1%
12 Roboto Slab 1% 1%
13 Noto Sans TC 1% 1%
14 Poppins 1% 1%
15 Ubuntu 1% 1%
16 Oswald 1% 1%
17 Merriweather 1% 1%
18 PT Sans 1% 1%
19 Playfair Display 1% 1%
20 Noto Sans 1% 1%
図 6. 全フォント宣言に占める上位20のフォントファミリーの割合。

ここでの上位のエントリがGoogle Fontsの人気順フォント一覧と非常によく似ていることは驚くに値しません。

どのようなフォント形式を使用していますか?

今日のブラウザではWOFF2はかなりサポートされています。Google FontsはWOFF2というフォーマットを提供していますが、これは前身のWOFFよりも圧縮率が向上したフォーマットで、それ自体はすでに他の既存のフォントフォーマットよりも改善されていました。

図7. ウェブフォントのMIMEタイプの普及率
ウェブフォントのMIMEタイプの人気を示す棒グラフ。フォントの74%でWOFF2が使用されており、次いでWOFFが13%、octet-streamが 6%、TTFが3%、plainが2%、HTMLが1%、SFNTが1%、その他のすべてのタイプが1%未満となっています。デスクトップとモバイルでは、同様の分布となっています。
図 7. ウェブフォントのMIMEタイプの普及率

私から見れば、ここでの結果を見て、WebフォントはWOFF2オンリーにした方がいいという意見もあるかもしれません。二桁台のWOFF使用率はどこから来ているのでしょうか? もしかして、まだWebフォントをInternet Explorerに提供している開発者がいるのでしょうか?

第3位のoctet-stream(およびもう少し下のplain)は、多くのウェブサーバが不適切に設定されており、ウェブフォントファイルのリクエストで誤ったMIMEタイプを送信していることを示唆しているように見えます。

もう少し深く掘り下げて、@font-face宣言のsrc:プロパティで使われているformat()の値を見てみましょう。

図8. <code>@font-face</code>宣言におけるフォントフォーマットの人気度。
フォントフェイス宣言で使用されるフォーマットの人気を示す棒グラフ。デスクトップページの@font-face宣言の 69%がWOFF2形式を指定しており、11%がWOFF、10%がTrueType、8%がSVG、2%がEOT、1%未満でOpenType、TTF、OTFを指定しています。モバイルページの分布も同様です。
図 8. @font-face宣言におけるフォントフォーマットの人気度。

SVGフォントが衰退しているのを見て期待していたのですが。バグだらけだし、Safari以外のブラウザでは実装が削除されている。そろそろ捨ててしまおうか。

ここのSVGデータポイントを見ると、どのMIMEタイプでSVGフォントを提供しているのか気になります。図7のどこにもimage/svg+xmlは見当たりません。とにかく、それを修正することは気にしないで、ただそれらを取り除くだけです!

WOFF2専用

ランク フォーマットの組み合わせ デスクトップ モバイル
1 woff2 84.0% 81.9%
2 svg, truetype, woff 4.3% 4.0%
3 svg, truetype, woff, woff2 3.5% 3.2%
4 eot, svg, truetype, woff 1.3% 2.9%
5 woff, woff2 1.8% 1.8%
6 eot, svg, truetype, woff, woff2 1.2% 2.1%
7 truetype, woff 0.9% 1.1%
8 woff 0.7% 0.8%
9 truetype 0.6% 0.7%
10 truetype, woff, woff2 0.6% 0.6%
11 opentype, woff, woff2 0.3% 0.2%
12 svg 0.2% 0.2%
13 eot, truetype, woff 0.1% 0.2%
14 opentype, woff 0.1% 0.1%
15 opentype 0.1% 0.1%
16 eot 0.1% 0.1%
17 opentype, svg, truetype, woff 0.1% 0.0%
18 opentype, truetype, woff, woff2 0.0% 0.0%
19 eot, truetype, woff, woff2 0.0% 0.0%
20 svg, woff 0.0% 0.0%
図 9. フォントフォーマットの組み合わせトップ20

このデータセットは、大多数の人がすでに@font-faceブロックでWOFF2のみを使っていることを示唆しているように見える。しかし、このデータセットにおけるGoogle Fontsの優位性についての以前の議論によれば、もちろんこれは誤解を招くものです。Google Fontsは合理化されたCSSファイルを提供するためにいくつかのスニッフィングメソッドを実行しており、最新のformat()のみを含んでいる。当然のことながら、WOFF2がここでの結果を支配しているのはこの理由によるもので、WOFF2に対するブラウザのサポートは以前からかなり広くなっている。

重要なのは、この特定のデータはまだWOFF2オンリーのケースを支持しているわけではないということですが、魅力的なアイデアであることに変わりはありません。

見えない文字との戦い

デフォルトのWebフォントの読み込み動作である「読み込み中は見えない」(FOITとしても知られています)に対抗するため持っている第一のツールはfont-displayです。font-display: swap@font-faceブロックに追加すると、ウェブフォントが読み込まれている間にフォールバックテキストを表示するようにブラウザに指示する簡単な方法です。

ブラウザ対応もいいですね。Internet ExplorerやChromium以前のEdgeではサポートされていませんが、Webフォントが読み込まれたときにデフォルトでフォールバックテキストをレンダリングしてくれます(ここではFOITは使えません)。Chromeのテストでは、font-displayはどのくらいの頻度で使われているのでしょうか?

26%
図 10. font-displayスタイルを利用しているモバイルページの割合。

私はこれが時間の経過とともに忍び寄ってくることを想定しています、特に今はGoogle Fontsがすべての新しいコードスニペットに font-display を追加していますが彼らのサイトからコピーされています。

Google Fontsを使っているなら、スニペットを更新しよう! Google Fontsを使っていない場合は、font-displayを使いましょう! font-displayについての詳細は MDN を参照してください。

どのようなfont-display値が人気あるのか見てみましょう。

図11. `font-display'の値の使用法。
フォント表示スタイルの利用状況を示す棒グラフ。モバイルページの2.6%がこのスタイルを「swap」、1.5%が「auto」、0.7%が「block」、0.4%が「fallback」、0.2%が「optional」、0.1%が引用符で囲んだ「swap」に設定しているが、これは無効である。デスクトップの分布は、「swap」の利用率が0.4%ポイント低く、「auto」の利用率が0.1%ポイント高くなっている以外は似ている。
図 11. font-displayの値の使用法。

ウェブフォントの読み込み中にフォールバックテキストを表示する簡単な方法として、font-display: swapが最も一般的な値として君臨しています。swapは新しいGoogle Fontsのコードスニペットでもデフォルト値として使われています。いくつかの著名な開発者のエバンジェリストがこれを求めてちょっとした働きかけをしていたので、ここではoptional(キャッシュされた場合にのみレンダリングする)がもう少し使われることを期待していたのですが、駄目でした。

ウェブフォントの数が多すぎる?

ある程度のニュアンスが必要な質問です。フォントはどのように使われているのか? ページ上のコンテンツの量は? そのコンテンツはレイアウトのどこにあるのか? フォントはどのようにレンダリングされているのか? しかし、ニュアンスの代わりに、リクエスト数を中心とした大まかで重い分析に飛び込んでみましょう。

図12. ページあたりのフォント要求の分布。
ページごとのフォント要求の分布を示す棒グラフ。デスクトップでの10、25、50、75、90パーセンタイルは以下の通りです。0、1、3、6、9のフォント要求があります。モバイルの分布は75パーセンタイルと90パーセンタイルまでは同じで、モバイルページでは要求されるフォントが1つ少なくなっています。
図 12. ページあたりのフォント要求の分布。

中央値のウェブページでは、3つのウェブフォントをリクエストしています。90パーセンタイルでは、モバイルとデスクトップでそれぞれ6つと9つのウェブフォントをリクエストしています。

図13. ページあたりに要求されたウェブフォントのヒストグラム。
ページあたりのフォントリクエスト数の分布を示すヒストグラム。最も人気のあるフォントリクエスト数は0で、デスクトップページの22%を占めています。この分布は、1つのフォントを持つページの9%まで落ち込み、2~4つのフォントでは10%で頂点に達し、フォント数が増えるにつれて落ち込んでいきます。デスクトップとモバイルの分布は似ていますが、モバイルの分布はページあたりのフォント数が少ない方にわずかに傾いています。
図 13. ページあたりに要求されたウェブフォントのヒストグラム。

Webフォントのリクエストがデスクトップとモバイルの間でかなり安定しているように見えるというのは非常に興味深いことです。私は、@mediaクエリの中の@font-faceブロックを隠すことを推奨することが流行らなかったのを見てうれしく思います (何も考えないでください)。

しかし、モバイルデバイスでのフォントのリクエストはわずかに多い。ここでの私の勘は、モバイルデバイスで利用できる書体が少ないということはGoogle Fonts CSSでのlocal()のヒット数が少ないということであり、ネットワークからのフォントリクエストに戻ってしまうのではないかと考えています。

この賞を受賞したくない

718
図 14. 1ページで最も多くのWebフォントのリクエストがあった。

最も多くのウェブフォントをリクエストしたページの賞は、718のウェブフォントをリクエストしたサイトに贈られます!

コードに飛び込んだ後、それらの718のリクエストのすべてがGoogle Fontsに向かっています! どうやらWordPress用の「ページの折り返しの上に」最適化プラグインが誤作動して、このサイトで不正を行い、すべてのGoogle Fonts-oopsにリクエストしている(DDoS-ing?)。

パフォーマンス最適化プラグインは、あなたのパフォーマンスをはるかに悪化させることができることを皮肉っています!

Unicode-rangeを使うとより正確なマッチングが可能になります

56%
図 15. unicode-rangeプロパティでWebフォントを宣言しているモバイルページの割合。

unicode-rangeは、ブラウザに、ページがフォントファイルで使用したいコードポイントを具体的に知らせるための優れたCSSプロパティです。@font-face宣言にunicode-rangeがある場合、ページ上のコンテンツは、フォントが要求される前に、その範囲内のコードポイントのいずれかにマッチしなければなりません。これは非常に良いことです。

Google FontsはそのCSSのほとんど(すべてではないにしても)でunicode-rangeを使用しているので、これもGoogle Fontsの使用状況によって偏っていると予想される指標です。ユーザーの世界でこれはあまり一般的でないと思いますが、Web Almanacの次の版ではGoogle Fontsのリクエストをフィルタリングして除外することが可能かもしれません。

システムフォントが存在する場合、ウェブフォントを要求しないようにする

59%
図 16. local()プロパティでWebフォントを宣言しているモバイルページの割合。

local()@font-facesrcのシステムフォントを参照するための良い方法です。もし local()フォントが存在するならば、ウェブフォントを要求する必要は全くありません。これはGoogle Fontsによって広く使われており、論争の的にもなっているのでユーザの土地からパターンを得ようとしているのであれば、これも歪んだデータの一例になるでしょう。

ここでは、私よりも賢い人々(TypeKitのBram Stein氏) が、インストールされているフォントのバージョンが古くて信頼性は低い場合があるため、local()を使うことは予測不可能である可能性があると述べていることにも注目しておきましょう。

縮約されたフォントとfont-stretch

7%
図 17. font-stretch プロパティを持つスタイルを含むデスクトップページとモバイルページの割合。

歴史的に、font-stretchはブラウザのサポートが悪く、よく知られた@font-faceプロパティではありませんでした。詳しくはMDNのfont-stretchについて を参照してください。しかし、ブラウザのサポートは広がっています。

小さいビューポートで凝縮されたフォントを使用することで、より多くのテキストを表示できるようになることが示唆されていますが、このアプローチは一般的には使用されていません。とはいえ、このプロパティがモバイルよりもデスクトップで半パーセントポイント多く使われているというのは予想外で、7%というのは私が予想していたよりもはるかに高いと思えます。

可変フォントは未来のもの

可変フォントでは、1つのフォントファイルに複数のフォントの太さやスタイルを含めることができます。

1.8%
図 18. 可変フォントを含むページの割合

1.8%でさえ、これは予想よりも高かったが、これがうまくいくのを見て興奮している。Google Fonts v2には可変フォントのサポートがいくつか含まれています。

図19. 'font-variation-settings'軸の使用法。
font-variation-settingsプロパティの使用状況を示す棒グラフ。デスクトップページのプロパティの42%が"opsz"の値に設定されており、32%が"wght"、16%が"wdth"、2%以下が"roun"、"crsb"、"slnt"、"inln"などに設定されています。デスクトップページとモバイルページで顕著な違いは、"opsz"の使用率が26%、"wght"の使用率が38%、"wdth"の使用率が23%となっており、"wght"の使用率は、"wght"の使用率と"wght"の使用率の差が大きい。
図 19. font-variation-settings軸の使用法。

この大規模なデータセットのレンズを通して見ると、これらの結果は非常に低いサンプルサイズであることがわかります。しかし、デスクトップページで最も一般的な軸としてopszが注目され、wghtwdthが後に続く。私の経験では、可変フォントの入門デモはたいていウェイトベースです。

カラーフォントも未来かも?

117
図 20. カラーフォントを含むデスクトップウェブページの数。

これらのここでの使用法は基本的に存在しませんが、詳細についてはカラーフォント! WTF?という優れたリソースをチェックできます。フォント用のSVGフォーマット(これは良くないし消えていく)に似ていますが(全くそうではありません)、これを使うとOpenTypeファイルの中にSVGを埋め込むことができ、これは素晴らしくクールです。

結論

ここでの最大の収穫は、Google Fontsがウェブフォントの議論を支配しているということだ。彼らが取ったアプローチは、ここで記録したデータに大きく影響している。ここでのポジティブな点はウェブフォントへのアクセスが容易であること、優れたフォントフォーマット(WOFF2)であること、そして自由なunicode範囲の設定が可能であることだ。ここでの欠点はサードパーティのホスティング、異なるホストからのリクエスト、およびpreloadにアクセスできないことでパフォーマンスが低下することです。

私は、将来的には「バリアブルフォントの台頭」を見ることになるだろうと完全に予想しています。バリアブルフォントは複数の個々のフォントファイルを1つの合成フォントファイルに結合するので、これはウェブフォントのリクエストの減少と対になっているはずです。しかし歴史が示しているように、ここで通常起こることは、あるものを最適化してその空所を埋めるためにさらに多くのものを追加してしまうことです。

カラーフォントの人気が高まるかどうかは非常に興味深いところです。私は、これらは可変フォントよりもはるかにニッチなものになると予想していますが、アイコンフォントのスペースに生命線を見ることができるかもしれません。

フォントを凍らせるなよ。

著者