部 I 章 1

フォント

公開日：2026/05/13

Web Almanacのキャラクターが組立ラインに並び、さまざまなスタイルと形のFの文字を準備しているヒーロー画像。

Charles Berret によって書かれた。

Bram Stein と José Solé によってレビュ。

Charles Berret と Ivan Ukhov による分析。

Chris Lilley 編集。

Sakae Kotaro によって翻訳された。

はじめに

HTTP Archiveが2011年にウェブタイポグラフィのデータ収集を開始した当初、カスタムウェブフォントの使用率は一桁台前半に過ぎませんでした。当時、@font-face を使ってセルフホストのフォントを配信したり、Typekit、Fonts.com、Google Web Fontsなどのサービスを利用したりしていたウェブサイトは、わずか約3〜5%でした。2011年当時の残りのサイトはすべて、ユーザーのデバイスで利用可能な少数の「ウェブセーフ」なシステムフォント（Arial、Courier、Timesなど）のみを使用していました。

デザイナーたちがカスタムタイポグラフィによってビジュアルアイデンティティを他のサイトと差別化できると気づくと、ウェブフォントは急速に標準となっていきました。2015年までにウェブフォントはウェブサイトの半数以上で使用されるようになり、2020年には約75%の普及率に達しました。現在、問われるのはウェブサイトがウェブフォントを使用するかどうかではなく、どの書体を表示し、フォント機能を使って表現の可能性を最大限に引き出しているかどうかです。

同時に、フォントの配信方法も変化しています。サードパーティのCDNにのみ依存するのではなく、フォントファイルをセルフホストすることを選ぶサイトが増えており、多くのサイトが両方のアプローチを組み合わせて使用しています。昨年のデータでは、セルフホスト専用の利用が明確に増加し、セルフホストと外部サービスを組み合わせるサイトが減少傾向にあることが示されており、このトレンドが2025年も続いているかどうかを調査します。

この章では、現在のウェブタイポグラフィのいくつかの側面を探ります。どのプロバイダーが最大のシェアを持つか、フォントがどのように読み込まれ速度のために最適化されるか、実際のCSS実装でどの書体がリードしているか、非ラテン文字スクリプトがどのように扱われるか、そして可変フォントとカラーフォントがウェブタイポグラフィの未来にとって何を意味するかを考察します。

ウェブフォントの使用状況

ウェブフォントの使用は増加を続けていますが、ウェブ全体（最大のCJK文字セットを除く）でウェブフォントの普及が飽和に近づくにつれ、その成長は自然と鈍化しています。

88%

図1.1. ウェブフォントを使用しているモバイルページの割合。

2025年には、ウェブフォントは約88%のウェブサイトで見られ、2024年の約87%からわずかに増加しました。（ここでの指標は、ウェブフォントファイルをリクエストするページのシェアであり、実質的にウェブフォントを使用しているウェブサイトの割合を表しています。）

この広範な使用状況は、開発者がコアシステムフォントのみに限定されていた時代からウェブタイポグラフィがいかに進化したかを示しています。ただし、注目すべき少数派（約12%のサイト）はいまだに古いデフォルトフォントを使い続けています。

ホスティングとサービス

今年のWeb Almanacクロールにより、セルフホスティングがウェブフォント配信において最も広く普及した手段であることが確認されました。約72%のウェブサイト（デスクトップ・モバイルともに）が、セルフホスティング専用または自己ホストと外部ホストの組み合わせで、少なくとも1つのフォントファイルを自社のオリジンから提供しています。この数字は昨年より1ポイント強高く、2022年比では約4〜5ポイント高く、着実な増加を示しています。つまり、2022年に顕著になったセルフホスティングの増加は今なお続いています。

この72%の内訳として、2つの重要なグループが挙げられます。

セルフホスト専用フォント: デスクトップサイトの約31.5%、モバイルサイトの約36.4%が、セルフホストフォントのみを使用しています（サードパーティのフォントサービスは一切使用なし）。これらを平均すると、2025年には全サイトの約3分の1がセルフホスティングのみに依存しています（昨年の約30%から増加）。これは大きな変化であり、クリティカルパスから外部プロバイダーを排除し、すべてのフォントを自社ホストする決断をしたサイトが増えています。
ミックスホスティング（セルフホスティング＋サービス）: デスクトップサイトの36.1%、モバイルサイトの31.7%が、同一ページでセルフホストフォントとフォントサービスを組み合わせて使用しています。これらのほとんどの場合、サービスはGoogle Fontsで、アイコンCDNや別のソースが追加されることもあります。この「ハイブリッド」アプローチは昨年（2024年のデスクトップ約38.5%、モバイル約32.7%）よりやや一般的でしたが、一部のサイトがセルフホスティングへ完全移行したため、若干減少しています。

これらのグループを合わせると、約72%のサイトが何らかの形でセルフホストしています。残りの約28%のサイトは、フォントをサードパーティサービスに完全依存しており（そのカテゴリでは断然Google Fontsが最も選ばれています）。

ウェブフォントサービス

セルフホスティングの成長にもかかわらず、ホスト型フォントCDNはGoogleの圧倒的な存在感により、依然として全ウェブサイトの約半数に表示されています。今年のクロールでは、Google FontsはデスクトップサイトのはGoogleのAPIを使ってフォントを取得しているサイトすべてをカウントしており、Googleが唯一のソースであるか他のソースと一緒に使用されているかを問いません。）デスクトップにおけるGoogleのリーチは、2024年の57%から約3パーセントポイント低下し、2022年比では約6ポイント低下しており、セルフホスティングへのシフトを反映しています。モバイルでは、Googleのシェアはわずかにしか低下しておらず（昨年比約0.3ポイント、2022年比約4ポイント）、全体的なパターンは2024年に指摘されたものと同じです。Google Fontsは依然として多くのサイトでデフォルトの選択肢ですが、より多くのサイトがセルフホストするにつれて、その優位性は徐々に低下しています。

他のフォントホスティングサービスは比較すると非常に小規模です。Adobe Fonts（旧Typekit）は再び緩やかな成長を見せました。2025年には、デスクトップサイトの約4.2%、モバイルサイトの約3.5%がAdobe Fontsを使用しており（合計で約3.8%）、昨年の約4.1%から増加しています。これはウェブ全体では小さなシェアですが、実質的な成長（2年間で10〜11%の相対的増加）を示しています。

人気のアイコンフォントCDNであるFont Awesomeは緩やかな減少傾向にあります。2022年には約4.4%のサイトで使用され、2024年には4.0%、2025年には約3〜4%のサイトに減少しています。この減少は、多くのサイトがインラインSVG、アイコンスプライトシート、セルフホストアイコンセットなど代替のアイコンソリューションに移行していること、またパフォーマンス上の理由から大きなアイコンフォントの読み込みを避ける開発者がいることが原因と考えられます。それでも、約25サイトに1サイトでFont Awesomeが継続的に使用されていることは重要であり、それに匹敵するリーチを持つ単一のフォントファミリー（アイコンまたはテキスト）はほとんどありません。

その他のサービスは、ウェブ規模ではほぼ無視できる程度です。MonotypeのFonts.com、Extensis、Cloud.Typography、Type Networkなどのレガシーサービスはそれぞれ1%未満のサイトにしか対応していません。これらの多くはクロールデータでほぼ見えなくなるほど減少しています。実際問題として、2025年にウェブサイトがホスト型フォントサービスを使用している場合、ほぼ確実にGoogle Fontsです。Adobe FontsやFont Awesomeである可能性は低く、それ以外である可能性はさらに低いです。

フォントホスティングの組み合わせ

ほとんどのサイトがウェブタイポグラフィに1つのソースだけを使用していないため、どのように配信を組み合わせているかを見ることは有益です。実際にはウェブはいくつかの予測可能な組み合わせ（セルフホスティングのみ、Googleのみ、またはその2つのハイブリッド）に収束しています。

Google Fontsとセルフホストフォントの組み合わせ: デスクトップサイトの約36%、モバイルサイトの約32%が使用。このハイブリッドアプローチは非常に一般的です。例えば、サイトがブランドやアイコンフォントをセルフホストしながら、本文テキスト用にGoogle ホストのフォントを使用する（またはその逆）といったケースです。
セルフホストフォントのみ: デスクトップサイトの約32%、モバイルサイトの約36%が使用（全体では約34%）。ページ上のすべてのカスタムフォントがサイト自身のドメインから提供されることを意味します。前述のように、このシェアは昨年の約30%から今年は全サイトの約3分の1まで成長しています。
Google Fontsのみ: デスクトップサイトの約13%、モバイルサイトの約12%が使用。これらのサイトはフォントのニーズをGoogleのCDNに独占的に依存しています（多くの場合、GoogleのスタイルシートへのStandardの <link> を通じて）。

これら3つの構成が合わさって、全ウェブサイトの約5分の4を占めています。その他の組み合わせ（GoogleとAdobeの併用、AdobeとセルフホスティングなMど）は、クロールデータではすぐに希少になります。実際、上位のパターンを超えると、特定の組み合わせのシェアは1%を下回り、8番目や10番目に一般的な構成になると、その使用状況はほぼ知覚不可能（サイトの約0.05%）になります。

これらの一般的なサービスの組み合わせを超えて、年々バランスはセルフホスティングへと傾いています。2024年には約30%のサイトが専用セルフホストでしたが、現在は約34%です。対応して、「ミックス」アプローチ（セルフホスティング＋サービス）は若干縮小しています（例えば、デスクトップでは約38%から約36%）。つまり、両方を行うことで保険をかけるサイトは減少し、すべてを自社ホストすることを決定したサイトが増えています。これはパフォーマンスとプライバシーの動機によるものと考えられます。昨年の章で指摘されたように、キャッシュパーティショニングなど現代のブラウザの変更が、Google CDNを使用することの古いパフォーマンス上の優位性を取り除きました。

フォントファイルのホスティング

フォントホスティングを見る別の方法として、どの特定のフォントファイルが最もリクエストされているか、またそれらがセルフホスティングからかサービスからかを確認することが挙げられます。これにより、ウェブで最も人気のあるフォントファミリーとその配信方法についての洞察が得られます。

セルフホスト側では、トラフィックはアイコンフォントファイルと一般的なライブラリアセットに集中しています。Font Awesome（アイコンセットのTTF/WOFFファイル）のローカルコピーは、2025年のクロールではデスクトップのフォントリクエストの約8.5%、モバイルのフォントリクエストの約9.3%を占めています。これにより、Font Awesomeはテキスト書体ではなくアイコンセットであるにもかかわらず、ウェブで最も頻繁にフェッチされるフォントリソースの1つとなっています。注目すべきことに、Font Awesomeの使用のほとんどはセルフホスティング経由であり、fontawesome.com CDNから直接フェッチされる割合はずっと少ないです。その他の人気のユーティリティフォントも同様のパターンを示しています。例えば、IcoMoon（別のアイコンフォントジェネレーターの出力）はデスクトップの約1.0%、モバイルのフォントリクエストの1.1%を占め、ETmodules（WordPressテーマでよく見られる）はデスクトップで約0.5%、モバイルで0.7%です。これらもほぼ常に、それらを使用するサイトに常駐するセルフホストフォントです。実際には、ウェブ上でのこの「セルフホスティング」のセグメントは、オーダーメイドのテキストフォントのセルフホスティングだけでなく、これらの一般的なアイコン/フォントアセットを自サイトのファイルにバンドルすることについてです。

