Cufonを使用してトラブルが発生して以来、外部フォントリソースを使用することは避けましたが、最近では、代替の読み込み方法を探していましたより良い方法があるかどうかを確認するフォント。より良いメソッドには、ただ青く表示される方法があります。
そこには多くの新しいメソッドがあり、各メソッドにはバリエーションがあるようです。 typekitを使用する必要がありますか?またはgoogle webfonts(jsまたはcssを使用)?ローカルでロードするフォント(fontsquirrel.com生成メソッドなど)を引き続き使用する必要がありますか?
以下にいくつかのテストを行って、最も好評を博していると思われるメソッドをリストしますが、ウェブフォントに移行する価値は本当にありますか?リソース負荷(http要求)が高く、ファイル形式の種類が少ない(互換性が低い)などのように見えますが、ほとんどの場合、ファイルは非同期で効率的に読み込まれているように見えます。
ここではベストプラクティスを本当に探しています。パフォーマンスは重要ですが、スケーラビリティと使いやすさも重要です。言うまでもなく、ルックアンドフィール。
@import
または<link>
を使用するか、スタイルシート(@font-face
)の内容を取得して、独自のスタイルシートに直接配置できます。テスト結果
78ms load of html 36ms load of css
webfont.js
を使用してstyleshetをロードします:root
要素を追加しますテスト結果
171ms load of html 176ms load of js 32ms load of css
:root
要素を追加します。*.js
スニペットまたは外部ロードファイル*.js
ファイルを使用できますdata:font/opentype
を使用します。外部スタイルシートをheadに追加します
typekit.comからフォントとターゲットセレクタを簡単に追加/削除/調整できます
テスト結果
169ms load of html 213ms load of js 31ms load of css 3ms load of data:font/
@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;
}
まず、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
スタイルシートを使用してスタイル設定を続けるためですが、それは私だけかもしれません。スクリプト( http://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js )によって読み込まれたJSファイルは、@font-face
宣言、およびlooksは、より多くの作業のように見えます。そして、実際のフォント自体(WOFFまたはTTF)の読み込みがブロックしているとは思わないので、物事をそれほど遅らせるべきではありません。私は個人的にはCDNの大ファンではありませんが、実際には本当に速いのです。 Googleのサーバーは、ほとんどの共有ホスティングプランを地滑りで打ち負かします。また、そのフォントは非常に人気があるため、人々は既にそれらをキャッシュしているかもしれません。
そして、それは私が持っているすべてです。
Typekitの経験がないので、理論から除外しました。引数のためにブラウザ間の一般化をカウントせずに不正確な点がある場合は、それらを指摘してください。
あなたはあなたの質問でロード時間を非常によく扱っていると思います。私の観点からは、リストに追加する必要のあるいくつかの情報源と、オプションの完全なビューを取得するために調べる必要がある他のいくつかの考慮事項があります。
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)
私はこのサービスを使用していませんが、彼らは非常に確立されたフォントベンダーであり、彼らのサイトにリストした情報は非常に印象的です。正確なメソッドの仕様はありませんが、以下のとおりです。
FontSquirrelと提携しています。フォントはここで固定価格で購入できます。 FontSquirrelと同様に、CSSに付随するフォントファイルが配信され、独自のサーバーに展開されます。
各フォントサービスの全体的な長所と短所について、いくつかの比較を示します。
Webフォントの品質はかなり異なる場合があります。これには、レターフォーム自体、または文字セットの間隔やサイズなどが含まれます。これらはすべて、フォントが与える品質の全体的な印象を決定します。無料のオプションにはいくつかの優れたオプションがありますが、高品質ではないフォントもあるため、これらのソースから慎重に選択する必要があります。
デスクトップフォントには、Webフォントで取得するのが非常に困難だった多くの改良点があります。これらのサービスのいくつかは、それらを提供する方法を提供します。
これは主に、各サービスでサポートされているフォント形式に帰着します。主なものは次のとおりです。
詳細は @ 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 */
}
私が理解している限り、上記の構文を使用すると、ブラウザはそれらに機能する特定の形式を取得できるため、機能しないフォント形式での無駄なダウンロードはありません。
Fonts.com、Typekit、Typography.comなどの有料サービスは、メソッドを使用して正しい形式を検出し、thenが正しいフォント形式を、多くの場合、CSSファイルのbase64データとして配信します。
私が見ることができることから、上記の方法の違いは、高速インターネットユーザーにとってはごくわずかです(差は<200msのようです)が、低速ネットワーク上のデバイス、特にキャッシュされていないページヒットについては考慮する価値があります。
使用したい特定の文字のみが存在することがわかっている場合は、文字のサブセットを使用してフォントを作成し、ダウンロードのサイズを小さくすることができます。
さて、あなたがそうであるように
...ここでベストプラクティスを探して、パフォーマンスは重要ですが、スケーラビリティと使いやすさも重要です。言うまでもなく、ルックアンドフィール。
答えは(Webデザインでいつもそうであるように):それは依存します!
確かなことの1つは、JSアプローチ(2番目の例に示す)の使用はお勧めしません。
個人的には、大部分のユーザーがJavascriptを有効にしている場合でも、Javascriptに基づいてプレゼンテーションやCSSスタイルを作成することは嫌いです。物事を混同しないことの問題です。
そして、あなたの与えられた例で見ることができるように、フォントが利用可能になる前にページがブラウザによって既にレンダリングされているので、ある種のFOUC(スタイルのないコンテンツのflas)があります。すぐに、ページが再描画されます。そして、サイトが大きいほど、(パフォーマンス)インパクトが大きくなります!
だから、フォントの埋め込みにJSソリューションを使用することはありません。
ここで、純粋なCSSメソッドを見てみましょう。
かなり前から、「vs. @import」についての議論があります。個人的には、@ importの使用を避け、常に<link>
のみを使用することを好みます。しかし、これは主に個人的な好みの問題です。絶対にすべきでないことの1つは、両方を混ぜることです!
ローカルと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つの異なるフォントファイルがあり、合計10(リンク要素の1つを含む)の要求を意味します。そして、これらのリクエストは、サイトへの新しいページリクエストごとに繰り返されます(ただし、データは転送されません)。また、<link>
のリクエストに対する応答はキャッシュされません。
推奨:
結局のところ、スタイルシートにエンコードされた.woff形式のBase64でフォントファイルを含めることを本当にお勧めします。
ニースの記事を参照してください 例とその方法の説明については!
追加のリクエストのオーバーヘッドは、bease64エンコード時のサイズ増加よりも大きいため、インラインcssメソッドを使用します。これは、cssファイルのサーバーによるgizip圧縮によってさらに相殺されます。
他のオプションは、フォントの非同期読み込みを使用することですが、ほとんどの場合、ユーザーは読み込み後にフォントが表示されます。
方法に関係なく、使用する文字セットのみを含めることにより、フォントファイルのサイズを小さくできます。
最適なオプションは、次のように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>
これをWebページで行い、Google Insightsテストで9ポイントを増やします。
個人的には、Googleフォントを使用しています。さまざまな選択肢があり、最近 Zopfli圧縮に移行することでフォントの圧縮が改善されました もあります。 GoogleはWebの高速化に努めているため、その部分の最適化もWebから得られると思います。
外注フォント配信として選択するものは何でも、フォントを取得するためのリクエストによって速度が常に低下します。速度の観点から見た最高のものは、自分でフォントを提供することです。アウトソースされた配信からロードするのにかかる余分なミリ秒を気にしない場合、使いやすさがミリ秒の価値があると思うなら、それを使うべきです。
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秒を超えてロードすることにより、フォントの配信にかかるミリ秒がサイトを傷つけている場合、自分でホストする必要があると思います。