WEBフォントを使うときの正解を探る
WEBサイトの表示でフォントを指定するときにはWEBフォントを使います。
WEBフォントとは、使いたいフォントをサーバーにUPし、それをユーザーにダウンロード(自動でダウンロードされる)させて表示させる方法です。
英語だったら文字数が少ないので、そこまで問題はないのですが、日本語の場合、ひらがな、カタカナ、漢字とあり、フォントファイルが重くなり、表示速度に影響がでます。
表示速度を優先するのであれば、使わない方がいい、と言われるほどです。
だけどさ、使いたいわけですよ。WEBフォントを。
デフォルトのフォントじゃなくて、ちょっとこだわってます感をだしたいんですよ。
(端末に依存しないで同じフォントを表示できるというメリットがあります。)
というわけで、WEBフォントを使用する際のベストプラクティスを探りたいと思います。
あらかじめ断わっておくと、これは私の主観で正しいかどうかはわかりません。
また、時がたてばここで紹介している内容と違うことをやるかもしれません。
WEBフォントの簡単な使い方
WEBフォントの利用方法として、一番簡単なのはGoogleのCDNからWEBフォントを読み込む。
これが手軽で簡単です。
CDNから読み込む手順は、いろんなサイトで紹介されているので省きます。
参考サイトは以下。
CDNではなく自サーバーに設置するならサブセット化が必須
CDNではなく、自分のサーバーにWEBフォントを用意するのであれば、サブセット化という軽量化が必須です。
日本語の漢字は数が多いので、常用漢字(厳密には違うけど)以外は用意しないで、ファイルを軽量化するのがサブセット化です。
これもいろんなサイトで手順が紹介されているので省きます。
参考サイトは以下。
サブセット化した.otfファイルをwoffとwoff2で変換することで、
NotoSansJP-Regular.otf(4,442KB)が、
NotoSansJP-Regular.woff(404KB)、
NotoSansJP-Regular.woff2(359KB)
まで減量できます。
表示速度を考慮してベストな読み込みを考える
まず、最初の選択としてCDNを使うか、自分のサーバーに設置するかの二択があります。
私は自分のサーバーにサブセット化したWEBフォントを設置しました。
自サーバーにフォントを設置するメリット
一番の理由は、フォントの表示方法を色々と設定できるようにするためです。
あとで紹介しますが、WEBフォントの呼び出し方法は色々あります。
次に、第三者サーバーから読み込むと、「今は無料だけどやっぱり有料にするわ」と言われたときにめんどくさいから。
CDNを利用すると、同じところから呼び出してるので、他のサイトで読み込んだ時にキャッシュされる、とかだったら利用価値が高いんですが、第三者サイトのWEBフォントはキャッシュされない(正確にはそのキャッシュを利用できない)ので、あまり意味がないようです。
フォントファイルのフォーマットはwoff2 & woff
WEBフォントのフォーマットは複数存在します。
ブラウザ間で使える使えないがあるためです。
最近ようやくIEが引退されたので、woff2だけで良いという情報をみたんですが、な~んかよくわからんのですが、私の環境だとwoff2だけにするとフォントが置き換わるという事象があります。
原因をずーっと調査しても全然わからないので、woff2とwoffの両方を使っています。
ちなみに環境はchorome 102.0.5005.115(Official Build(64 ビット)
なんでなんだろう。
WEBフォントをHTMLに読み込む最適解をさぐる
ようやく本題にたどり着きます。
WEBフォントを使う上で考慮すべき点は2つ。
読み込みの遅さと、フォントの置き換わりによるCLSの軽減です。
WEBフォントの読み込みを少しでも早くする
WEBフォントの読み込みを可能な限り早くするために、まずプリロードで読み込みます。
<link rel="preload" as="font" href="/font/NotoSansJP-Regular.woff2" crossorigin> <link rel="preload" as="font" href="/font/NotoSansJP-Bold.woff2" crossorigin>
preloadしたフォントファイルをCSSよりも先に読み込ませます。
次にfont-faceでフォントの読み込み指定を書きます。
@font-face { font-family: "NotoSansCJKjp"; font-weight: normal; font-display: block; src: local("Noto Sans CJK JP Regular"), url(/font/NotoSansJP-Regular.woff2) format("woff2"), url(/font/NotoSansJP-Regular.woff) format("woff"); } @font-face { font-family: "NotoSansCJKjp"; font-weight: bold; font-display: block; src: local("Noto Sans CJK JP Bold"), url(/font/NotoSansJP-Bold.woff2) format("woff2"), url(/font/NotoSansJP-Bold.woff) format("woff"); }
私のサイトでは、ウェイト違いを2つ読み込んでいます。
両方ともサブセット化してwoff2に変換してあります。
font-displayはblock、optional、swapのどれが正解か
このfont-displayの指定が悩ましい。
どれが正解とは言いずらいので、お好みになります。
font-display:swap の特徴
私は最初、「swap」を指定していました。
swapの場合、代替フォントが先に表示され、その後指定したフォントを読み込む、という挙動になります。
最終的に指定フォントになるのですが、読み込まれるまで秒数にして1秒にも満たない時間ですが、目視でフォントの置き換わりが確認できます。
それが気になって、swapをやめました。
CLSも発生していたのでそれの対策も含め。
font-display:optional の特徴
swapの次に採用したのが「optional」でした。
optionalの場合、フォントの読み込みが早ければ(おおよそ100ms以下)指定フォントに置き換え、それ以上時間がかかる場合はフォントの置き換えをしません。
これでCLSはほぼ起きないようになるのですが、フォントが変わってしまうことで、line-hightの扱い方が変わってしまいました。
指定フォントとデフォルトフォントで期待する行間に差異があるようで、簡単に言うと文字が読みづらくなってしまうというデメリットが発生。
フォントがキャッシュされる2ページ目以降では特に問題ないわけですが、多くのユーザーは1ページ目で離脱することを考えると、あんまりよろしくないなぁと。
文章が読みづらいってことが、離脱の原因にもなりうるので。
font-display:block の特徴
最終的にたどり着いたのが、「block」です。
blockの場合、フォントのダウンロードができれば、必ず指定フォントで表示します。
サブセット化されたフォントは400KB位なので、そんなに時間かからないし、CLSも発生しないのでこれでいいかなと。
font-displayはシーンによって使い分けるのがいい
CLSをどこまで気にするかと、WEBフォントの使用範囲がどこまでなのかによって使い分けるのが良いのではないかと思います。
私は全ての文字をWEBフォントで指定してるので、blockにしました。
WEBフォント使わないのが一番だという意見も大いに賛成できます。
ただ、「使わない」のと、「使ったことがない」では自分の経験値が変わってくるので、私はこの自分のサイトで色々実験をしています。
結局WEBフォントってどうなの?
個人的には使わなくていいなら使わないのが一番です。
サブセット作るの面倒だし、文字のちらつきが起きたり、CLSが起きたり、そこまで大きなメリットはないですし。
ただ、自分の使いたいフォントで表示させることができるので、そこは個人的に満足してます。
スマホでもPCでもマックでもウィンドウズでも同じフォントで表示されるのがいいかなと。
昔に比べると、だいぶ環境が整ってきたと思うので、今後WEBフォントが使われるシーンが増えていくのではないかと予想されます。(Good Bye IE!)
そんな時に、何を考えてどうやって使うのかの最適解、または、なぜこの方法なのか、についての指針が得られたというのが、私の感想です。