Google Fonts側では、フォントリクエストは典型的なロングテール分布を示しています。先頭にある少数の非常に人気のあるフォントと、使用率が低い多くのフォントです。デスクトップでは、Robotoが単一で最もリクエストされるGoogle ホストのフォントであり、すべてのGoogle フォントリクエストの約9.2%を占めています。その直後にNoto Sans JP（日本語）があり、Googleのリクエストの約7.1%を占めています。これはGoogleのリーチがいかにグローバルであるかを即座に示しています。上位2つのフォントのうち1つはラテン/英語のUIフェイスで、もう1つは日本語フォントです。その下のリストは2025年に予想される通りです。Poppins（デスクトップでのGoogle フォントリクエストの約3.8%）、Open Sans（デスクトップでGoogle経由で約3.3%）、Lato（約2.0%）、Montserrat（約1.9%）。モバイルでは順序がわずかに変わります。Noto Sans JPが実際には約6.4%で1位であり、Robotoは4.1%ですが、Poppins（約4.1%）、Open Sans（約3.7%）、Lato（約2%）、Montserrat（約2.2%）はすべて同じトップグループにいます。要するに、Google Fontsの最大量フォントには、広く使用されているラテン系ファミリーと重要な非ラテン系フォント（特にCJKスクリプト）の両方が含まれています。

これらのフォントのうち、どれがセルフホストされる傾向があり、どれがGoogleから提供される傾向があるかを注目するのは興味深いことです。例えば、Noto Sans JP（大きな日本語フォント）は、データではほぼ完全にGoogleのCDNによって提供されています。Noto Sans JPのセルフホスト率はリクエストのわずか約0.2%であり、そのフォントを使用するほぼすべてのユーザーがGoogleに配信を任せることを選んでいることを意味します（おそらく非常に大きなファイルで、Googleのインフラがそのために最適化されているためです）。Noto Serif JPも同様で、リクエストの約1.3〜1.4%に表示されます（ほとんどがGoogle ホスト）。対照的に、多くの人気のラテン文字系ファミリーはGoogleによって提供される使用量に加えて、セルフホスト分もかなり存在します。Robotoもセルフホストされています（デスクトップのフォントリクエストの約2.2%がセルフホストのRobotoファイル用で、Googleからの9.2%に加えて）。同様に、Poppinsは約2.0%がセルフホスト、Open Sanは約1.7%、Montserratは約1.4%、Latoは約1.0%、Interは約0.9%がセルフホスト（デスクトップ数値）。これらの各ケースでは、同じフォントが多くのサイトでGoogleによっても配信されています。最も人気のあるGoogle Fonts（Roboto、Open Sans、Poppins、Montserrat、Lato、Inter）がセルフホストデータでも無視できない率で表示されること、そしてセルフホスティングが成長しGoogleのシェアが緩和されていることから、多くのプロジェクトがGoogle Fontsから始めてパフォーマンスやプライバシー上の理由から同じファミリーを社内に取り込む可能性が高いです。（注：データは重複と方向性のシフトを示せますが、サイトごとの移行パスは示せません。）

Adobe Fontsは、キットが必要で多様な独自の商用フォントを提供する別種のサービスであるため、異なるプロファイルを持っています。単一のAdobe提供フォントがシェアを独占していません。2025年のトップAdobe フォントファミリーはProxima Novaで、デスクトップとモバイル両方のフォントリクエストの約0.8〜0.9%を占めています。その下では、Adobeのトラフィックは長いファミリーリストに分散しています。これらは主にFutura PT、Brandon Grotesque、Freight Sans、Acumin、Sofia Pro、Aktiv Grotesk、Museoなどの人気のブランディングおよび編集向けフェイスで、それぞれリクエストの数百分の一パーセントから半パーセント程度を占めています。これはAdobe Fontsが一般的にどのように位置づけられているかと一致しています。何百万ものサイトで1つのフォントが見つかるというよりも、それぞれ比較的少数のサイトで使用される非常に優れたフォントを幅広く提供しています。これは本質的にGoogleのパターンとは逆であり、Googleでは少数のフォントが使用量の大部分を占めています。

パフォーマンス

2025年のウェブにおけるタイポグラフィのパフォーマンスは、ウェブフォントをできるだけ小さく、クリーンな形で配信することに重点が置かれています。このセクションでは、最も重要な2つのパフォーマンスの要素を見ていきます。フォーマット（ウェブは基本的にWOFF2に集約し、WOFFがフォールバックとして残っている）と、それらのフォーマットが生み出す実際の転送サイズ（中央値は十分に合理的ですが、ロングテールは本当に遅くなる可能性がある）です。これらの結果をウェブフォントの衛生チェックリストとして読む場合は、WOFF2を使用し、MIMEタイプを確認し、必要に応じて大きなフォントをサブセット化し、セルフホストしている場合は特に注意してください。そこに非効率性のほとんどがまだ存在しています。

ファイル形式と最適化

ウェブでのフォントファイル形式に関しては、モダンなWOFF2フォーマットが引き続きリードしています。WOFF2（Web Open Font Format 2）は優れた圧縮を提供し、より速い転送のためにファイルサイズが小さくなり、すでに何年もすべての主要なブラウザでサポートされています。2025年には、WOFF2はデスクトップとモバイルページの両方でフォントファイルリクエストの約65%を占めています。これは現代のフォントフォーマットの圧倒的多数であり、ウェブの標準フォントフォーマットとしてのWOFF2への継続的な集約を表しています。言い換えれば、今年のデータのすべてのウェブフォントの約3分の2がWOFF2フォーマットです。WOFF2への集約は、より優れた圧縮がより速いフォントの読み込みとより少ない帯域幅の使用につながるため、パフォーマンスにとっての良い傾向です。

WOFF2のすぐ後ろには古いWOFF 1.0フォーマットがあり、依然として重要なフォールバックです。2025年には、WOFF 1.0はデスクトップとモバイルの両方でフォントリクエストの約16%を占めています。WOFF2の65%のシェアと合わせると、2つのWOFFフォーマットが合計でフォントリクエスト全体の約81%を占めています。これはWOFF2を主要フォーマットとした継続的な集約を反映しており、WOFF 1.0は主にレガシーおよび互換性のケースのために残っています。WOFF2の広範なブラウザサポートによってほぼすべてのユースケースがカバーされているため、より多くのサイトやフォントプロバイダーがWOFFからWOFF2に移行しています。WOFFは2010年代初頭に導入された当時は大きな改善でしたが、現在では主に古いブラウザや長期間フォントファイルを更新していないサイトで使用される、主にレガシーのフォールバックとなっています。

WOFFとWOFF2を超えると、ほとんどがエッジケースとして残るのはマイナーなフォーマットだけです。以下で述べるように、来年のIncremental Font Transfer技術の登場は大きなフォントにとって特に価値のある改善となり、WOFF2のシェアを削り始める可能性があります。それでも、注目すべき割合のフォントが依然として生のTrueType（.ttf）ファイルとして提供されています。2025年には、フォントリクエストの約6.7%がTTFであり、多くの場合、元のフォントファイルをWOFFとして再パッケージせずに提供するCDNやセルフホスティングのセットアップによるものです。同様に、フォントリクエストの約6.6%が汎用の application/octet-stream MIMEタイプで配信されています。octet-streamは独自のフォントフォーマットではないことに注意してください。これは通常、サーバーが適切なフォントMIMEを指定していない設定ミスを示します（例えば、WOFF2ファイルが正しい font/woff2 の代わりに Content-Type: application/octet-stream で提供されるかもしれません）。2025年にも、この設定ミスのMIME問題が残念ながら続いており、フォントファイルの約6〜7%が依然として誤ったMIMEタイプで送信されています。これは主に、設定の問題を持つ少数の主要ホスト（昨年の分析ではcdnjsとWixのCDNが顕著な問題サイトでした）によるものです。font/woff2 や font/woff などの正しいMIMEタイプを使用することでコンテンツの処理とデバッグが改善されるため、これは小さいながらも注目すべきスライスです。

重要なのは、モダンなフォーマットを組み合わせると、WOFF2 + WOFFがウェブフォントエコシステムの5分の4以上を占めることです。OpenType/CFF（.otf）やSVGフォントなどの他のフォーマットはデスクトップでは健在ですが、公共ウェブからは事実上消えており、EOT（旧IE固有のフォーマット）はほぼ絶滅しています。2020年に、Web AlmanacはすでにSVGとEOTがほぼなくなったと指摘しており、その傾向は続いています。典型的なサイトのクロールで非WOFFフォントファイルに遭遇することは今や稀です。圧倒的なアドバイスは変わりません。ウェブフォントにはWOFF2を使用し、特定のニーズがない限り古いフォーマットは廃止してください。今年のクロールデータは、ほぼすべての人がWOFF2に収束し、WOFFをトレーリングフォールバックとして使用し、その他はすべて無視できる程度であることを強く裏付けています。

ファイルサイズとパフォーマンス

パフォーマンスの観点から、モダンなフォーマットを使用することは重要です。なぜならフォントファイル自体が平均的に大きくなってきているからです。昨年の分析では、ウェブフォントファイルの中央値サイズが以前の年と比べてかなり増加しており、サイトがより複雑なフォント（例えば、複数の言語をサポートするためにより多くのグリフを持つフォントや、多くのスタイルをバンドルする可変フォント）を使用していることを示唆していました。2025年のデータは、このより大きなフォントファイルへの傾向が続いており、最適化がさらに重要であることを示しています。

ウェブでのフォント転送サイズの分布を見ると：

2024年には、フォントファイルの中央値サイズは約36〜39 KB（gzip圧縮）で、2年前の30 KB台前半から増加しています。2025年には、中央値は引き続き30 KB台後半から40 KB台前半の範囲（デスクトップでは30 KB台中盤、モバイルではわずかに高い）にあり、典型的なフォントファイルが過去1年でそれほど成長していないことを示しています。より大きなサイズでの横ばいとなっています。
75パーセンタイルでは、2024年のフォントファイルは約76〜77 KBでした。2025年では、これは概ね同様（70 KB台中盤）です。したがって、ウェブフォントの4分の3が80 KB未満であり、特にWOFF2圧縮でも依然として管理可能です。
ただし、90パーセンタイルでは、2024年にはフォントファイルが約112〜116 KBでした。2025年のクロールでは、90パーセンタイルが115〜116 KBの範囲で同様です。したがって、フォントのトップ10%はかなり大きく（100 KBをはるかに超えています）。これらは複雑なスクリプト用のフォント（何千ものグリフを持つCJKフォント）、多くの軸を持つフル機能の可変フォント、または単にサブセット化されていないファイルである傾向があります。
分布の末尾は非常に重くなっています。99パーセンタイルでは、2024年のデスクトップのフォントファイルは約776 KB（モバイルでは572 KB）でした。2025年では、最大の1%のフォントは依然として数百キロバイトの範囲にあります。これらはおそらく大規模なCJKフォント、埋め込みグラフィックを持つアイコンフォント、またはデバッグテーブルが誤って含まれたフォントです。ほとんどのフォントは合理的なサイズですが、少数の外れ値が非常に重くなる可能性があることを思い起こさせます。

