フォントをサブセットにまとめることでパフォーマンスが向上します。サブセット化して、旧式のブラウザの場合は代わりに手動でサブセット化します。スタイル別の派生フォントの数が減り、ページやテキスト表示のパフォーマンスが向上します。コードポイントを定義できます。ファミリー」を構築できます。リソースをダウンロードして現在のページに適用する必要があるのかを判断します。リソースの場所の優先順位付きリストを指定)を指定します。いう単一のファミリーを定義しています。セットを指しています。ディスクリプタには、カンマで区切られた派生リソースの優先順位付きリストが含まれています。ディレクティブを使うと、ローカルにインストールされているフォントを参照、読み込み、使用できます。ディレクティブを使うと、外部フォントの読み込みができます。よって参照されるフォントの形式を指定できます。フォントをローカルにインストールしていることはほとんどありません。モバイル端末では、追加のフォントを「インストール」することは実質的に不可能です。エントリのリストを指定する必要があります。ブラウザは、フォントが必要であると判断すると、指定されたリソースリストを指定された順序で調べ、該当するリソースの読み込みを試みます。前の例では次のようになります。ブラウザは、ページのレイアウトを行い、指定されたテキストをページに表示するためにどの派生フォントが必要なのかを判断します。それぞれの必要なフォントについて、ブラウザは、ローカルのフォントが使用できるかどうかを調べます。ローカルのフォントが使用できない場合は、ブラウザは外部定義を順番に調べます。形式ヒントが存在する場合、ブラウザは自身がサポートしているかどうかを調べ、サポートしている場合はダウンロードを開始します。そのヒントをサポートしていない場合は、次の形式ヒントを調べます。形式ヒントが存在しない場合、ブラウザはリソースをダウンロードします。外部ディレクティブと適切な形式ヒントを組み合わせて使うことで、使用可能なすべてのフォント形式を指定して、残りの処理をブラウザに任せることができます。ブラウザは、どのリソースが必要なのかを判断して、最適な形式を自動的に選択します。派生フォントの指定順序は重要です。ブラウザは、サポートする最初の形式を選択します。コードポイントのセットを定義することもできます。フォントをより小さいサブセット(ラテン、キリル、ギリシャの各文字のサブセットなど)に分割し、特定のページでテキストをレンダリングするために必要なグリフだけをダウンロードできます。ディスクリプタを使うと、カンマで区切られた範囲値のリストを指定できます。つのうちいずれかの形式で指定できます。ファミリーをラテン語と日本語のサブセットに分割し、ブラウザがそれぞれのサブセットを必要に応じてダウンロードするようにできます。よるサブセット化は特にアジア系の言語で重要です。これらの言語では、グリフの数が西洋言語よりもずっと多く、通常の「フル装備の」フォントではそのサイズが数十キロバイト単位ではなく数メガバイト単位に及ぶことが多くあります。ファミリーを定義できます。必要な派生フォントやサブセットをダウンロードするだけで済み、ページ上で表示されたり使用されたりすることが決してないサブセットをダウンロードする必要がなくなります。すべてのブラウザがサポートしているわけではないという小さな欠点があります。宣言をまったく処理しないブラウザもあります。した問題に対処するには、旧式のブラウザで代わりに「手動サブセット化」を行う必要があります。リソースを提供して、残りをブラウザから隠す必要があります。ページでラテン文字しか使われていない場合は、それ以外のグリフを取り除いて、特定のサブセットを単独のリソースとして利用することができます。よるサブセット化がブラウザでサポートされている場合は、自動的に適切なサブセットが選択されます。ルールで指定するだけで済みます。よるサブセット化がサポートされない場合は、ページで不要なサブセットをすべて隠す必要があります。デベロッパーが必要なサブセットを指定する必要があります。フォントのサブセット化と最適化を行います。パラメータによる手動サブセット化が可能です。この方法を使ってページで必要なサブセットを手動で指定できます。詳しくはフォント提供者のマニュアルをご覧ください。ファミリーはそれぞれ、複数のスタイル別の派生フォント(標準、太字、斜体)と、スタイルごとの複数のウェイトで構成されますが、さらにスタイルに含まれるグリフ形状がスタイルごとに大きく異なる場合があります。スペーシングやサイジングが異なる場合や、形状が完全に異なる場合があります。それ以外のウェイトの派生フォント(グレーで表示)はすべて、ブラウザによって最も近い派生フォントに自動的にマッピングされます。指定されたウェイトに対応するフェースが存在しない場合は、それに近いウェイトのフェースが使用されます。一般に、太字のウェイトは、より重いウェイトのフェースにマッピングされ、細字のウェイトは、より軽いウェイトのフェースにマッピングされます。派生フォントにも同様のロジックが適用されます。デザイナーはどの派生フォントを生成するのかをコントロールし、ユーザーはどの派生フォントをページ上で使用するのかをコントロールします。派生フォントはそれぞれ別々のダウンロードになるため、派生フォントの数は少なく保つことをおすすめします。つの太字の派生フォントを定義できます。つのリソースで構成されています。つの異なる「ウェイト」を提供します。プロパティを斜体に設定したりした場合はどうなるでしょうか。正確に一致するフォントが見つからない場合、ブラウザは最も近いものを代用します。スタイルが一致するフォントが見つからない場合(上の例で斜体の派生フォントを宣言しなかった場合など)、ブラウザは独自の派生フォントを合成します。作成者は、斜体にすると形状が大きく変わるキリル文字など、合成による方法が適さない場合があることにも注意する必要があります。これらのスクリプトを正しく再現するためには、実際の斜体フォントを使用してください。おける実際のフォントと合成フォントの違いを示しています。ウェイトのフォントから生成されます。ご覧のように、著しい違いが見られます。太字と斜体の派生フォントを生成する方法の詳細は指定されていません。したがって、その結果はブラウザごとに異なり、またフォントに大きく依存します。最適な一貫性と見栄えを保つには、合成フォントを使用しないようにします。代わりに、使用する派生フォントの数を最小限に抑えて、それらの場所を指定してください。することで、ページ上で使用されているときにブラウザがフォントをダウンロードできます。場合によっては[合成の派生フォント]。使用の際は注意してください。ツリーが構築されるまで遅延されるため、テキストのレンダリングが遅れることがあります。フォントの読み込みとレンダリング処理を実装するために必要なフックを提供します。「フル装備の」ウェブフォントには、場合によっては必要ないスタイル別派生フォントや、使用されないグリフもすべて含まれているため、ダウンロードのサイズがあっという間に数メガバイトに及んでしまいます。サブセット、個別のスタイル別派生フォントなど)に分割できるようになっています。これらが宣言されている場合、ブラウザは必要なサブセットや派生フォントを判断して、テキストのレンダリングに最小限必要なセットをダウンロードします。パスの中でパフォーマンスのボトルネックが生じたり、テキストのレンダリングが遅れたりするなど、回避すべき副作用が生じる可能性もあるので注意が必要です。デフォルトの動作フォントの遅延読み込みは、実はテキストのレンダリングが遅れるという重要な問題を引き起こす場合があります。ツリーを構築する必要があります。その結果、フォントのリクエストが他の重要なリソースよりもずっと後になるため、リソースを取得するまでブラウザでのテキストのレンダリングがブロックされることがあります。ドキュメントをリクエストします。CSS、JS、その他のリソースを検出し、リクエストを送信します。リクエストが送信されます。ブラウザがレイアウトを実行し、コンテンツを画面にペイントします。ピクセルもレンダリングできません。ピクセルをペイントします。レイアウトをレンダリングする一方で、すべてのテキストは省略する「空テキスト問題」が発生します。次のセクションでは、このデフォルトの動作をカスタマイズするためのいくつかのオプションについて説明します。利用することができます。含めることができます。特定のリソースがすぐに必要になるというブラウザへの「ヒント」として役立ちますが、ブラウザにその使い方を教えることはしません。@font-face定義と一緒にプリロードを使用する必要があります。常にプリロードする必要があるフォーマットです。対して無条件で優先度の高いリクエストが送られます。使用は無駄なリクエストになります。コンソールに警告が表示されます。フォントが使用可能である可能性が高くなりますが、その保証はありません。使用するテキストをレンダリングする場合に、ブラウザがどのように動作するかを考慮する必要があります。レイアウトをレンダリングする一方で、すべてのテキストは省略する「空テキスト問題」が発生します。フォントがダウンロードされるのを待つ最大タイムアウトを実装しています。その後、代替フォントが使用されます。残念ながら、その実装方法はブラウザによって異なります。秒のタイムアウトがあり、その後テキストは代替フォントで表示されます。フォントがダウンロードに成功した場合、最終的にスワップが発生し、テキストは意図したフォントで再レンダリングされます。秒で、即時にテキストのレンダリングが行われます。リクエストされたフォントがまだ使用できない場合は代替フォントが使用され、リクエストされたフォントが利用可能になるとテキストの再レンダリングを行います。タイムアウトの振る舞いはありません(ベースラインのネットワークタイムアウト以外のものはありません)。記述子、font-display、および対応するプロパティを提案しました。ダウンロード可能フォントが読み込まれる前にレンダリングする方法を制御するためのものです。つの主要な期間に分割します。フェースでレンダリングされる必要があります。フェースは通常どおりに使用されます。ブロック期の直後に発生します。フェースでレンダリングされる必要があります。フェースは通常どおりに使用されます。スワップ期の直後に発生します。フェースがまだロードされていない場合、読み込み失敗としてマークされ、通常の代替フォントが使用されます。フェースが通常どおりに使用されます。使用して、フォントがダウンロードされたかどうか、またはいつダウンロードされるかによってフォントのレンダリング方法を決定できます。ルールにそれを追加します。使用するフォント表示戦略を必ず使用します。似たデフォルト戦略を持っています。秒が推奨されます)、スワップ期は無限になります。フェースを入れ替えます。フェースを作成します。この値は、ページを使用可能にするために特定の書体でテキストをレンダリングすることが必要な場合にのみ使用する必要があります。秒でスワップ期は無限になります。フェースがロードされていない場合、ブラウザは代替フォントですぐにテキストを描画しますが、ロードされるとすぐにフォントフェースを入れ替えます。同様に、この値は、特定のフォントでテキストをレンダリングすることがページにとって重要ではあるが、どのフォントでレンダリングしてもメッセージは正しく表示される場合にのみ使用する必要があります。候補として適しています。合理的な代替フォントを使用して会社の名前を表示すればメッセージは伝わりますが、最終的には正式な書体を使用することになるためです。秒が推奨されます)なります。フェースが読み込まれていない場合、最初は代替フォントでレンダリングされますが、読み込まれるとすぐにフォントが入れ替わります。時間がかかりすぎると、残りのページの有効期間は代替フォントが使用されます。本文のようなものに適しています。ユーザーにできるだけ早く読み始めてもらうと同時に、新しいフォントの読み込み時にテキストを移動させてユーザーの邪魔をしたくないからです。使用感にとって重要ではない場合に適しています。値は、フォントのダウンロードを開始するかどうかをブラウザに任せます。ユーザーにとって最適と思われることに応じて、フォントのダウンロードをしない場合も、ダウンロードの優先順位を低くする場合もあります。これは、ユーザーの接続が遅いため、フォントの取り込みがリソースの最善の使い方ではないような状況では有益です。新しいブラウザの多くで採用されています。これがより広く採用されるにつれて、ブラウザの一貫した振る舞いを期待することができます。一緒に使用すると、開発者はオーバーヘッドを増やすことなく、フォントの読み込みとレンダリングを大幅に制御できます。実行によるオーバーヘッドが問題ない場合は、別の選択肢があります。フェースを定義および操作すること、それらのダウンロードの進行状況を追跡すること、デフォルトの遅延読み込み動作をオーバーライドすることが可能です。リソースの取得を直ちに開始するようブラウザに指示することができます。メソッドを通じて)確認し、ダウンロードの進行状況を追跡できるので、ページにテキストを表示するための独自の方法を定義することもできます。フォントが使用可能になるまですべてのテキストの表示を保留できます。フォントごとに独自のタイムアウトを実装できます。代替フォントを使用して表示の保留を解除し、フォントが使用可能になった時点で、目的のフォントを使用した新しいスタイルを表示できます。ページ上のさまざまなコンテンツに対して上記の方法を組み合わせることもできます。「フォントが使用可能になるまで一部のセクションでテキストの表示を保留する」、「代替フォントを使用し、フォントのダウンロードが完了したら再表示する」、「さまざまなタイムアウトを指定する」などの方法を利用できます。一部のブラウザではまだ開発段階です。ライブラリを使用して同様の機能を提供することを検討してください。依存性が高まることによるオーバーヘッドがあります。リソースは通常は静的なリソースであり、頻繁に更新されることはありません。有効期限を長く指定する対象として適しています。ポリシーの両方を必ず指定してください。ケースに適しています。使って保存するべきではありません。これらには、独自のパフォーマンス問題があります。リソースを提供するための最も確実で最適なメカニズムです。最適化チェックリスト一般的な理解に反して、ウェブフォントを利用することで必ずページのレンダリングが遅れたり、その他のパフォーマンス指標に悪影響が生じたりするわけではありません。エクスペリエンスを大幅に向上できます。優れたブランディング、読みやすさの向上、ユーザビリティ、検索機能を備えながら、あらゆる画面形式と解像度にうまく対応する、複数の解像度に対応した拡張可能なソリューションを提供できます。ウェブフォントを積極的に活用しましょう。安易に実装すると、大量のダウンロードや不要な遅延を招くおそれがあります。アセット自体を最適化し、それらを取得してページ上で利用する方法を最適化できるようにすることにより、ブラウザに負荷がかからないようにする必要があります。ページ上で使用するフォントの数を多すぎないようにし、フォントごとに使用する派生フォントの数を最小限に抑えます。エクスペリエンスの一貫性が高まり、動作が高速になります。分割が可能で、特定のページで必要なグリフだけを提供できます。その結果、ファイルサイズが小さくなり、リソースのダウンロード速度が改善されます。サブセットを定義する際はフォントの再利用を考慮して注意深く最適化してください。ページごとに異なる文字セットをダウンロードする際、文字セットに重複が生じないようにします。スクリプト(ラテン文字やキリル文字など)に基づいてサブセット化することをおすすめします。