フォント
序章
ウェブフォントは、ウェブ上で美しく機能的なタイポグラフィを可能にします。ウェブフォントを使用することは、デザインに力を与えるだけでなく、デザインのサブセットを民主化します。しかし、どんなに良いことがあってもウェブフォントが適切に読み込まれていないと、サイトのパフォーマンスに大きな悪影響を及ぼすこともあります。
それらはウェブにとってプラスになるのか? それらは害よりも多くの利益を提供しているか? Web標準の牛道は、デフォルトでWebフォントの読み込みのベストプラクティスを奨励するために十分に舗装されているだろうか? そうでない場合、何を変える必要があるのでしょうか? 今日のウェブ上でウェブフォントがどのように使用されているかを調べることで、これらの疑問に答えられるかどうかをデータ駆動型で覗いてみましょう。
そのウェブフォントはどこで手に入れたの?
最初の、そして最も顕著な問題は、パフォーマンスです。パフォーマンスに特化した章がありますが、ここではフォント固有のパフォーマンスの問題について少し掘り下げてみましょう。
ホストされたWebフォントを使用すると、実装やメンテナンスが容易になりますが、セルフホスティングは最高のパフォーマンスを提供します。Webフォントはデフォルトで、Webフォントの読み込み中にテキストを非表示にする(Flash of Invisible Text、またはFOITとしても知られています)ことを考えると、Webフォントのパフォーマンスは画像のような非ブロッキング資産よりも重要になる可能性があります。
フォントは同じホストでホストされているのか、それとも別のホストでホストされているのか?
サードパーティのホスティングに対するセルフホスティングの差別化は、HTTP/2の世界ではますます重要になってきています。同一ホストのリクエストには、ウォーターフォール内の他の同一ホストのリクエストに対して優先順位をつける可能性が高いという大きな利点があります。
別のホストからウェブフォントを読み込む際のパフォーマンスコストを軽減するための推奨事項としては、preconnect
、dns-prefetch
、preload
リソースのヒントの使用がありますが、優先度の高いウェブフォントは、ウェブフォントのパフォーマンスへの影響を最小限に抑えるため、同一ホストからのリクエストにすべきです。これは視覚的に、非常に目立つコンテンツやページの大部分を占める本文コピーで使用されるフォントへ対して特に重要です。
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% |
ここでのGoogle Fontsの優位性は、同時に驚くべきことであると同時に意外性のないものであった。期待していたという点では予想外でしたが、サービスの圧倒的な人気の高さには驚きました。フォントリクエストの75%というのは驚異的だ。TypeKitは一桁台の遠い2位で、Bootstrapライブラリがさらに遠い3位を占めていました。
ここでのGoogle Fontsの使用率の高さは非常に印象的だが、Google Fonts<link>
要素を含むページが29%しかなかったことも注目に値する。これはいくつかのことを意味しているかもしれない。
- ページがGoogle Fontsを使用する場合、彼らはGoogle Fontsを多く使用しています。それらは結局のところ、金銭的なコストなしで提供されています。おそらく、人気のあるWYSIWYGエディタで使われているのではないでしょうか? これは非常に可能性の高い説明のように思えます。
- あるいは、もっとありそうにない話としては、多くの人が
<link>
の代わりに@import
を使ってGoogle Fontsを使っているということかもしれません。 -
あるいは、超ありえないシナリオにまで踏み込んでみたいのであれば、多くの人が代わりにHTTP
Link:
ヘッダーを使ってGoogle Fontsを使っているということになるかもしれません。
Google Fontsのドキュメントでは、Google Fonts CSSの<link>
はページの<head>
の最初の子として配置することを推奨しています。これは大きなお願いです! 実際、これは一般的でありません。全ページの半分のパーセント(約20,000ページ)しかこのアドバイスを受けていないので、これは一般的でありません。
さらに言えば、ページがpreconnect
やdns-prefetch
を<link>
要素として使用している場合、これらはいずれにしてもGoogle Fonts CSSの前へ来ることになります。これらのリソースのヒントについては、続きを読んでください。
サードパーティホスティングの高速化
上述したように、サードパーティホストへのウェブフォント要求を高速化する超簡単な方法は、preconnect
リソースヒントを使用することです。
うわー! 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% |
ここでの上位のエントリがGoogle Fontsの人気順フォント一覧と非常によく似ていることは驚くに値しません。
どのようなフォント形式を使用していますか?
今日のブラウザではWOFF2はかなりサポートされています。Google FontsはWOFF2というフォーマットを提供していますが、これは前身のWOFFよりも圧縮率が向上したフォーマットで、それ自体はすでに他の既存のフォントフォーマットよりも改善されていました。
私から見れば、ここでの結果を見て、WebフォントはWOFF2オンリーにした方がいいという意見もあるかもしれません。二桁台のWOFF使用率はどこから来ているのでしょうか? もしかして、まだWebフォントをInternet Explorerに提供している開発者がいるのでしょうか?
第3位のoctet-stream
(およびもう少し下のplain
)は、多くのウェブサーバが不適切に設定されており、ウェブフォントファイルのリクエストで誤ったMIMEタイプを送信していることを示唆しているように見えます。
もう少し深く掘り下げて、@font-face
宣言のsrc:
プロパティで使われているformat()
の値を見てみましょう。
SVGフォントが衰退しているのを見て期待していたのですが。バグだらけだし、Safari以外のブラウザでは実装が削除されている。そろそろ捨ててしまおうか。
ここのSVGデータポイントを見ると、どのMIMEタイプでSVGフォントを提供しているのか気になります。図6.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% |
このデータセットは、大多数の人がすでに@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
はどのくらいの頻度で使われているのでしょうか?
私はこれが時間の経過とともに忍び寄ってくることを想定しています、特に今はGoogle Fontsがすべての新しいコードスニペットに font-display
を追加していますが彼らのサイトからコピーされています。
Google Fontsを使っているなら、スニペットを更新しよう! Google Fontsを使っていない場合は、font-display
を使いましょう! font-display
についての詳細は MDN を参照してください。
どのようなfont-display
値が人気あるのか見てみましょう。
ウェブフォントの読み込み中にフォールバックテキストを表示する簡単な方法として、font-display: swap
が最も一般的な値として君臨しています。swap
は新しいGoogle Fontsのコードスニペットでもデフォルト値として使われています。いくつかの著名な開発者のエバンジェリストがこれを求めてちょっとした働きかけをしていたので、ここではoptional
(キャッシュされた場合にのみレンダリングする)がもう少し使われることを期待していたのですが、駄目でした。
ウェブフォントの数が多すぎる?
ある程度のニュアンスが必要な質問です。フォントはどのように使われているのか? ページ上のコンテンツの量は? そのコンテンツはレイアウトのどこにあるのか? フォントはどのようにレンダリングされているのか? しかし、ニュアンスの代わりに、リクエスト数を中心とした大まかで重い分析に飛び込んでみましょう。
中央値のウェブページでは、3つのウェブフォントをリクエストしています。90パーセンタイルでは、モバイルとデスクトップでそれぞれ6つと9つのウェブフォントをリクエストしています。
Webフォントのリクエストがデスクトップとモバイルの間でかなり安定しているように見えるというのは非常に興味深いことです。私は、@media
クエリの中の@font-face
ブロックを隠すことを推奨することが流行らなかったのを見てうれしく思います (何も考えないでください)。
しかし、モバイルデバイスでのフォントのリクエストはわずかに多い。ここでの私の勘は、モバイルデバイスで利用できる書体が少ないということはGoogle Fonts CSSでのlocal()
のヒット数が少ないということであり、ネットワークからのフォントリクエストに戻ってしまうのではないかと考えています。
この賞を受賞したくない
最も多くのウェブフォントをリクエストしたページの賞は、718のウェブフォントをリクエストしたサイトに贈られます!
コードに飛び込んだ後、それらの718のリクエストのすべてがGoogle Fontsに向かっています! どうやらWordPress用の「ページの折り返しの上に」最適化プラグインが誤作動して、このサイトで不正を行い、すべてのGoogle Fonts-oopsにリクエストしている(DDoS-ing?)。
パフォーマンス最適化プラグインは、あなたのパフォーマンスをはるかに悪化させることができることを皮肉っています!
Unicode-range
を使うとより正確なマッチングが可能になります
unicode-range
は、ブラウザに、ページがフォントファイルで使用したいコードポイントを具体的に知らせるための優れたCSSプロパティです。@font-face
宣言にunicode-range
がある場合、ページ上のコンテンツは、フォントが要求される前に、その範囲内のコードポイントのいずれかにマッチしなければなりません。これは非常に良いことです。
Google FontsはそのCSSのほとんど(すべてではないにしても)でunicode-range
を使用しているので、これもGoogle Fontsの使用状況によって偏っていると予想される指標です。ユーザーの世界でこれはあまり一般的でないと思いますが、Web Almanacの次の版ではGoogle Fontsのリクエストをフィルタリングして除外することが可能かもしれません。
システムフォントが存在する場合、ウェブフォントを要求しないようにする
local()
は@font-face
、src
のシステムフォントを参照するための良い方法です。もし local()
フォントが存在するならば、ウェブフォントを要求する必要は全くありません。これはGoogle Fontsによって広く使われており、論争の的にもなっているのでユーザの土地からパターンを得ようとしているのであれば、これも歪んだデータの一例になるでしょう。
ここでは、私よりも賢い人々(TypeKitのBram Stein氏) が、インストールされているフォントのバージョンが古くて信頼性は低い場合があるため、local()
を使うことは予測不可能である可能性があると述べていることにも注目しておきましょう。
縮約されたフォントとfont-stretch
歴史的に、font-stretch
はブラウザのサポートが悪く、よく知られた@font-face
プロパティではありませんでした。詳しくはMDNのfont-stretch
について を参照してください。しかし、ブラウザのサポートは広がっています。
小さいビューポートで凝縮されたフォントを使用することで、より多くのテキストを表示できるようになることが示唆されていますが、このアプローチは一般的には使用されていません。とはいえ、このプロパティがモバイルよりもデスクトップで半パーセントポイント多く使われているというのは予想外で、7%というのは私が予想していたよりもはるかに高いと思えます。
可変フォントは未来のもの
可変フォントでは、1つのフォントファイルに複数のフォントの太さやスタイルを含めることができます。
1.8%でさえ、これは予想よりも高かったが、これがうまくいくのを見て興奮している。Google Fonts v2には可変フォントのサポートがいくつか含まれています。
この大規模なデータセットのレンズを通して見ると、これらの結果は非常に低いサンプルサイズであることがわかります。しかし、デスクトップページで最も一般的な軸としてopsz
が注目され、wght
とwdth
が後に続く。私の経験では、可変フォントの入門デモはたいていウェイトベースです。
カラーフォントも未来かも?
これらのここでの使用法は基本的に存在しませんが、詳細についてはカラーフォント! WTF?という優れたリソースをチェックできます。フォント用のSVGフォーマット(これは良くないし消えていく)に似ていますが(全くそうではありません)、これを使うとOpenTypeファイルの中にSVGを埋め込むことができ、これは素晴らしくクールです。
結論
ここでの最大の収穫は、Google Fontsがウェブフォントの議論を支配しているということだ。彼らが取ったアプローチは、ここで記録したデータに大きく影響している。ここでのポジティブな点はウェブフォントへのアクセスが容易であること、優れたフォントフォーマット(WOFF2)であること、そして自由なunicode範囲
の設定が可能であることだ。ここでの欠点はサードパーティのホスティング、異なるホストからのリクエスト、およびpreload
にアクセスできないことでパフォーマンスが低下することです。
私は、将来的には「バリアブルフォントの台頭」を見ることになるだろうと完全に予想しています。バリアブルフォントは複数の個々のフォントファイルを1つの合成フォントファイルに結合するので、これはウェブフォントのリクエストの減少と対になっているはずです。しかし歴史が示しているように、ここで通常起こることは、あるものを最適化してその空所を埋めるためにさらに多くのものを追加してしまうことです。
カラーフォントの人気が高まるかどうかは非常に興味深いところです。私は、これらは可変フォントよりもはるかにニッチなものになると予想していますが、アイコンフォントのスペースに生命線を見ることができるかもしれません。
フォントを凍らせるなよ。