ウェブサイトのほとんどは適度なサイズのフォントファイルを提供していますが、非常に大きなフォントファイルも無視できない数存在するというのが主な学びです。これにより、効率的なフォーマットとテクニックを使用することが重要になります。WOFF2はファイルサイズを圧縮することで大いに役立ちますが、フォントが非圧縮で半メガバイトであれば、WOFF2でも限界があります。サブセット化（つまり、必要なグリフのみを含む）などのテクニックは、CJKやアイコンフォントなどの非常に大きなフォントにとって不可欠です。

WOFF2の普及が大きなフォントファイルのパフォーマンスへの影響を軽減するのに役立つのは心強いことですが、フォントをセルフホストするサイトは平均的に最適化の余地が多いことも判明しました。例えば、2024年にはセルフホストのフォントリクエストの約58%のみがWOFF2でした（全体では約78〜81%）。セルフホストのセットアップはWOFF（約18〜19%）やもいくつかの生のTTF（約6%）のシェアが大きかったです。これは、フォントをセルフホストする一部の開発者が古いファイルを使用しているか、WOFF2に圧縮していない可能性があることを示唆しており、一方でGoogleのような大手プロバイダーはブラウザがサポートしていれば常にWOFF2を提供します。

2025年のデータは改善を示しています。より多くのセルフホスターがWOFF2に移行していますが、依然としてギャップがあります。セルフホストする場合は、フォントのWOFF2バージョンを確保し、正しい Content-Type でそれらを提供するようにサーバーを設定することが重要です。2024年にセルフホストのフォントファイルの大部分が設定が正しくないMIMEタイプで提供されていました（前述の5〜6%）。これは開発者がシンプルなサーバーの設定変更で修正できるものです。良いニュースは、WOFF2の優位性が全体的に拡大していることですが、Googleのプラットフォームよりもセルフホストの領域では少し遅いペースです。本質的には、セルフホストサイトは追いついていますが、最適なフォーマットの使用においてわずかに遅れています。

CSSテクニックとフォントの読み込み

CSSテクニックとフォントの読み込みは、タイポグラフィが実際に現実のものとなる場所です。ページはフォントを選択するだけでなく、フォントオリジンへの接続をいつ開始するか、どのファイルを最初にフェッチするか、転送中に何を表示するかをブラウザに伝えます。このセクションでは、それらのメカニズム（リソースヒント（preconnect、preload、そして消えゆくdns-prefetch））、テキストフォントとアイコンフォントの間で明確に分かれている現在の標準的なfont-displayパターン、そして基礎となるアウトラインフォーマットを見ていきます。

リソースヒント

ウェブフォントはレンダリングブロックやテキスト表示の遅延によって視覚的な異常を引き起こす可能性があるため、多くのサイトがフォントの読み込みを最適化するためにリソースヒントを使用しています。データは、ベストプラクティスの進化に伴っていくつかの変化はあるものの、これらのヒントの着実な採用を示しています。

図1.12. デスクトップサイトでのフォントのリンクリレーションシップ値の使用状況。

図1.13. モバイルサイトでのフォントのリンクリレーションシップ値の使用状況。

最も人気のあるヒントは依然として <link rel="preconnect"> です（フォントホストへの接続を事前に開くためによく使用されます）。2025年のデータでは、デスクトップページの約18.3%がpreconnectヒントを含んでおり（2024年の18.3%からほぼ変わらず）、モバイルページの17.7%が同様です。この横ばいは、過去数年間増加した後、preconnectの使用が落ち着いたことを示唆しています。これは一般的なテクニックで、5ページに1ページ近くに存在しており、パフォーマンスを意識する多くのサイトがfonts.googleapis.comや自社CDNなどのドメインにpreconnectを追加するようになった現在、理にかなっています。

一方、dns-prefetch（DNSのみを解決する軽量なヒント）は低下傾向にあります。2025年には、フォントにdns-prefetchを使用しているデスクトップページが約14.6%で、2022年の約17.9%から減少しています。モバイルも14.7%で同様です。この減少は理にかなっています。開発者がpreconnect（接続確立の一部としてDNS解決を含む）を発見すると、別個のdns-prefetchは必要性が低くなります。以前にdns-prefetchを使用していた多くのサイトがpreconnectにアップグレードしており、これはTLSハンドシェイクを早期に行うことでより実質的な最適化を提供します。

preloadヒントは静かながら重要な上昇を見せています。2025年には、少なくとも1つのフォントに <link rel="preload" as="font"> を使用しているデスクトップページが約12.0%で、2024年の約11.0%から増加しています。モバイルも同様の増加を示しています（昨年から約11.7%）。これは、ブラウザにフォントを発見させるのではなく、より多くのサイトが重要なウェブフォントファイルを明示的にプリロードしていることを示しています。フォントをプリロードすると、ブラウザがCSSを待ってからフォント宣言を待つのではなく、preloadヒントを見た瞬間にフォントのフェッチを開始するため、読み込み遅延を短縮できます。このテクニックはパフォーマンスを重視したセットアップで特に人気があり、フォントファイルが大きい場合やFOIT（不可視テキストの点滅）を避けたい場合に推奨されます。

最後に、prefetchはニッチなツールのままです。2025年にはページのわずか約0.6%で使用されています（昨年の約0.5%からわずかに増加）。Prefetchは一般的に近い将来に必要になるかもしれないリソース（別のルートやページなど）を読み込むために使用されるため、prefetchが1%未満であることは、フォントに対するかなり専門的なヒントであることと一致しています。わずかな増加は、後続のページのアセットをプリフェッチするシングルページアプリケーションフレームワークや積極的なオプティマイザーによるものかもしれません。

まとめると、preconnectとpreloadが2025年で使用される主要なフォント読み込みヒントであり、preconnectがページの約5分の1に、preloadが約8分の1に表示されています。これはpreconnectに置き換えられるにつれてのdns-prefetchの減少と一致しており、prefetchは稀ですが緩やかに成長しています。これは業界が、より強力でより明示的な読み込みシグナルへと移行していることを反映しています。開発者は投機的なもの（dns-prefetch、prefetch）よりも即時的なアクション（preconnect、preload）をますます好むようになっています。

フォント表示

CSS font-display ディスクリプタはウェブフォント使用において事実上の標準的なプラクティスとなっています。数年前は検討すべき「良い最適化」でしたが、2025年にはウェブフォントを使用するほとんどのページが、フォントの読み込み中にテキストがどのようにレンダリングされるかを制御するために font-display ポリシーを指定するようになっています。データは、テキストフォントとアイコンフォントの間で明確な分かれ目とともに、高速なテキストレンダリングへの強い選好を示しています。

最も一般的な選択は font-display: swap です。2025年のクロールでは、デスクトップページの約49.6%、モバイルページの50.1%に表示されています。言い換えれば、ウェブフォントを使用するすべてのページの約半数が、少なくとも1つのフォントに font-display: swap を指定するようになっています。この値は、フォールバックフォントを使用してテキストを即座に表示し、ウェブフォントの読み込みが完了したときにスワップすることを保証します。swapの人気はウェブのベストプラクティスと一致しています（Google Fontsや多くの専門家が推奨しています）。本質的に、テキストコンテンツのデフォルトの考え方になりつつあります。開発者は、一時的にフォールバックフォントであっても、テキストの素早い初回描画を好みます。

次に、font-display: blockはデスクトップページの約24.7%、モバイルページの24.9%で2番目に一般的な値で、swapの約半分の普及率です。定義上、blockはフォントの読み込み中に一時的にグリフを非表示にしますが、これが主にボディテキストに使用されていると仮定すると危険に見えるかもしれません。しかし、データは実世界の font-display: block の使用の約70%がアイコンフォントスタイル（Font Awesome、テーマアイコンセットなど）からのものであることを示しており、作者が欠落したアイコンよりも短い遅延を意図的に好んでいます。それらのケースでは、blockはまさに期待通りのことをしています。最初のテキスト描画を最適化するのではなく、UIの破損を防ぎます。したがって、事実上すべてのblockの使用はボディテキストフォントからではなく、完全にレンダリングされるかまったくレンダリングされないかのどちらかが必要なUIアイコンからです。このパターンは2024年の章での「驚き」の発見でしたが、2025年のデータはそれを確認しています。blockの普及率は多くの開発者がコンテンツに不可視テキストを好むためではなく、アイコンキットが欠落したアイコンを防ぐためにデフォルトとしてblockと一緒に出荷されているためです。

swapとblockを超えると、他の値はずっと一般的ではありません。font-display: auto（ブラウザのデフォルト動作に委ねる）はデスクトップの9.1%、モバイルページの8.5%で使用されています。このシェアは、より多くの人が明示的に値を設定するにつれて縮小しています。また、font-display: fallback（非常に短い不可視期間を許可した後、常にスワップする）が約5.1%のページに見られます。この値は、テキストを素早くスワップしたいが、重要なフォントの読み込みに小さな余地を与えたい開発者に好まれることがあります。最後に、font-display: optionalは依然として稀であり、ページの約0.4〜0.5%のみが使用しています。optional値はパフォーマンスに対して最も積極的であり（フォントが即座に読み込まれない場合、まったくスワップしないことが多い）、通常はパフォーマンスに敏感なサイトや非常に特定のタイポグラフィのセットアップでのみ使用されます。

個々のフォントファミリーとそのfont-displayの動作を見ると、これらの結論が強化されます。最も一般的に読み込まれるテキストフォント（例：Roboto、Open Sans、Montserrat、Poppins、Inter、Lato）は、@font-faceルールで圧倒的に font-display: swap で提供されています。例えば、swapを持つRobotoは約12%のページに表示され、swapを持つOpen Sanは約8%に表示されます。逆に、font-display: blockを持つフォントは主にアイコンキットです。Font AwesomeのCSS（デフォルトでblockを使用）は約17%のページで観察され、ETmodules、IcoMoon、Bootstrap Iconsなどの他のアイコンフォントも一桁台の低いパーセンテージでblockの使用に貢献しています。一部のテキスト指向のサイトはfont-display: fallbackを使用しています（例えば、Interやあるセリフフォントをするいくつかのサイトはスタイルなしフォントの点滅と偽ボールドテキストの点滅のバランスを取るために意図的にfallbackを設定しています）。しかし、通常のテキストフォントにblockを使用するサイトはほとんどありません。

現代のベストプラクティスは数字に明確に反映されています。ウェブの約半分が素早いテキストレンダリングを確保するためにswapを使用し、blockを使用する4分の1はほとんどが非テキストグリフのためにそうしています。残りの4分の1はfont-displayを指定していない（したがってブラウザのデフォルトを使用している）か、専門的な戦略（fallback/optional）を試みています。2024年と比較して、これらの割合は本質的に変わっていません。昨年はswapが約50%、blockが約25%使用されていました。この安定性は2024年のガイダンスが依然として有効であることを意味します。サイトでfont-display: blockを見た場合、それはアイコンフォントである可能性が高いです。テキスト的なウェブコンテンツのほぼすべてについて、今日の開発者はより良いUXのためにswapを好みます。

フォントアウトライン形式

タイポグラフィのもう一つの技術的な側面は、フォントファイル内のアウトライン形式（TrueType対PostScriptアウトライン）です。ほとんどのウェブフォントは、コンテナに関係なく、TrueType（glyfテーブル）形式またはCFF（Compact Font Format）アウトラインのいずれかです。2022〜2025年のデータは、ウェブがTrueTypeアウトラインに圧倒的に標準化していることを示しています。

