98

Cufonを使用してトラブルが発生して以来、外部のフォントリソースを使用することはしませんでしたが、最近では、フォントをロードする別の方法を探して、より良い方法があるかどうかを確認しています。優れたメソッドには、突然に現れる方法があります。

多くの新しいメソッドがあり、メソッドごとにバリエーションがあるようです。タイプキットを使用する必要がありますか？またはgoogle webfonts（jsまたはcssを使用）？ローカルでロードするフォント（fontsquirrel.comで生成されたメソッドなど）を引き続き使用する必要がありますか？

いくつかのテストを行い、最もよく受け入れられていると思われるメソッドを以下にリストしますが、Webフォントに移行する価値はありますか？リソースの負荷（http要求）が多く、ファイル形式の種類が少ない（互換性が低い）などのようですが、ほとんどの場合、ファイルは非同期で効率的に読み込まれるように見えます。

それは単に状況と必要性の問題ですか？もしそうなら、それらは何ですか？
これらの方法には大きな違いがありますか？
私がリストしていないより良い方法はありますか？
パフォーマンスのプロ/コンは何ですか？見て？依存関係？互換性？

私はここでベストプラクティスを本当に探しています。パフォーマンスは重要ですが、スケーラビリティと使いやすさも重要です。言うまでもなく、ルックアンドフィール。

Google CSS

外部スタイルシートのみを使用
互換性のある最小のファイルタイプのみを使用
は、styleshee（）のコンテンツを使用@importまたは<link>取得@font-faceして、独自のスタイルシートに直接配置できます。

試験結果

  78ms load of html
  36ms load of css

ここに画像の説明を入力してください

Google JSメソッド

webfont.jsスタイルセットの読み込みに使用します
互換性のある最小のファイルタイプのみを使用
:rootクラスに要素を追加します
頭にスクリプトを追加します。

試験結果

    171ms load of html
    176ms load of js
    32ms load of css

ここに画像の説明を入力してください

Typekitメソッド

:root要素をクラスに追加します。
*.jsスニペットまたは外部から読み込まれたファイル*.jsfileを使用できます
data:font/opentypeフォントファイルの代わりに使用します。
頭にスクリプトを追加
埋め込みcssをヘッドに追加します
外部スタイルシートをヘッドに追加します

typekit.comからフォントとターゲットセレクタを簡単に追加/削除/調整できます

試験結果

  169ms load of html
  213ms load of js
  31ms load of css
  3ms load of data:font/

ここに画像の説明を入力してください

…＆Font Squirrelメソッド