今年、ウェブに読み込まれたフォントの約92〜93%がTrueTypeアウトライン（伝統的な2次ベジェ曲線の「glyf」テーブル）を使用していました。これは2022年の約90%からわずかに増加しています。対照的に、PostScript/CFFアウトライン（.otfフォントによく見られる3次ベジェ曲線アウトライン）はウェブフォントの約7%に減少しています（数年前の約9〜10%から低下）。TrueTypeは特定のユースケース（特にバイトコードによるヒンティングを行わない場合）でパフォーマンスやサイズの利点があるため、モダンなウェブフォントサービスやファウンドリーは、元々PostScriptアウトラインとして設計されたフォントでもTTF/WOFF2を提供することが多いです。

その他はすべてごくわずかな割合です。CFF2（PostScriptアウトラインを持つ可変フォントに使用される新しいバリアント）は実際にはほぼ存在せず、フォントの0.01〜0.02%にしか表示されません。SVGグリフ（SVGテーブルを持つフォント、多くの場合カラーフォント）も非常に低い小数点以下の割合です。本質的に、カラー/絵文字フォントの特殊なケースを除いて、ウェブ開発者はこれらについてあまり心配する必要はありません。仮想的には常にTrueTypeベースのフォントを扱うことになり、特に古いパッケージからのCFFアウトラインが少数残っている程度です。

ハイフネーションとジャスティフィケーション

適切なテキストレイアウトは、読みやすさのために適切な場所で行を折り返すことを含みます。ブラウザはデフォルトでグリーディな改行アルゴリズムを使用しており、これはジャスティフィケーションされたテキストで不均一なスペースや「空白の川」を引き起こす可能性があります。代わりに、ハイフネーション（単語を分割する）と改行を改善するための新しいCSSプロパティ（text-wrap: balanceまたはpretty）を使用できます。これらがどのように使用されているか見てみましょう。

まず、ハイフネーション（CSS hyphensプロパティ）について話しましょう。デフォルトでは、ブラウザは特定の条件が満たされた場合（langが指定されていて単語が長いなど）にのみテキストをハイフネーションし、一部のブラウザ（Chromeなど）はそう指示されない限りまったくハイフネーションしないかもしれません。hyphens: autoプロパティは必要に応じて自動ハイフネーションを許可します。2025年には、世界的にページのわずか約10.5%がCSSで hyphens: auto を使用しています。これは過去数年よりわずかに増加していますが、依然として非常に低いです。これは、約10サイトに1サイトがハイフネーションを明示的に有効にしていることを示唆しています（通常、ジャスティフィケーションされたテキストや狭い列のテキストを改善するため）。

一方、hyphens: noneまたはhyphens: manualが設定されているページが約3.8〜4.0%あります（多くの場合、リセットやフレームワークによって）。これは通常、自動ハイフネーションがないことを確保するために行われます（例えば、一部のデザイナーはタイトルや特定のコンポーネントでハイフンを避けることを好み、または古いCSSリセットが予期しない改行を避けるために hyphens: none を設定します）。

これらを組み合わせると、ページの約14〜15%がhyphensプロパティにまったく触れています。大多数（85%）はそれに触れておらず、事実上ブラウザのデフォルト（多くの言語でハイフネーションなしを意味する）に委ねています。したがって、ハイフネーションは普遍的にはほど遠く、おそらくそれを慎重に使用する必要があるため（正しい言語タグと様々なブラウザサポートへの期待を持って）、すべてのコンテンツがハイフネーションの恩恵を受けるわけではありません（これは主にジャスティフィケーションされたテキストや狭い列での懸念です）。

テキストの折り返しと改行（CSS text-wrapプロパティ）：CSS Text Module Level 4は、ブラウザがテキストをより均等に分配するのを助けるためにtext-wrap: balanceとtext-wrap: prettyを導入しました。これらはかなり新しく（SafariやChromiumベースのブラウザなど一部のブラウザでのみ最近サポートされています）、その採用は小さいながらも、複数行の見出しなどのための新興のベストプラクティスを示しています。

デスクトップサイトでは、ページの約2.7%がtext-wrap: balanceを使用しています。モバイルでは約2.5%です。このプロパティは行を概ね等しい長さにしようとします（複数行のタイトルに最適）。その新しさにもかかわらず、約40ページに1ページですでに確認できるのは印象的です。これはフレームワークや大規模サイトがヒーローセクションへの素早い採用を反映しているものと思われます。

text-wrap: prettyプロパティ（非常に短い単語や他の奇妙な配置を避けるためにスペースにある程度の余裕を持たせる）は、ページの約1.7%（デスクトップとモバイルの両方）にあります。これはbalanceプロパティよりわずかに低いです。Prettyはより段落向けで、厳しい改行を避けるためのものであり、完全なジャスティフィケーションや特定の改行の問題が発生する場所で選択的に使用される場合があります。

興味深いことに、モバイルではtext-wrap: wrap（デフォルトの通常の動作）が約6.9%のページで明示的に表示されています。これはフレームワークが再述しているか、小さい画面のためにbalanceからwrapにトグルしているためかもしれません。そしてtext-wrap: nowrap（要素内での折り返しを防ぐ）は、ボタンやロゴなどを1行に保つためによく使用され、モバイルページの約3.1%、デスクトップページの3.2%で使用されています。

モバイルでのnowrapと明示的なwrapの比較的高い使用は、小さい画面での改行の制御が特に重要であることを示しています（例えば、タイトなUI要素での不自然な折り返しを防ぐ）。

ハイフネーションとテキストラップの機能を合わせると、次のような状況が浮かび上がります。少数のサイトがテキストレンダリングのきめ細かな制御を本当に行っており（これらはニュースサイト、慎重に設計された編集サイト、またはアプリのようなインターフェースが含まれる可能性があります）、それらのサイトはハイフネーションとバランスの取れた折り返しを使用してテキストブロックを改善しています。大多数のサイトはデフォルト（ハイフネーションなし、グリーディな改行）に依存しています。

ジャスティフィケーションについて具体的に言うと：サイトがtext-align: justifyを設定した場合（一部のサイト、特に記事コンテンツでそうしています）、理想的には大きなギャップを避けるためにhyphens: autoとおそらくtext-wrap: prettyも使用すべきです。まだ多くのサイトがそうしていないことがわかっており、ウェブ上のジャスティフィケーションされたテキストの多くはおそらく最適でないスペースを持っています。ツールは存在します（ハイフネーション、balance、pretty）が、採用は遅れています。その一部はブラウザのサポート（これらはある程度最先端のプロパティです）であり、一部は認知不足かもしれません。

最後に、hyphenate-character（カスタムハイフングリフを指定する）やhyphenate-limit-chars（非常に短い単語のハイフネーションを避ける）などのプロパティはほぼ未使用のようです。これらのプロパティの使用は無視できるほど少なく、ほとんどの著者が触れない非常に細かい調整です。ほとんどの著者はブラウザのデフォルトを受け入れています。

したがって、ハイフネーションは緩やかに成長していますが、依然として約10サイトに1サイトしか使用しておらず、新しい改行オプションが登場しています。数パーセントのサイトがすでにバランスの取れた改行を使用して、より良いタイトルを表示しています。レスポンシブデザインと複数行のレイアウトテクニックが開発者によりよい制御を求めるよう促すにつれて、これらの数字が増加することが予想されます。

ファミリーとファウンドリー

このセクションではウェブタイポグラフィの供給側を見ていきます。まず実際にCSSで宣言されているフォントとファウンドリーを追跡し、次にシステムフォントと汎用スタックの役割を見て、最後にメタデータをファウンドリー、デザイナー、ライセンスまで追って、ウェブ全体のユーザーに最も普及しているものを確認します。

汎用フォントとシステムフォント

カスタムウェブフォントの普及にもかかわらず、システムフォントと汎用ファミリー名は特にパフォーマンスとネイティブな外観のためにウェブデザインの基盤であり続けています。多くのサイトがボディテキストやUI要素にシステムフォントスタックまたはフォールバックを指定しています。2025年のデータはこれらがいかに一般的かを示しています：

ファミリー	デスクトップ	モバイル
`sans-serif`	89%	89%
`monospace`	64%	63%
`serif`	47%	48%
`system-ui`	10%	9%
`ui-monospace`	4%	4%
`ui-sans-serif`	4%	4%
`cursive`	3%	3%

図1.20. 最も一般的なシステムファミリー

汎用のsans-serifはCSSで最も一般的なファミリー名（font-familyリストの末尾のフォールバックとして）です。デスクトップとモバイルページの約89%に含まれています。本質的に、ほぼすべてのサイトがCSSに常にデフォルトフォントを確保するためにsans-serifで終わる（またはシステムフォントスタックでそれから始まる）行を持っています。汎用のmonospaceも非常に一般的で（ページの約64%に見られる）、開発者がコードスニペットや整形済みテキストにモノスペースフォントを設定することが多いためです。汎用のserifはページの約48%に表示され、見出しのフォールバックとして、またはセリフデザインが必要な場合に使用されます。

より興味深いのは、system-uiのようなプラットフォーム固有の汎用フォントの台頭です。system-ui値（macOS/iOSのSan Francisco、WindowsのSegoe UI、AndroidのRobotoなど、OSのUIフォントにマッピングされる）は現在、デスクトップページの約9.7%、モバイルの9.3%で使用されています。これは著しい増加であり、数年前はこれらの値はほとんど登録されていませんでした。採用は主に「ネイティブアプリ」の美学を目指すか、パフォーマンス上の理由からユーザーのデフォルトUIフォントに委ねるモダンなCSSフレームワークやデザインシステムによって促進されています。同様に、新しい汎用のui-monospace（システムのデフォルトのモノスペースフォント）はページの約4%で使用され、ui-sans-serifは約3.5%で使用されています。これらの数字は、（約10サイトに1サイト）の無視できないサブセットのサイトが、多くの場合スピードとネイティブアプリとの一貫性のために、テキストにシステムフォントを明示的に選択していることを示しています。これはGitHubやMediumなどのサイトがボディテキストにウェブフォントを読み込まないようにシステムフォントを使用するトレンドと一致しています。

まとめると、システムフォントは多くのウェブサイトで典型的に縁の下の力持ちでした。開発者はほとんどのUIテキストにシステムフォント（または少なくともsans-serifのような安全な汎用フォールバック）を使用し、次にブランディングやヘッダーのためにいくつかのカスタムフォントを読み込むというハイブリッドアプローチを使用することが多いです。汎用のsans-serif、serif、monospaceはフォールバックとしてユビキタスであり、system-uiファミリーと関連するものは現在多くのCSSフレームワークでより目立っています。

フォントファウンドリー

フォントの作成に功績があるファウンドリーやベンダーを確認するために@font-faceメタデータを見ると、大多数は少数のファウンドリーによって提供されており、クレジットのないフォントの大きな塊と、低いパーセンタイルで長いテールの他のファウンドリーが続いています。

ページカバレッジ別で、ウェブのトップの「ファウンドリー」ラベルは：

Google：ウェブフォントを使用するウェブサイトの約34%でファウンドリーとして記載されています。これにより、Google（Google Fonts経由）は断然フォントの最大の単一ソースとなっています。これは主に独立したデザイナーによるオープンソースデザインへのGoogleの資金提供によるものです。
Font Awesome（AWSM）：ウェブサイトの約29%でクレジットされています。これは2番目に大きなシェアで（Googleより約5パーセントポイント後れを取っており）、Font Awesomeアイコンフォントのユビキタスさによって完全に説明されます。Font Awesomeはアイコンセットであるため（ファウンドリー「Dave Gandy」も引用される可能性がありますが、フォントメタデータはよく「Font Awesome」または「AWSM」をファウンドリーとして使用します）、少しユニークです。

合わせると、GoogleとFont Awesomeに関連するフォントは全ページの約3分の2に表示されており、これは巨大です。これら2つの後、次に大きなカテゴリは実際には帰属のないフォントまたはカスタムフォントです。ページの約19%がファウンドリーが指定されていないフォント（「UNSPEC」）を持ち、別の12%がファウンドリーに「none」または汎用的な値を記載しています。合計すると、フォントの4分の1をはるかに超えるものがメタデータに明確なファウンドリー情報を持っていません。このチャンクはカスタムのセルフホストフォント、小さなファウンドリー、または名前が標準化されていなかったフォントを表している可能性が高いです。

GoogleとFont Awesomeを超えた識別可能なファウンドリーの中では、いくつかが際立っています。「pyrs」（Fontlab）はページの約17%に記載されています（これはオープンソースのアイコンセットや特定のCJKフォントに関連するラベルで、複数のケース変化から正規化が必要かもしれません）。ULA（MontserratのデザイナーであるJulia Ulanovsky）は約10%です。Indian Type Foundryは約9%です。ADBE（Adobe）は約6%です。これらの数字は昨年と同程度の大きさで、Notoなどのフォントがどのように帰属されるかによって若干の順序変更があります。例えば、NotoフォントはGoogleと他者のコラボレーションであったため、これらの共同フォントの一部がAdobeのファウンドリーコードの下に表示されるようになり、昨年の計算方法と比較してAdobeのシェアがわずかに増加しています。

要するに、ウェブ上のフォントへの帰属は現在、Google、Font Awesome、数十の人気フォントの発行者、そして匿名の大きな中間層に分かれています。約30%のフォントがファウンドリー情報が不明確または存在しません。残りはアクティブなウェブフォントファウンドリーの「who’s who」に分かれています。Indian Type Foundry（Google経由で多くの人気フォントをリリース）、「pyrs」などのファウンドリータグにグループ化された独立したデザイナー、Adobe、Monotypeなどの商業ファウンドリーの少々などです。この分布はオープンソースフォントのプロバイダーとしてのGoogle Fontsの影響力とFont Awesomeの広範な使用を強調しながら、ウェブフォントの大部分が帰属が強くない、より広いオープンソースコミュニティやカスタムキットから来ていることを思い起こさせます。

フォントデザイナー

多くのフォントファイルはメタデータにタイプデザイナーの名前を含んでいます。それを集計することで、誰の作品がウェブで最も普及しているかを確認できます（多くのフォントがメタデータにデザイナーをまったく記載していないことを念頭に置いて）。

デザイナー	デスクトップ	モバイル
	78.3%	76.7%
Dave Gandy	13.6%	13.8%
Adrian Frutiger	1.5%	1.6%
Jan Kovarik	1.5%	1.4%
Rasmus Andersson	1.2%	1.2%
Linotype Design Studio	1.0%	1.2%
Google	1.1%	1.1%
Julieta Ulanovsky	1.0%	1.1%
Mark Simonson	0.9%	0.8%
Commercial Type, Inc.	0.4%	0.7%

図1.22. 最も人気のあるフォントデザイナー

データは、ほとんどのウェブフォントがデザイナーを指定していないことを示しています。ページの約77〜78%がメタデータにデザイナーが記載されていないフォントを少なくとも1つ使用しています。これは省略によるものか、フォントが個人ではなくファウンドリーやプロジェクトに帰属しているためかもしれません。その巨大なブランクカテゴリは、「デザイナーランキング」を割り引いて見る必要があることを意味します。これは部分的な見方です。

そうは言っても、クレジットされたシェアでは一人の名前が際立っています。Dave GandyはFont Awesomeの作成者であり、その名前が約13.7%のページに表示されています（基本的にFont Awesomeをセルフホストしてデザイナーフィールドが入力されているすべてのページ）。これにより彼はアイコンフォントの普及によって、ウェブ上で最も目立つ（メタデータ上の）タイプデザイナーとなっています。興味深い特異性です。ウェブ開発者が美的な理由から意識的に「Dave Gandyのタイプフェイス」を選んでいるわけではなく、一つの非常に成功したツールキットが何百万ものサイトに彼の名前を付けているのです。

その他には、それぞれ約1%前後のページに名前が登場する著名なタイプデザイナーたちのグループがいます。Univers やエポニマスなFrutiger書体で知られるAdrian Frutiger（1.5%）、InterのデザイナーであるRasmusAndersson（1.2%）、汎用的なラベル「Google」（1.1%、特定のデザイナーがクレジットされていない一部のGoogleフォントで使用）、Linotypのデザインスタジオ（1.1%）、MontserratのデザイナーであるJulieta Ulanovsky（1.0%）、Proxima NovaなどのデザイナーであるMark Simonson（0.9%）などです。

これらの数字はウェブで最も人気のあるフォントを反映しています。MontserratはUlanovskyの名を持ち、InterはAnderssonの名を持ち、Proxima NovaはSimonsonの名を持っています（ただし、Adobe経由のProximaはキットのメタデータによっては彼の名前が記載されない場合もあります）。さらにロングテールでは、Łukasz Dziedzic（Latoのデザイナー、おそらく複数の綴りで登場）やGoogleフォントプロジェクトや主要なファウンドリーへの貢献者の名前も見られます。しかし、これらのシェアはそれぞれ1%以下です。

重要な点は、ウェブ上でのデザイナー帰属は非常に疎らで偏りが激しいということです。1つのアイコンフォントの作者がツールの人気により統計を圧倒しています。残りの見えるデザイナー帰属は、著名な20世紀タイプデザイナー（Frutigerなど）、最も人気のあるオープンソースフォントの作者（InterのAndersson、MontserratのUlanovsky）、大きなファウンドリーチーム（Linotype、Monotypenど）が混在しています。これはウェブでのフォント配信のあり方を示しています。多くの場合、プラットフォーム（Googleなど）やファウンドリーが前面に出て、個々の作者は名前の残る大きなプロジェクトに携わっていない限り、常に名前が挙げられるとは限りません。

フォントライセンス

フォントファイルにはメタデータにライセンスのURLや識別子が含まれていることが多く、ウェブで一般的なライセンスを把握するために利用できます。ただし、約半数のフォントはパース可能な形式でライセンスを明確に指定していません。それを念頭に置くと、データはオープンソースライセンスがウェブフォントを完全に支配していることを示しています。

ライセンス	デスクトップ	モバイル
OFL	64%	65%
	49%	50%
Font Awesome	13%	13%
Apache	21%	8%
Adobe	5%	4%
Monotype	4%	4%

図1.23. 最も一般的なフォントライセンス

断然最も一般的なライセンスはSIL Open Font License（OFL）です。サンプル中の約64%のウェブサイトがOFLのもとで少なくとも1つのフォントを使用しています。これはOFLがGoogle Fontsやその他のオープンソースフォントプロジェクトの大多数で使用されているライセンスであることを考えれば驚くべきことではありません。基本的に、変更時に名前を変更する限り、フォントの自由な使用、変更、再配布を許可しています。OFLフォントの普及は、ほぼ3分の2のサイトがオープンソースフォントを使用していることを意味します。

次の大きな「ライセンス」カテゴリは、実際にはライセンスが指定されていないものです。約50%のページで、少なくとも1つのフォントのライセンスフィールドが空白または認識不能でした。これはフォントがメタデータのないカスタムフォントであるか、ライセンスが埋め込まれていない（よくあること）商用フォントであるか、あるいは「不明」として入力されているデータである可能性があります。ウェブ上のフォント使用の多くは、ファイル内のライセンスによって簡単に追跡できないことを思い起こさせます。しかしこのバケットの多くはおそらく、@font-face にライセンスを宣言しない（ウェブデザイナーが常に記入するとは限らないため）専有フォントです。

Font Awesomeライセンス（専有とオープンのハイブリッドライセンス）は約13%のページに存在し、Font Awesomeの使用数と一致しています。Adobeのフォントライセンス（Adobe Fonts経由のフォント用）は約4〜5%のページに表示され、これもAdobeの使用シェアと一致しています。同様に、MonotypeのEULAは約4%をカバーしています（ただし、ウェブ上の多くのMonotypeフォントはセルフホストされている場合「ライセンスなし」として表示される可能性があります）。

それ以外に、Apacheライセンス（一部の古いGoogle Fontsやその他のプロジェクトで使用されているオープンソースライセンス）はOFLに次ぐ2番目に多い明示的なライセンスであり、オープンライセンスが標準であることを強調しています。興味深いことに、デスクトップ/モバイルの差があります。デスクトップのクロールでは高く（〜21%）、モバイルでは低く（〜8%）なっており、特定のフォントやフレームワークがデスクトップサイトでより一般的であることが原因と考えられます。

これらを超えると、特定のファウンドリーとベンダーのライセンスの長いテールがあります。Commercial Type、Typotheque、Hoefler&Co（Typography.com）、Dalton Maag、Naver（一部のNoto Sans CJKディストリビューション用）のマーカーがそれぞれ1%未満のページで見られます。これらは特定のサイトでの商用フォントライブラリの特定の使用を示しますが、概してウェブはオープンフォントライセンスで動いています。

グローバル言語サポート

ウェブはますますグローバルになっており、ウェブのタイポグラフィも世界の多くの書記体系をサポートしなければなりません。ラテン文字はウェブフォントで最もよくサポートされている書記体系ですが、近年のフォント作成と配布の取り組みのおかげで、他の書体も着実に増加しています。

2025年には、全ウェブフォントの半数強にラテン文字が含まれています（データセットのフォントの約54%）。ラテン文字はほとんどのマルチスクリプトフォントに含まれているため、これは基本的にヨーロッパやアメリカのオーディエンス向けのフォントがすべてここに含まれることを意味します。ラテン文字と並んで、約54%のフォントにはUnicodeの私用領域（PUA）も含まれており、これはアイコンフォントやカスタムシンボルが存在する場所です。PUAの普及は、ウェブ上のフォントの多くが実際にアイコンセットであるか、組み込みのアイコンを持っているか（Font Awesome、テーマアイコンフォントなど、すべてPUAにマッピングされる）を（再度）示しています。

ラテン文字の次に多い書体はキリル文字で、ウェブフォントの約12〜13%がサポートしています。キリル文字のシェアは少し成長しており（2022年は約7%、2024年は約10%）、ロシア語、セルビア語、ウクライナ語などの言語をカバーするフォントが増えていることを反映しています。ギリシャ語のカバレッジは約7〜8%のフォントに存在し、数年前から増加しています。多くの拡張文字セットはラテン文字、ラテン拡張、キリル文字、ギリシャ語を1つのファイルに持っているため、これらの拡張はしばしば一緒に来ます。