@font-face{
    font-weight:400;
    font-style:normal;
    font-family:open_sanslight;
    src:url(../font/opensans-light-webfont.eot);
    src:url(../font/opensans-light-webfont.eot?#iefix) format(embedded-opentype),
        url(../font/opensans-light-webfont.woff) format(woff),
        url(../font/opensans-light-webfont.ttf) format(truetype),
        url(../font/opensans-light-webfont.svg#open_sanslight) format(svg)
}

…またはdata：fontメソッドで…

@font-face {
    font-family: 'open_sanslight';
    src: url('opensans-light-webfont-f.eot');
}

@font-face {
    font-family: 'open_sanslight';
    src: url(data:application/x-font-woff;charset=utf-8;base64,d09GRgABAAAAAF4sABMAAAAArXQAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAABGRlRNAAABqAAAABwAAAAcZLn0KkqwK44Jq866WBSpzpsNY2IyGAhoJFBbYjuxmyns5sNa4NwldcJ7eh3Uy5gQkURIlqWzONe3HcLsDX1x/+jifDXvbzgTBjopZElndil3hJkERJkmRJkVRJk3TJkEzJkmzOc4HLXOEOF7nEX/*thisisnotafullencodingjustanexample*/bZwUnK4yS3JlTx2Sr4USKEUSbHVX9fcGNBs4fqgw+GoNHU7lKr36Eqn0lCWt6pHFpWaUlc6lS6loSxRlirLlP/uuU01dVfT7L6gPxyqraluCpgj3WtqeC1V4VBDW2N4K1r1esw/IupKp9L1FwlqnuIAAAB42j3NvQ7BUBjG8R5tTz/0u2UjNTTESYQbMGmXLiISbeI6zBYjbuWtye7CeMJxtuf3LP8ne1+IXbWa7G3TMXZru4qLZkJRW1O2wzi3I+Li2Gik5yXpYkNGXj70YU98YQLGHxwwXxIWwO8SNmAdJBzAXku4gFNI9AF38QMjTwZ9vN6yJzq9OoEB6I8VQzDYK0ZguFKMwWiumIDxTDEFk6liBqaF4gDMFFvKxAfOxFUGAAABUxSL9gAA) format('woff'),
         url('opensans-light-webfont-f.ttf') format('truetype'),
         url('opensans-light-webfont-f.svg#open_sanslight') format('svg');
    font-weight: normal;
    font-style: normal;

}

— ダーチャー
ソース

4

これはいい質問です。

— dachi 14年

1

それが最善の方法であるかどうかは<link href='http://fonts.googleapis.com/css?family=Open+Sans:300' rel='stylesheet'>

— わかり

font-squirrelのようなWebサイトをローカルWebフォント専用に開発しましたGeorgian。私はfont-squirrelメソッドを使用していますが、この質問にも素晴らしい回答を期待しています。

— だち

1

これは、防弾@font-face宣言を宣言する方法に関する非常に優れた記事です。おそらく役立つ情報を見つけることができます。paulirish.com/2009/bulletproof-font-face-implementation-syntax

— lefoy

あなたがそれを受け入れない限り、私はより良い/改善された答えのために利用できるとき報奨金を始めることができます。

— ダビット、2014年

34

まず、Googleのサービスについて明らかにします。ブラウザが処理できる最小の形式を実際にロードします。WOFFは小さなファイルサイズを提供し、ブラウザはそれをサポートしているので、これが目に見えるものです。WOFFもかなり広くサポートされています。ただし、たとえばOperaでは、フォントのTrueTypeバージョンを取得します。

ファイルサイズのロジックも、Font Squirrelがこの順序で試行する理由だと思います。しかし、それはほとんど私の側の推測です。

すべてのリクエストとバイトがカウントされる環境で作業している場合は、プロファイリングを行って、ユースケースに最適なものを見つける必要があります。人々は1ページしか表示せず、二度と訪問しないのでしょうか？その場合、キャッシングルールはそれほど重要ではありません。閲覧中または戻ってきている場合は、サーバーよりもGoogleの方がキャッシュルールが優れている可能性があります。レイテンシの方が大きな問題ですか、それとも帯域幅ですか。レイテンシの場合は、リクエストの数を減らしてローカルでホストし、ファイルをできるだけ結合します。帯域幅の場合は、どちらのオプションを選択しても、最小のコードと最小のフォント形式になります。

次に、CSSとJSの比較について説明します。次のHTMLを見てみましょう。

<head>
    <script type="text/javascript" src="script1.js"></script>
    <link rel="stylesheet" type="text/css" href="style1.css" />
    <style type="text/css">
        @import url(style2.css);
    </style>
    <script type="text/javascript">
        (function() {
            var wf = document.createElement('script');
            wf.src = 'script2.js';
            wf.type = 'text/javascript';
            wf.async = 'true';
            var s = document.getElementsByTagName('script')[0];
            s.parentNode.insertBefore(wf, s);
        })();
    </script>
</head>

多くの場合、script1、style1、およびstyle2ブロックされるだろう。つまり、ブラウザーは、そのリソースが読み込まれるまでドキュメントを表示し続けることができません（ただし、最近のブラウザーはこれを少し誤解しています）。特にスタイルシートの場合、これは実際には良いことです。これは、スタイルのないコンテンツのフラッシュを防ぎ、スタイルを適用するときに発生する大きなシフトも防ぎます（コンテンツのシフトは、ユーザーにとって本当に煩わしいものです）。

一方、script2ブロックはしません。それは後でロードすることができ、ブラウザはドキュメントの残りの部分を解析して表示することに移ることができます。そのため、それも有益です。

具体的にはフォント（さらに具体的には、Googleの提供物）について話していると、おそらくCSSメソッドにこだわるでしょう（@importスタイルシートでスタイルを維持するので気に入っていますが、それは私だけかもしれません）。スクリプトによってロードされたJSファイル（http://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js）は@font-face宣言よりも大きく、多くの作業のように見えます。また、実際のフォント自体（WOFFまたはTTF）の読み込みがブロックされているとは思わないので、遅延が多すぎないはずです。私は個人的にはCDNの大ファンではありませんが、実際にはCDNは非常に高速です。Googleのサーバーは、ほとんどの共有ホスティングプランを地滑りで打ち負かします。そのフォントは非常に人気があるため、人々はすでにそれらをキャッシュしているかもしれません。

そして、それは私が持っているすべてです。

私はTypekitを使った経験がないので、理論化は省きました。議論のためにブラウザ間の一般化を数えずに、不正確な点がある場合は、指摘してください。

— ザックラビット
ソース

これの大部分は状況によるものだと考えましたが、ブロッキングとFOUTの問題についても十分に注意してください。：私はここに読み込まpaulirish.com/2009/fighting-the-font-face-fout＆stevesouders.com/blog/2009/10/13/font-face-and-performance。今夜、いくつかのテストを実行してパフォーマンスの違いを投稿します。すばらしい洞察をありがとう。

— ダーチャー、2014年

11

あなたはあなたの質問でロード時間に非常にうまく対処したと思います。私の観点からは、リストに追加する必要があるいくつかのソースと、オプションの完全なビューを取得するために検討する必要があるいくつかの他の考慮事項があります。

他の信頼できるフォントソース

cloud.typography

http://www.typography.com/cloud/

私が知ることができることから、フォントはCSSファイルにデータとして埋め込まれています：

@font-face{ 
    font-family: "Font Name"; 
    src: url(data:application/x-font-woff;base64,d09GRk9UVE8AACSCAA0AAAAARKwAAQAAAAAiVAAAAi4AAAadAAAAAAAAAABDRkYgAAAIyAAAFCgAABmIK5m+CkdERUYAABzwAAAAHQAAACAAXQAER1BPUwAAHRAAAAQlAAAYAq+OkMNHU1VC ... ); 
    font-weight:400; font-style:normal; 
}

これが私のスペックです：

94ms load of css from their server
37ms load of css from our server (will vary based on your configuration)
195ms load of data:fonts from our server (will vary based on your configuration)

ここでは、彼らの展開に関する非常に高レベルの説明を示します。

Fonts.com

私はこのサービスを使用していませんが、非常に定評のあるフォントベンダーであり、彼らがサイトに掲載した情報は非常に印象的です。私はそれらの正確な方法についての仕様はありませんが、ここに私が彼らが知っていることを示します：

利用可能な世界で最も有名なフォントのいくつか
非常に大きなフォントライブラリ（20,000以上）
モックアップを作成するためのデスクトップフォントのダウンロード
ブラウザでWebフォントをテストするためのカスタムツール
タイポグラフィの細かい制御とサブセット
セルフホスティングオプション

FontSpring

FontSquirrelと提携しています。フォントはここで固定価格で購入できます。付随するCSSが提供するフォントファイルは、FontSquirrelと同じように、独自のサーバーに展開されます。

拡張された仕様

各フォントサービスの全体的な長所と短所について、いくつか比較します。

フォントライブラリのサイズ

Fonts.com：20,000以上
FontSpring：1000以上
FontSquirrel：300以上
Google：600以上
タイプキット：900+
Typography.com（cloud.typography.com）：おそらく300以上（35ファミリー）

価格

Fonts.com：500,000ページビューで月額$ 20
FontSpring：フォントによって異なります（1回限りのフォントの購入）
FontSquirrel：無料
Google：無料
Typekit：500,000ページビューで月額4ドル
Typography.com：1,000,000ページビューで$ 12.50 /月

フォント品質

Webフォントの品質はかなり異なる場合があります。これには、文字フォーム自体や、文字セットの間隔やサイズなどが含まれます。これらすべてが、フォントが与える全体的な品質の印象を決定します。無料のオプションにはいくつかの優れたオプションがありますが、高品質ではないフォントもいくつかあるため、これらのソースから慎重に選択する必要があります。

Fonts.com：高
FontSpring：混合から高
FontSquirrel：混合
Google：混合
タイプキット：高
Typography.com：非常に高い（Fonts.com、FontSpring、およびTypekitは複数のタイプファウンドリをサポートするため、これを「非常に高い」と指定します。これは、世界で最高のH＆FJファウンドリのフォントのみです）

フォント品質II：タイポグラフィ

デスクトップのタイポグラフィには、Webフォントを取得するのが非常に困難な多くの改良点があります。これらのサービスのいくつかは、それらを提供する方法を提供します。

Fonts.com：カーニング、レタースペース、合字、代替文字、分数など
FontSpring：なし
FontSquirrel：なし
Google：なし
タイプキット：なし
Typography.com：小文字、合字、代替文字、代替番号のスタイル、分数など

ブラウザのサポート

これは主に、各サービスでサポートされているフォント形式に起因します。主なものは次のとおりです。

EOT：Internet Explorer（IE 4以降）
TrueTypeおよびOpenType：従来の形式（Safari 3.1以降、FF 3.5以降、Opera 10以降）
WOFF：Webフォントの新しい標準（FF 3.6以降、Chrome 5以降）
SVG：IOS <4.2

@ Font-Faceルールと便利なWebフォントトリックの詳細情報

これらのサービスはすべて、主要なフォント形式をサポートしています。自己ホスト型フォントでは、正しい構文を使用している限り、カバーする必要があります。FontSpringからの防弾構文の2011年の更新は次のとおりです。

@font-face {
  font-family: 'MyWebFont';
  src: url('webfont.eot'); /* IE9 Compat Modes */
  src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('webfont.woff') format('woff'), /* Modern Browsers */
       url('webfont.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */
  }

パフォーマンスI：ダウンロード

私が理解している限り、上記の構文を使用することで、ブラウザーはそれらに有効な特定のフォーマットを取得できるため、機能しないフォントフォーマットを無駄にダウンロードすることはありません。

Fonts.com、Typekit、またはTypography.com使用方法などの有料サービスは、正しい形式を検出し、することが、その後 CSSファイル内のbase64データとして、多くの場合、右のフォントフォーマットを提供します。

私が見ることができることから、上記の方法の違いは高速インターネットユーザーにはほとんど無視できます（200ミリ秒未満の差のようです）が、特にキャッシュされていないページヒットの場合、低速ネットワーク上のデバイスを検討する価値があります。

パフォーマンスII：サブセット化

使用したい特定の文字のみが存在することがわかっている場合は、文字のサブセットを使用してフォントを作成し、ダウンロードのサイズを小さくすることができます。

Fonts.com：非常に詳細な制御
FontSpring：FontSquirrel webfontジェネレーターを介してサブセットとして再コンパイルできます
FontSquirrel：webfontジェネレーターを介してサブセットとして再コンパイルできます
Google：非常に詳細な制御
Typekit：「すべての文字」または「デフォルト」の限定オプション
Typography.com：非常に詳細な制御

パフォーマンスIII：配信

Fonts.com：グローバルCDN または独自のサーバー
FontSpring：サーバーに基づく
FontSquirrel：サーバーに基づく
Google：グローバルスーパーCDN
Typekit：グローバルCDN
Typography.com：グローバルCDN（125,000サーバー）

言語サポート

Fonts.com：アジアおよび中東を含む40言語
FontSpring：フォントに応じた西洋
FontSquirrel：欧文、フォントに依存
Google：フォント、西洋
Typekit：フォント、西洋
Typography.com：フォントに応じて西洋

テストと実装

Fonts.com：非常に簡単で、豊富でカスタマイズ可能なツール
FontSpring：Technical（自分でやる）
FontSquirrel：テクニカル（自分でやる）
Google：簡単
タイプキット：簡単
Typography.com：簡単なテスト、導入後の変更にはもう少し複雑

— Nwalton
ソース

これはOPの質問には答えません。いくつかのWebフォントを比較するだけです。

— stackErr 2014年

これは、すべての情報に感謝し、各ベンダーで最も有益です。

— ダーチャー2014年

10

まあ、あなたがそうしているように

...ここでベストプラクティスを探すと、パフォーマンスは重要ですが、スケーラビリティと使いやすさも重要です。言うまでもなく、ルックアンドフィール。

答えは（いつものWebデザインのように）：場合によります！

確かなことの1つは、JSアプローチ（2番目の例に示されている）を使用することをお勧めしないことです。

個人的には、大多数のユーザーがJavaScriptを有効にしているにもかかわらず、JavaScriptに応じてプレゼンテーションやCSSスタイルを作成するのは嫌いです。混同しないという問題です。

そして、あなたの与えられた例で見ることができるように、フォントが利用可能になる前にページがブラウザによってすでにレンダリングされているため、ある種のFOUC（スタイルのないコンテンツのフレー）があります。すぐに、ページが再描画されます。また、サイトが大きいほど、（パフォーマンス）への影響も大きくなります。

したがって、フォントの埋め込みにJSソリューションを使用することはありません。

それでは、純粋なCSSメソッドを見てみましょう。
かなり長い間、ここでは「vs. @import」についての議論があります。個人的には@importの使用を避け、常にのみ使用することを好み<link>ます。しかし、これは主に個人的な好みの問題です。絶対にしてはいけないことは、両方を混ぜることです！

ローカルとCDN
フォントファイルをローカルでホストするか、CDNを使用するかを決定する場合、ほとんどの場合、異なるフォントの数と、埋め込むそれぞれのフォントによって異なります。

なぜこれが重要なのか、または役割を果たすのか？
パフォーマンスの観点から、（1つの）スタイルシートにエンコードされたフォントBase64を含めることをお勧めします。ただし、.woff形式のみです。これは、ほとんどすべての最新のブラウザーで使用されているため、ほとんどの訪問者にとって意味があります。他のすべてのユーザーの場合は、追加のリクエストに応じます。

ただし、Base64エンコーディングによって引き起こされる「オーバーヘッド」とフォントファイルのサイズ（.woff形式であっても）のため、この手法は、3つまたは4つ以下の異なるフォントしかない場合にのみ使用してください。また、サーバーがgzip圧縮された（CSS）ファイルを配信することを常に確認してください。

そうすることの大きな利点は、フォントファイルに対する追加の要求がないことです。また、最初のページが読み込まれた後（サイトのどのページでも）、CSSファイルがキャッシュされます。これは、HTML5アプリケーションキャッシュを使用する場合にも利点があります（実際に使用します）。

作者が自分のサイトで最大3つまたは4つの異なるフォントを使用するべきではないという事実に加えて、GoogleのCDNの使用方法を見てみましょう。

まず、次のように、必要なすべてのフォントを1つのシングル<link>に含めることができる（そして常にそうする必要がある）ことに注意してください。

<link href='http://fonts.googleapis.com/css?family=PT+Serif:400,700,400italic,700italic|PT+Sans:400,700,400italic,700italic|Montez' rel='stylesheet' type='text/css'>

これにより、次の応答が返されます。

@font-face {
  font-family: 'Montez';
  font-style: normal;
  font-weight: 400;
  src: local('Montez'), local('Montez-Regular'), url(http://themes.googleusercontent.com/static/fonts/montez/v4/Zfcl-OLECD6-4EcdWMp-Tw.woff) format('woff');
}
@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-weight: 400;
  src: local('PT Sans'), local('PTSans-Regular'), url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/LKf8nhXsWg5ybwEGXk8UBQ.woff) format('woff');
}
@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-weight: 700;
  src: local('PT Sans Bold'), local('PTSans-Bold'), url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/0XxGQsSc1g4rdRdjJKZrNBsxEYwM7FgeyaSgU71cLG0.woff) format('woff');
}
@font-face {
  font-family: 'PT Sans';
  font-style: italic;
  font-weight: 400;
  src: local('PT Sans Italic'), local('PTSans-Italic'), url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/PIPMHY90P7jtyjpXuZ2cLD8E0i7KZn-EPnyo3HZu7kw.woff) format('woff');
}
@font-face {
  font-family: 'PT Sans';
  font-style: italic;
  font-weight: 700;
  src: local('PT Sans Bold Italic'), local('PTSans-BoldItalic'), url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/lILlYDvubYemzYzN7GbLkHhCUOGz7vYGh680lGh-uXM.woff) format('woff');
}
@font-face {
  font-family: 'PT Serif';
  font-style: normal;
  font-weight: 400;
  src: local('PT Serif'), local('PTSerif-Regular'), url(http://themes.googleusercontent.com/static/fonts/ptserif/v6/sDRi4fY9bOiJUbgq53yZCfesZW2xOQ-xsNqO47m55DA.woff) format('woff');
}
@font-face {
  font-family: 'PT Serif';
  font-style: normal;
  font-weight: 700;
  src: local('PT Serif Bold'), local('PTSerif-Bold'), url(http://themes.googleusercontent.com/static/fonts/ptserif/v6/QABk9IxT-LFTJ_dQzv7xpIbN6UDyHWBl620a-IRfuBk.woff) format('woff');
}
@font-face {
  font-family: 'PT Serif';
  font-style: italic;
  font-weight: 400;
  src: local('PT Serif Italic'), local('PTSerif-Italic'), url(http://themes.googleusercontent.com/static/fonts/ptserif/v6/03aPdn7fFF3H6ngCgAlQzBsxEYwM7FgeyaSgU71cLG0.woff) format('woff');
}
@font-face {
  font-family: 'PT Serif';
  font-style: italic;
  font-weight: 700;
  src: local('PT Serif Bold Italic'), local('PTSerif-BoldItalic'), url(http://themes.googleusercontent.com/static/fonts/ptserif/v6/Foydq9xJp--nfYIx2TBz9QFhaRv2pGgT5Kf0An0s4MM.woff) format('woff');
}

ご覧のように、ユーザーが1つ以上の要求されたフォントをローカルにインストールしていない場合、9つの異なるフォントファイルがあります。つまり、リンク要素の1つを含む合計10の要求です。そして、これらのリクエストは、サイトへの新しいページリクエストごとに繰り返されます（データは転送されません）。また、の要求に対する応答<link>はキャッシュされません。

推奨事項：
結局のところ、スタイルシートにエンコードされたBase64の.woff形式でフォントファイルを含めることをお勧めします。

例とその方法の説明については、この素晴らしい記事を参照してください！

— ネットサーファー
ソース

おかげで、この解決策を探していました！

— 2014

3

インラインcssメソッドを使用しているのは、追加のリクエストのオーバーヘッドがbease64エンコード時のサイズの増加よりも大きいためです。これは、cssファイルのサーバーによるgizip圧縮によってさらに相殺されます。

その他のオプションは、フォントの非同期読み込みを使用することですが、ほとんどの場合、ユーザーは読み込み後にフォントが飛び出すのを目にします。

方法に関係なく、使用する文字セットのみを含めることにより、フォントファイルのサイズを小さくすることができます。

— クリス・グナワルデナ
ソース

HTTP2を使用する場合、上記の追加のオーバーヘッドはありません。

— Chris Gunawardena

1

個人的には、Googleフォントを使用しています。選択肢は豊富で、最近ではZopfli圧縮に移行することで、フォントの圧縮も改善されています。グーグルはウェブをより速くするために努力しているので、私はその部分のより多くの最適化が彼らからも来ると思います。

アウトソーシングされたフォント配信として何を選択しても、フォントを取得するためのリクエストにより、常に速度が低下します。速度の観点から見た最良のことは、自分でフォントを提供することです。アウトソーシングされた配信からロードするためにかかる余分なミリ秒を気にしない場合、それらの使いやすさがミリ秒に見合うと考えるなら、それに合わせるべきです。

Typekitやその他については知りませんが、Google Fontsを使用すると、特定のサブセットと文字の範囲を提供することを選択して、配信をさらに高速化できます。

サブセットの選択：

<link href="http://fonts.googleapis.com/css?family=Open+Sans&subset=latin" rel="stylesheet">

文字の範囲を選択する：

<!-- Only serve H,W,e,l,o,r and d -->
<link href="http://fonts.googleapis.com/css?family=Open+Sans&text=HelloWorld" rel="stylesheet">

フォント配信により、dns-prefetchを使用して速度をさらに向上させることができます。

私は、Googleがフォント配信をできる限り高速化するためにできる限りのことをすることを願っています。それらをロードするのにかかるミリ秒は私のウェブサイトを傷つけないので、私はそれらを楽しく使っています。

短い話：

フォントの配信にかかるミリ秒がサイトに悪影響を及ぼしている場合（たとえば、推奨される1秒よりも多くロードするなど）、自分でホストする必要があると思います。

— ジェレミー・カールソン
ソース

1

上の良い点<link rel=dns-prefetch href='//fonts.googleapis.com'>、私はそれが外部webfontsのために実行するように登録していない何らかの理由で、分析、熱マッピング、およびサブドメインのためにそれを使用。読み込み時間はフォントごとに大きく異なります。かなり人気のあるフォント（キャッシュされる可能性があります）を使用している場合、または一部のフォントのみを選択している場合は、webfontsを使用するとかなり高速なフォントソースになります。私はすぐにテストをここに速度で投稿します。

— ダーチャー、2014年

1

最良のオプションは、次のようにajaxを使用してフォントをインポートすることです。

<script>
    (function() {
        var font = document.createElement('link'); 
        font.type = 'text/css'; 
        font.rel = 'stylesheet';
        font.href = '/url/to/font.css';
        var s = document.getElementsByTagName('link')[0]; 
        s.parentNode.insertBefore(font, s);
      })();
</script>

私は自分のウェブページでこれを行い、Google Insightsテストで9ポイントを増やします。

— Phok7
ソース

面白い。このメソッドでPageSpeedsを調べる必要があります。

— darcher

2

何についてのasync属性？同じことをします。

— Tymek

Webフォントまたはローカルに読み込まれたフォント？

Google CSS

Google JSメソッド

Typekitメソッド

…＆Font Squirrelメソッド

他の信頼できるフォントソース

cloud.typography

Fonts.com

FontSpring

拡張された仕様

フォントライブラリのサイズ

価格

フォント品質

フォント品質II：タイポグラフィ

ブラウザのサポート

パフォーマンスI：ダウンロード

パフォーマンスII：サブセット化

パフォーマンスIII：配信

言語サポート

テストと実装