CJK（中国語・日本語・韓国語）書体の存在は見えますが、主にファイルサイズの懸念から人口規模が示唆するよりも控えめです。日本語書記体系はカタカナ（約1.3〜1.4%のフォントにカタカナ文字が含まれる）とひらがな（同様に約1.3〜1.4%）で登場します。さらに、漢字（中国語と日本語の書き込みに使用される文字）は約0.4%のフォントに登場します。漢字の割合が小さいのは、フルの中国語/日本語フォントファイルは膨大であり、比較的少数のサイトがそれらを完全に提供しているためです。多くの場合、サイトはシステムフォントに頼るかサブセットを使用しています（カタカナ/ひらがなの存在は一部の日本語フォントやサブセットが使用されていることを示唆しています）。韓国語のハングル文字は約0.9〜1.0%のフォントに含まれています。これらの数字は小さく見えますが、一部のオープンソースCJKフォント（Noto Sans JP、Noto Sans KRなど）が使用されていることを表しています。サイズのためにほとんどのウェブサイトがCJKウェブフォントを提供していなかった10年前と比較すると、これは大きな変化です。

注目すべき存在の他の書体：ヘブライ語は約1.2%のフォントに登場します（Google経由とセルフホストの両方でいくつかのヘブライ語ウェブフォントがあります）。アラビア文字はデスクトップで約0.7%、モバイルで0.9%のフォントがサポートしており、モバイルの多い地域がウェブフォントを多く使用するにつれてわずかに増加しています。デバナーガリー（インドのヒンディー語やその他の言語に使用）は1%弱のフォントに存在します。タイ文字は約0.5%のフォントに見られます。アルメニア語とジョージア語はそれぞれ0.2〜0.3%の範囲です。グジャラート語、グルムキー語、タミル語、ラオス語、クメール語などの他の南アジアおよび東南アジアの書体はそれぞれ0.1%未満のフォントに登録されています。

ラテンアルファベット以外の多くの書体が2%未満のフォントで使用されていますが、総合的には広い採用を示しています。主要なトレンドは、ラテン文字のみのフォントの優位性がゆっくりと低下していることです。より多くのフォントがマルチスクリプトであるか、他の書記体系を対象としています。このグローバル言語サポートの拡大の多くは、オープンソースフォントプロジェクトのおかげです。例えば、日本語と韓国語の重要な使用は、高品質のCJKフォントを自由に利用可能にしたNoto Sans/Serif JP、Nanum Gothic、Noto Sans KRなどのオープンフォントに起因しています。2024年には、韓国語のトップ10ウェブフォントファミリーのすべてがオープンソースであることに気づきましたが、そのパターンは続いており、デザイナーが自分の言語のための無料の高品質フォントにアクセスできるとき、それらのフォントを使用することを示しています。同様に、日本語のトップウェブフォントはオープンソース（Notoなど）であり、共有された漢字のために隣接言語に多大な影響を持っています。

1つの注意点は中国語（特に簡体字中国語）です。中国語専用のウェブフォントが使用されているのを見ることは依然として稀です（上記のデータは日本語サブセット以外での漢字の使用が非常に低いことを示しています）。何千もの文字を含める場合、中国語フォントファイルは極めて大きいため、ほとんどのサイトはまだそれらをセルフホストすることを避けています。システムフォントを使用するか、ロゴや見出し用に非常に限られたサブセットを提供しています。したがって、日本語と韓国語のウェブフォントの成長が見られる一方で、中国語は主にパフォーマンスの理由から同じ普及を見ていません。これからの発展の予告として、インクリメンタルフォント転送（IFT）の開発は、過去に中国語ウェブフォントを妨げてきたパフォーマンスダイナミクスを変えることを約束しています。IFTにより、ユーザーは特定のページを表示するために必要な文字のみを取得できるようになり、大きな文字セットを持つ言語のファイルサイズが劇的に削減されます。標準化され広く採用されれば、IFTはそれらの大きな文字セットの実効コストを削減することで、フル機能の中国語ウェブフォントをはるかに実用的にする可能性があります。同じメカニズムは、IFTが未使用のグリフと未使用のバリエーションデータの転送を避けることができるため、大規模な多軸可変フォントにも広く利益をもたらし、豊富な可変タイポグラフィをスケールでデプロイする際のコストを削減します。

まとめると、ウェブフォントの景観は徐々に多言語的になっています。ラテン文字はまだフォントの約半分に存在し（ほぼすべてのサイトは、数字や基本記号だけのためでもラテン文字が必要です）、他の書体をサポートするフォントのシェアは年々拡大しています。これは地域化の増加と、十分に提供されていない言語のフォントを提供してきたGoogleのNotoプロジェクトなどの取り組みの成果のポジティブなサインです。開発者にとって、例えばデバナーガリーやアラビア語のフォントが必要な場合、オープンウェブフォントが存在し、同僚によって使用されている可能性が相当あることを意味します。また、マルチスクリプトフォントは膨大になる可能性があるため、IFTなどの実験的な開発からフォントファイルサイズとパフォーマンスに注意が必要であることも意味します。

高度なフォーマットと機能

ウェブフォントがより多くの書体とより大きな文字セットをカバーするために拡張されるにつれ、次の問題はこれらのフォントで実際に何ができるかということです。この最終セクションでは、基本的なカバレッジを超えて、現代のフォントファイル内の高度な仕組み—OpenType機能、可変フォント、カラーフォント—と、開発者がウェブ全体でそれらの機能をどのくらいの頻度で使用しているかを見ていきます。

OpenType機能

OpenType機能は、印刷時代のタイポグラフィクラフトの特徴となっていた合字、代替文字、古いスタイルの数字、その他の詳細などの高度なビジュアルスタイルを可能にします。これらの機能の採用を2つのアプローチから観察できます。フォントにOpenType機能が含まれているかどうか、そしてサイトがCSS経由でそれらの機能を使用しているかどうかです。

まず、フォント自体を見ると、OpenTypeレイアウト機能はウェブフォントで今や標準となっています。2022年のデータでは、OpenTypeレイアウトテーブル（GSUB/GPOS）を持つフォントは半数未満でした。2024年には小さな多数（モバイルで約54%）になりました。2025年には、ウェブ上の個別のフォントファイルの約61〜62%が少なくとも1つのOpenType機能テーブル（置換や配置など）を含んでいます。この使用レベルはフォントの明確な多数を表しており、毎年成長しています。これは新しいフォントファイル（特にオープンソースのもの）がフル機能を含んで構築されているのに対し、古いシンプルなフォント（またはアイコンフォント）はそれらを持っていない可能性があることを反映しています。

図1.25. 機能別のCSS font-feature-settingsの使用状況。

OpenType機能の採用を使用量（フォントリクエスト）で重み付けすると、シェアはさらに高くなります。リクエストベースでは、フォントフェッチの99%以上がOpenType機能を持つフォントに対するものです。この数字は、OpenType機能を持たないフォントがニッチまたは非常に低使用（または多くのファイルとしてカウントされるが、トラフィックのシェアが小さいアイコンフォント）である傾向があることを示しています。基本的に、ユーザーがウェブで実際に見るほぼすべてのフォントは、合字やカーニングなどの機能が可能です。サイトがこれらの機能を有効化していなくても、フォントファイルはそれらをサポートしています。

したがって、多くの開発者は使用しているフォント（特にテキストフォント）でOpenType機能が利用可能だと想定できます。これらのテーブルを欠いているのは少数派（10個のフォントのうち4個未満、縮小中）で、ほとんどが古いウェブセーフに近いフォントや特殊なケースです。

では、フォントでどのOpenType機能が一般的でしょうか？OpenType機能を持つフォントの中で、最も一般的なものは：

カーニング（kern）: 約44〜46%のフォントにカーニング機能が含まれています。数年前は〜35〜38%に過ぎなかったため、その存在は大幅に増加しています。多くのフォントが特定の文字ペア間のスペーシングを調整するためにGPOSカーニング（またはkernテーブル）に依存していることを意味します。品質と活版整理の洗練さが標準になっているサインです。
標準合字（liga）: 約43%のフォントがこの機能を含んでいます。これは文字のシーケンス（「fi」など）を単一の合字グリフに置き換えます。2022年の約10%からのこの大きな跳躍は、ほとんどの新しいフォントが合字をサポートしていることを示しています（基本的なものだけでも）。
ローカライズされたフォーム（locl）: 約33%のフォントがこれを持っており、異なる言語で異なるグリフを許可します（ポーランドのkresakアクセントやトルコのドット付きiなど）。これが3分の1であることは、多くのマルチ言語フォントが組み込みのローカル最適化を持っていることを意味します。
数値機能: 約33%が分数（frac）をサポートし、約25%が分子（numr）と分母（dnom）をサポートしています（任意の分数の構築用）。表形式数字（tnum）と比例数字（pnum）はそれぞれ約20%のフォントに含まれています。これは素晴らしいことです。ランダムな現代のフォントを選ぶと、テーブル、財務データなどに役立つ高度な数字の整列と分数構築能力を持っている可能性が相当あることを意味します。
マーク配置（mark と mkmk）: 約17%が基本的なマーク配置を持ち、14%がマークからマークへの配置を持っています。これらはアラビア語、インド系書体、ベトナム語文字などのアクセントスタッキングにとって重要です。約6分の1のフォントにマーク配置が見られることは、複雑な書体の影響を示しています。ラテン文字専用のフォントがmarkテーブルを必要とすることは少ないからです。一方、多くのラテンフォントでパンアフリカンサポートを増やすGoogleの取り組みも、markテーブルの存在を増加させている可能性があります。
スタイリスティックセット（ss01、ss02など）と代替: これらはデータに健全ですが低いレベルで表示されます。約12%のフォントにss01があり、より小さな割合でss02、ss03など、またはsalt（スタイリスティック代替）機能があります。これは特定の文字のオプションの代替デザイン（異なる「a」や「g」など）を提供するフォントに対応しています。
大文字とスモールキャップス: smcp（スモールキャップス）やc2sc（大文字からスモールキャップスへ）などの機能は一部のフォント（数パーセント）に存在し、より高度な活版整理ファミリーを反映しています。
書体固有の機能: 例えば、rlig（アラビア語で使用される必須合字）や様々なインド系機能（上基底、下基底置換のabvs、blwsなど）はそれぞれ約1%以下のフォントに表示されます。これは上で議論した書体のフォントのシェアとほぼ一致しています。

総合的に、これはウェブフォントがより洗練されてきていることを意味します。今年のウェブクロールで見られたフォントの半数以上が少なくとも1つのOpenTypeの手を持っており、多くが12以上を持っています。合字やカーニングのような一般的なものは今では期待されており、単なる特別な特典ではありません。

では、開発者はCSS でこれらの機能を使用しているでしょうか？多くのブラウザエンジンはデフォルトでligaやkernなどのコア機能を適用します（無効にされない限り）。したがって、一部の機能は作者が何もしなくても使用されます。しかし、作者はCSS font-feature-settingsまたはより高度なfont-variantプロパティを通じて機能を明示的に制御できます。

低レベルのfont-feature-settingsの使用は絶対値では比較的小さいです。このプロパティを通じて特定のOpenType機能を手動で設定するページは約2〜3%に過ぎません。CSSで最もよく切り替えられる機能はkernとligaであり、一部のCSSリセットやフレームワークがカーニングをオンにしたり合字を意図的にオン/オフしたりするためと考えられます。2025年には、font-feature-settings: kernはデスクトップページの約2.7%に表示され、ligaは約2.5%に表示されます。その後、ドロップがあります。tnum（表形式数字）は〜0.8〜0.9%、palt（一部のCJKスペーシング調整に使用される比例代替幅）は〜0.7〜0.8%、そしてlnum（ライニング数字）やpnumのようなものは〜0.4%です。スタイリスティックセット（ss01など）や任意合字は直接設定で〜0.1%以下のページにのみ表示されます。

ただし、任意のfont-feature-settings使用（normalを設定するだけかライブラリ経由で含むものも含めて）があるページを数えると、その数は高くなります。約11〜12%のページに少なくとも1つのfont-feature-settings宣言があります。これは多くのサイトがフォント機能に触れるボイラープレートやフレームワークを含んでいることを示唆しています（例えば、特定のケースで合字を無効にするためにfont-feature-settings: "liga" 0を設定したり、一部の古いキットが特定の機能を有効にしたりするなど）。

対照的に、より人間に優しいfont-variant CSSプロパティは約5〜6%のページで使用されています。最も一般的なのはfont-variant-numericで、表形式数字や旧スタイル数字をリクエストするためによく使用されます。例えば、font-variant-numeric: tabular-numsは3.2〜3.3%のページで見られ、font-variant-caps: small-caps（〜1.5%のページ）などのプロパティの小さな使用が見られます。少なくない数のページ（約0.5%）が合字を意図的に無効にするためにfont-variant-ligatures: noneを使用しています（CSSリセットの一部として、またはモノスペースコードで合字が一般的に不要な場合などによく見られます）。

ここでのトレンドは、開発者がOpenTypeコントロールを徐々に採用していますが、普遍的ではないということです。ほとんどはブラウザのデフォルト（通常は基本を処理する）に依存しています。約10ページに1つのサブセットが、フレームワーク経由または手動で何らかの高度な調整を含んでいます。最も頻繁な意図的な使用は、数字の整列（表形式対比例）、合字やカーニングの明示的な有効化/無効化、そして場合によってはスモールキャップスの使用です。直接のfont-feature-settingsの使用がfont-variantの使用の約2倍であるという事実は、フレームワークが低レベルの構文を出力していることを示している可能性があります。または、特定の高レベルプロパティが存在しないため、スタイリスティックセットのような特定の一般的でない機能について、開発者がfont-feature-settingsを使用するしかない場合もあります。

日常的なガイダンスとして：フォントが合字などの機能を持っている場合、ブラウザのデフォルトで既に機能している可能性が高いという良いニュースがあります。また、特別な機能（例えば表形式数字）が必要な場合、小さくても増加中のサイトがCSS経由でそれらを使用する方法を示しています。より多くのデザイナーが利用可能な細かいタイポグラフィコントロールを認識するにつれ、これらの数字は引き続き上昇すると予想されます。

可変フォント

可変フォント（1つのファイルでウェイトや幅などの複数のスタイルを許可するもの）は、ここ数年で実験的なものからかなりメインストリームへと移行しました。2025年のデータは採用の継続的な成長を示しています。

可変フォントはどれほど人気があるでしょうか？今年は、39.4%のデスクトップウェブサイトと41.3%のモバイルウェブサイトが自分のページに少なくとも1つの可変フォントを使用しています。つまり、今では10のサイトのうち約4つが可変フォントを使用しています。これは2024年のデスクトップで約33%、モバイルで34%から増加しています。成長（年間〜6〜7パーセントポイント）は安定的で重要です。注目すべきは、モバイルが一貫して可変フォントの採用においてデスクトップを小さなマージンでリードしていることです。これはモバイルのパフォーマンスがフォントファイルの組み合わせからより多く恩恵を受けるか、多くの現代のモバイルファーストサイトまたはPWAがその柔軟性のために可変フォントを採用しているためかもしれません。

ただし、特定の可変フォントの使用分布は非常に上位集中しています。少数のフォントファミリーが非常に大きなシェアを占めています。ウェブで最も使用されている単一の可変フォントは依然としてNoto Sans JP（GoogleのNotoファミリーの日本語サンセリフ）です。2024年には、Noto Sans JPは可変フォントを使用するすべてのサイトの約27%で見つかり、2025年には可変フォントを使用するページの約25〜26%に表示されています。これによりNoto Sans JPはリーチ数でトップの可変フォントとなり、東アジアおよびCJKコンテンツのために世界中で多くのサイトがこのフォントに依存していることを証明しています。その後、次の3つの最大の可変フォントはRoboto、Open Sans、Montserratです。Noto Sans JPと合わせると、これら4つのファミリーはデスクトップとモバイルの両方で全可変フォントリクエストのほぼ60%を占めています。具体的には、Robotoは可変フォントサイトの約15%、Open Sansは11%、Montserratは7〜8%で使用されています。これらはすべてGoogle Fontsで可変形式で利用可能であり、Googleがこれらをデフォルトで可変フォントとして提供し始めたことがその優位性を説明しています。

トップ4を超えると、他の注目すべき可変フォントのクラスターが見られます。Noto Sans KR（可変フォントサイトの〜5%、韓国語の使用を反映）、Noto Serif JP（〜4%）、Noto Sans TC（〜2%）で、これらはすべてCJKスクリプトの同じNotoファミリーの一部です。次に、Inter（〜3.3%）、Raleway、Oswald、Playfair Display、Rubik、Roboto Slab、Google Sans、Nunitoなどの人気のラテン可変フォントがそれぞれ可変フォントを使用するサイトの2〜3%に登場します。このロングテールは、多くの可変フォントが存在する一方で、スケールで使用されているものはほとんどが大きな問題（複数のスクリプトや複数のスタイルを効率的にカバーするなど）を解決し、入手が容易なもの（主にGoogle経由のオープンソース）であることを示しています。

これらの可変フォントがどのように使用されているかを観察することも興味深いです。可変フォントでCSSに設定される一般的な軸は洞察を提供します。ウェイト軸（wght）は断然最も使用されており、可変フォントを使用するページの約57〜61%でウェイトが明示的に調整されています。これは、ほとんどの人が可変フォントを基本的に1つのファイルに複数のウェイトを持つために使用していることを示しています（例えば、異なるブレークポイントでテキストを太くしたり細くしたりする）。ただし、次に一般的な軸は特定の可変フォントシステムから来ています。FILLとopsz（光学サイズ）はそれぞれ可変フォントページの約35〜39%に表示され、GRADは約27%で続きます。これらはMaterial Symbols アイコンフォント（グリフフィル、グレード、光学サイズの軸を持つ）に対応しており、Googleが広く使用している可変アイコンフォントです。したがって、可変フォント使用の大部分は実際にはテキストではなく、複数のスタイリスティック軸を持つアイコンによるものです。幅（wdth）とスラント（slnt）が使用中の他の主要な軸です。スラントはデスクトップの約19%（モバイルの24%）の可変フォントページで見られ、幅は両方の約17%で見られます。これは、より小さいが確固たる割合のサイトが幅を調整するか、中間的なスラントを使用している（おそらく真のイタリックの代替またはレスポンシブ調整として）ことを示しています。他のすべての軸（カスタムデザイン軸やRoboto Flexのようなより細かい軸など）は使用率が5%以下または1%以下で表示されており、デモや非常に特定のプロジェクトからのノイズである可能性もあります。

実際には、ウェブの可変フォントは主にウェイト調整のために使用されており、場合によっては幅やスラントにも使用されています。opsz、FILL、GRADの高い表示は、広いトレンドではなく1つの人気アイコンフォントの使用の産物のようです。可変フォントの約束（継続的なバリエーションによる細かいタイポグラフィの調整）は、高いレベルの技術的統合によってサポートされていますが、ほとんどのデザイナーにとってクリエイティブな探索の初期段階にあります。多くの人が可変フォントを便利なマルチウェイトファイルとして使用しており、まだタイポグラフィ表現のための完全に動的なリソースとしてではありません。

そして、可変フォントアニメーション（フォントバリエーションプロパティでCSSトランジションまたはキーフレームを使用）は非常にニッチです。2025年の全ページの約0.3%のみが、可変フォント軸を含むアニメーションまたはトランジション（低レベルのfont-variation-settings経由、または可変フォントのfont-weightやその他の短縮形経由）を含んでいます。可変フォントを使用するページの中でも、何らかのアニメーションを行うのは1%未満（約0.7〜0.8%）に過ぎません。それが起こる場合は通常は装飾的で、例えばヒーロータイトルの拡大・縮小、またはウェイトを変更するホバーエフェクトを持つアイコンボタンなどです。レイアウトシフトを引き起こす可能性があるため、または単にそのデザイン空間に踏み込んでいる人が多くないため、一般的ではないようです。

カラーフォント

カラーフォント（絵文字やアイコンによく使われる多色グリフを持つフォントを提供する新技術）は興味深い技術でしたが、ウェブでの採用は依然として非常に限られています。2025年のデータはほぼゼロの基盤からの若干の増加を示していますが、まだメインストリームからは程遠いです。

0.06%

図1.27. カラーフォントを使用しているモバイルページの割合。

クロールで観察されたウェブサイトの約0.05〜0.06%のみがカラーフォントを使用していました。これは2,000ページに1つのオーダーです。数年前の約0.01%から成長していますが、依然として5倍の増加であり、全体的には微小です。生の数字で言えば、約6,000〜7,000のデスクトップページと同様の数のモバイルページでカラーフォントを見つけました。使用量は「倍増」していますが、このレポートの他の数字と比較すると、依然として四捨五入の誤差の領域に居ます。

なぜこれほど少ないのでしょうか？いくつかの理由があります。最近まで、新しいカラーフォントフォーマット（COLR/CPAL v1）のクロスブラウザサポートが不完全でした。カラーフォントを作成したり、絵文字以外のユースケースを見つけることは一般的ではありませんでした。そして多くの潜在的なユース（アイコン、シンボル）は代わりにSVGや画像として提供されていました。

カラーフォントを使用している少数のサイトを見ると、何のために使用されているのでしょうか？データは、カラーフォントを持つページの大多数が絵文字や特殊なアイコノグラフィのために使用していることを示しています。実際、断然最も一般的なカラーフォントはNoto Color Emoji（COLRとCBDTビットマップを含む複数のフォーマットを持つGoogle/Androidの絵文字フォント）です。Noto Color Emojiはカラーフォントを使用するデスクトップページの約73%（およびモバイルのカラーフォントページの多数）に表示されています。基本的に、カラーフォントを使用しているほとんどのサイトは、OSの絵文字に頼るのではなく、一貫した外観で絵文字をレンダリングするためにそれを使用しています。その後、かなりの部分は2つの日本語カラーSVGフォント（特定のサイトで装飾的なテキストとして使用される）によるもので、それぞれカラーフォント使用ページの7%と5%を占めています。それ以外はロングテールです。Twemoji（Twitterの絵文字）が数パーセント、カラーレイヤーを持ついくつかのアイコンフォント、そして一握りの装飾的な多色テキストフォントです。

カラーフォント技術の観点から、いくつかのフォーマットがあります。SVG-in-OpenType、COLR/CPAL（v0とv1）、および古いビットマップフォント（GoogleのビットマップのCBDT/CBLC、AppleのSbix）。2025年のフォントリクエスト別の使用内訳は、大まかにSVGが58〜60%、COLR v0が25%、COLR v1が16%、CBDT/sbix（ビットマップ）が数パーセントです。SVGが最も高いのは興味深いことです。これは実際にはSVGベースで高トラフィックページで使用されているあの2つの日本語フォントのためです。COLR v0（レイヤードベクターグリフフォーマットの最初のバージョン）は多くの現在のカラーフォント（一部の絵文字セットやアイコンフォントを含む）で使用されています。グラデーションを許可し絵文字にとってよりコンパクトなCOLR v1は新しいですが、すでに〜16%を占めています。これはNoto Emoji COLR v1のような更新された絵文字フォントから来ている可能性が高いです。ビットマップフォーマット（GoogleのカラーフォントのCBDT、AppleのSbix）は今やウェブ上ではほぼ無視できるほどです。それらはネイティブアプリ向けでした。

もう1つの注目すべき現象は、一部のカラーフォントが互換性のために複数のフォーマットを含んでいることです。例えば、Noto Color EmojiはCBDTとCOLRの両方のテーブルを持っている可能性があります。これは「ファミリー」でカウントすると、そのフォントを複数のフォーマットカテゴリでダブルカウントする可能性があることを意味します。しかし、使用の観点からは、ブラウザサポートの増加でCOLR v1が勢いを得ています（絵文字にとってSVGやビットマップよりもはるかに効率的です）。

カラーフォント内のカラーパレット（フォントが異なるプリセットのカラースキームを提供するもの）は広く使用されていません。カラーフォントの95%以上は、定義されたパレットがゼロまたは1つです。つまり、固定された色のセットを持っているか、デフォルトに依存しています。複数のパレットを持つのはごくわずかです（例えば、パレットメカニズムを通じてスキントーンやテーマを切り替えられる絵文字フォントなど）。そして複数のパレットを持つカラーフォントは、多くの場合せいぜい2〜3つです。今日のほとんどのカラーフォントはテーマカラーの切り替えを提供することを目指していません。必要な色をハードコードしているだけです。これは当然のことです。テーマの切り替えの場所はCSSでのフォントパレットオーバーライドにあり、フォントにあるのではありません。

今日使用されているほとんどのカラーフォントのカラーレイヤーの数も小さいです。多くのアイコンフォントは2色のみ（例：前景と背景）を使用する可能性があります。より多くのレイヤーはフルの絵文字セット（すべての絵文字文字を構築するために数百のレイヤーを持つ可能性がある）にのみ表示されます。

量的に見ると、カラーフォントリクエストの約32〜37%が絵文字用であることがわかります（このパーセンテージは2024年に上昇し、他の用途が成長するにつれて今年はわずかに低下しています）。そのトレンドは、カラーフォントリクエストの多数（〜63〜68%）が現在は非絵文字用途（装飾的なCJKフォントや多色アイコンなど）であることを意味します。しかし、ページ数では、絵文字フォント（特にNoto Color Emoji）は依然としてカラーフォントの主要な使用です。一部の大きなプラットフォームやサイトがNoto Color Emojiをフォールバックとして含み、多くのページに貢献している可能性がある一方で、他のカラーフォントは少数のページで使用されているが、多くのページビューを持つサイトの装飾フォントのように多数回フェッチされる可能性があります。

2025年、カラーフォントはウェブ上の新奇なものとして残っています。成長していますが、微小な基盤から始まっています。ほとんどの開発者はそれらを必要としないか、過去のサポートの問題のために避けています。カラーフォントを使用している人は、主に一貫した絵文字レンダリングを確保するか、非常にカスタムな何か（多色のロゴタイプやアイコンなど）を行っています。ブラウザサポートが安定するにつれ（COLR v1は現在Chrome、Edge、Firefoxでサポートされています）、より多くの使用が見られるかもしれません。例えば、一部の人々がOS間で一致するカラーの絵文字を持つために絵文字フォントを埋め込み始める可能性があります。しかし今のところ、高度なフォーマットの観点から、カラーフォントはウェブ上の可変フォントより数百倍一般的でありません。

結論

2025年のウェブフォントの状況は、主要な変化ではなく段階的な改善が続く、成熟しほぼ遍在する技術を描いています。過去10年間で、ウェブフォントは周辺的な機能からウェブの本質的な部分へと変貌しました。10のサイトのうちほぼ9つが使用しており、その割合は毎年ゆっくりと完全な飽和に向かっています。

過去数年に観察されたいくつかの主要なトレンドが確固たるものとなりました：

セルフホストとサービスの比較: ウェブフォントの配信はサービスからセルフホストへとゆっくりと移行しています。Google Fontsは依然として全ウェブサイトの半数以上にフォントを提供していますが、パフォーマンスやプライバシーのために自分でフォントをホストすることを選ぶ開発者が増えるにつれ、そのシェアは緩やかに低下しています。今では約3分の1のサイトがすべてのフォントをセルフホストしており、数年前の約5分の1から増加しています。別の大きなシェアのサイトはGoogleのCDNとセルフホストのハイブリッドを使用しています。これは、開発者がサードパーティのインフラに完全に依存しているわけではなく、キャッシングとローディングを自分のニーズに合わせて最適化できるバランスを示しています。
フォーマットの統合: ウェブはWOFF2をプライマリフォントフォーマットとして標準化しました。フォントファイルの約65%はWOFF2であり、WOFFと合わせると約81%です。生のTTF、EOT、SVGフォントなどの古いフォーマットはほぼ完全に廃止されています。この統合はパフォーマンスに優れており（WOFF2は圧縮が優れています）、開発者がサポートする必要があるものを簡素化します。データは、ほとんどのサイトがこの方向に従っていることを示していますが、一部のセルフホスト環境はまだWOFF2の提供または正しいMIMEタイプの送信で遅れています。
フォントのサイズとパフォーマンス: 典型的なウェブフォントは30〜40 KBの範囲（圧縮後）であり、サイトはしばしば複数のフォントを使用するため、フォントは依然としてわずかな重量コストを持っています。中央値のサイズは最近わずかに増加しており、より豊富なフォント（例：可変フォントやより多くのグリフを持つフォント）を反映しています。フォントの相当部分は100 KBを超えており、特にアジア系書体やサブセット化されていない場合です。これはサブセット化と慎重なローディング戦略の重要性を強調しています。これらのフォントのほとんどが現在WOFF2であることはコストを軽減するのに役立ちますが、開発者は依然として注意が必要です。多くの大きなフォントファイルの多用はロードスピードを損なう可能性があります。2025年のクロールデータは、ほとんどのサイトがフォントの使用において適度であることを示していますが、小さなパーセンテージがやり過ぎで配布の「テール」を劇的に歪めています。
グローバルスクリプト: ウェブタイポグラフィはよりグローバルにフォーカスされるようになり、ラテン文字を超えた言語のサポートが大きくなっています。毎年、キリル文字、ギリシャ語、アラビア語、ヘブライ語、デバナーガリー、CJKなどがウェブフォントの使用に意味のある存在として見られます。これは主に、これらの書体の高品質フォントを生産する協働プロジェクトとオープンソースの取り組みのおかげです。ウェブフォントがほぼ独占的にラテン文字向けに開発されていた2010年代初頭からの大きな変化です。今では、開発者はさまざまな書記体系のウェブフォントを見つけることを合理的に期待できます。データは特に、Notoなどのフォントファミリーのおかげで成長を続ける日本語と韓国語のウェブフォントの採用を強調しています。中国語はファイルサイズのために依然としてより困難な問題ですが、インクリメンタルフォント転送（IFT）—フォントの必要な部分だけをオンザフライでロードする方法—などの技術が将来それを変える可能性があります（これは地平線上にあり、巨大なフォントにとってのブレークスルーになる可能性がありますが、依然として実験的です）。
可変フォント: かつては最先端のコンセプトだった可変フォントは、今やメインストリームです。約40%のウェブサイトがそれらを使用しており、しばしばGoogle Fontsが複数の静的ファイルの代わりに可変ファイルを提供することで透過的に行われています。豪華なアニメーションやコンテンツの継続的な変動性という点でデザインをまだ革命的には変えていませんが、実用的な利益をもたらしました：フォントリクエストを簡素化し、複数のスタイルが必要な場合に総バイト数を削減することがあります。多くの人気フォントは現在デフォルトで可変です（Robotoなど）、そして開発者はほとんどの場合、以前に複数のウェイトを使用してきたように使用しています—ただし、希望すればより細かい制御のボーナスがあります。
カラーフォント: カラーフォント（COLR/CPAL、SVGグリフ）のサポートが成長しているにもかかわらず、それらはウェブ上でまだ稀です。絵文字の使用を除いて、多色のグリフを利用しているサイトは少ないです。注目すべき領域として残っていますが、2025年現在、カラーフォントはまだ一般的なウェブ使用において足場を見つけていません。
レンダリングのためのCSS: より多くのサイトが利用可能なCSSを使用してフォントのロードとレンダリングを最適化しています。font-displayは現在フォントを使用するサイトの多数に指定されており、FOIT/FOUTについての意識的な選択を反映しています。swapの主要な使用は、アイコンフォントのみが整合性のために意図的に遅延させていて、テキストの素早い表示に対する共有の優先度を示しています。preconnectやpreloadなどのリソースヒントはユニバーサルではありませんが、健全な少数派がこれらの技術を採用しており、パフォーマンスを意識した開発プラクティスが増加していることを示しています。また、まだニッチですが、text-wrap: balanceやhyphens: autoなどのプロパティの採用は、より細かいタイポグラフィの調整がテキストレイアウトの改善のために徐々に普及していることを示しています。本質的に、ウェブ開発者はすべてをデフォルトに任せるのではなく、フォントのロード方法とテキストのフロー方法をより積極的に管理しています。これはエコシステムが成熟しているサインであり、フロントエンド開発者が他のパフォーマンスやUXの側面と同じ真剣さでタイポグラフィを扱っています。

全体的に、2025年のウェブフォントは収束と洗練の物語を語っています。フォーマット（あらゆる場所でWOFF2）、配信パターン（セルフホストが増加しているが、サービスも依然として重要）、広く使用されるファミリー（少数のウェブフォントが今や事実上コアになっている）、ベストプラクティス（font-display: swap、重要なフォントのプリロードなど）の収束が見られます。洗練にはグローバル言語サポートの改善、OpenType機能の使用、テキスト表示の粗い端を滑らかにするための新しいCSS機能が含まれます。したがって、ウェブフォントの景観は概して安定していますが、停滞していません。単一の変化がヘッドラインを掴むことはありませんが、これらの発展が集合的にウェブをより磨かれたものにしてアクセス可能にしています。

フォントの次の主要な発展は何でしょうか？述べたように、インクリメンタルフォント転送（IFT）は非常に有望な新技術です。ファイル全体をフロントローディングするのではなく、ブラウザが特定のテキストセットのためにフォントの必要なグリフのみをダウンロードすることを可能にします。標準化され採用されれば、IFTはCJK、絵文字、アイコンセットのような巨大なフォントにとって革命的になる可能性があります—「フォントサイズ」の問題を効果的に解決します。この技術はまだ開発中ですが、来年のWeb Almanacにはアイナンスルおよびインパクトに関するデータが報告できるかもしれません。

そして、2025年のチャプターは自信を持って幕を閉じます：フォントはウェブの基本的な構成要素であり、ほとんどの開発者によって賢く使用されており、前途はそれらをより速く、より包括的に、より表現豊かに、そして誰にとっても扱いやすくすることです。