Webサイトの制作をするときに必ず一度は話題にあがるのがフォントでしょう。フォントをどうするかはデザインと運用の両方に大きく影響するので避けて通れません。
この記事ではWeb制作とフォント、そしてWebフォントを使う上で考えることを解説します！
Web業界が抱えるフォントの苦しみ
まず、Web業界が抱えるフォントの苦しみを簡単にみていきましょう。
ユーザーのデバイスにフォントデータが必要
たとえば紙媒体のグラフィックデザインであれば、フォントデータはデザイナーや印刷用のコンピューターに入っていれば使用できます。
一方、Webではそうはいきません。なぜなら、フォントデータが閲覧するユーザーのデバイスに入っている必要があるからです。
しかし、ユーザーのデバイスに指定したフォントデータが入っていることは誰も保証してくれません。
画像ではなくテキストを使用する理由
テキストではなく画像にすればフォントデータが存在しない問題は回避できますが、それはユーザービリティや運用を考えたときに大きなデメリットがあります。
文字のコピーは出来なくなりますし、文言修正のコストはテキストを使用する場合と比較して数倍にはなるでしょう。
ですから、デザイン上のこだわりがなく、頻繁に変更されることが予想される箇所では画像ではなくテキストを打ち込むようにした方が賢明です。
Webフォントという救世主
そこで登場したのが2010年ごろから使われ始めたWebフォントという技術です。
Webフォントはオンデマンドにフォントデータをユーザーのデバイスに届ける仕組みです。
Webフォントの登場で苦しみから解放されたかと思いきや、今度は読み込み速度によるチラつきなどの問題が発生します。
なんでもWebフォントを使用すればよいというわけではなく、状況に応じて適切な方法をとることが重要です。
デバイス間の差は避けられない
ローカルフォントでもWebフォントでもデバイス間での表示の差は避けられません。できるだけ小さくすることはできますが、ユーザーが使っているデバイスが違うので、こればかりはどうしようもないですね。
ライセンスの問題は避けられない
これはグラフィックデザインでも同じですが、フォントにはライセンスがあります。商用フリーで使えるものばかりではありませんから、必ずライセンスは確認するようにしましょう。
ローカルフォントのメリットと問題
ここで言うローカルフォントとは、ユーザーのデバイスにもともとインストールされているフォントデータのことを指します。
代表的なデバイスにインストールされているフォントを知りたい場合はfont-familyメーカーが便利です。
通信が必要なく、すぐに表示される
ローカルフォントは、あらかじめインストールされているものを使用するので通信が必要なく、高速に表示できます。通信が必要ないので、オフライン環境でも動作してほしい場合にも適します。
使用できるフォントはデバイスによる
しかし、冒頭でも述べたように指定したフォントがインストールされている保証はありません。明朝体は特に注意が必要で、Androidデバイスには明朝体のローカルフォントがインストールされていないことが多いです。
実装方法
例えば游ゴシック体を使用したい場合は以下のように記述します。
.font-gothic {
font-family: YuGothic, 'Yu Gothic', sans-serif;
}最後の sans-serif はゴシック体のシステムデフォルトフォントを意味していて、游ゴシック体がなかった場合にシステムデフォルトフォントが使用されるようになります。特にローカルフォントを使用する場合は重要ですので、忘れないようにしましょう。
Webフォントのメリットとデメリット
ここで言うWebフォントとはサーバーにアップロードしたものや Google Fonts などのWebフォント提供サービスから配信されたフォントデータを指します。
Webフォントの形式にはいくつか種類がありますが、基本的にはwoffかwoff2を使用します。
デバイスを問わず同じフォントが使える
必要に応じてフォントデータをダウンロードして使用するので、デバイスを問わず同じフォントが使えるようになり、デザインの再現度があがります。ただし、デバイスごとにフォントの扱い方が異なるため行高などが違うことがあり、完全に同じにはならない場合があります。
表示に時間がかかることがある
欧文フォントであればさほど問題にならないのですが、日本語や中国語の場合は文字数の多さゆえにフォントデータの容量がとても大きくなります。
その結果、フォントデータをダウンロードすることに時間がかかってしまい、FOITやFOUTのような問題が発生したり、CLSなどコアウェブバイタルに影響したりすることも考えられます。
Webフォントが読み込まれるまでテキストが表示されない問題。
Webフォントが読み込まれるまで代替フォントが表示され、切り替わる時にチラつきが発生する問題。
リソースの表示などによってあとから生じる意図しない視覚的なズレの指標。LCP（Largest Contentful Paint）やINP（Interaction to Next Paint）と並ぶコアウェブバイタルの一つ。
実装方法
仮に FontName.woff というフォントを特定のWebサーバーから読み込む場合は以下のように記述します。Google Fonts などを使用する場合は書き方が違いますが、実はこの辺りを埋め込みコードがやってくれています。
@font-face {
font-family: 'Font Name';
font-style: normal;
font-weight: 400;
src: url(https://example.com/FontName.woff) format('woff');
font-display: swap; /* これについては後述 */
}
.font-fontName {
font-family:'Font Name';
}テキストではなく画像を使うメリットとデメリット
ローカルフォントもWebフォントもそれぞれ問題を抱えているので、ときには上手に画像を使うことも考えてみましょう。
テキストより画像の方が適している場合も多い
文字組みされているなど、極めてデザイン性が高い場合はテキストとCSSで頑張るよりも画像にしてしまう方が良いでしょう。デザインの再現度も上がりますし、複雑なコードの代わりにデザインツールを使用したほうが簡単なので、変更時の負担は画像の方が減ることもあります。SVG画像を使用すればデータ容量は小さいですし、キーワード対策が気になる場合は適切にalt属性を設定すれば問題ありません。
画像の場合、デバイス間の見た目の差はほとんどない
画像を使用しているので、正しく実装できていればデバイス間での見た目の差はほとんどありません。ただし、それでもブラウザによって画像の取り扱いが異なることがありますし、実は正しく実装するのは簡単ではありません。
画像は、きちんと理解して使わないと逆効果になる
画像の取り扱いには細心の注意が必要です。デザイン性の高い見出しなどをSVG画像で実装することは多いと思いますが、テキストデータのまま書き出してしまっては意味がないのでパス化（アウトライン化）を忘れてはいけません。
また、ベクター画像が得意なSVG形式の中にラスター画像を含めて書き出そうとするとラスター画像がBase64変換されてデータ容量が爆発的に増加することがあり、注意が必要です。
他にも、ブラウザごとに対応する形式やSVGの解釈の仕方が異なるのでクロスブラウザチェックは重要です。また、<picture>タグでアートディレクションを行う場合はレスポンシブのチェックも忘れずに実施しましょう。
Webフォントの読み込みを高速化する方法
ここまではフォントを表示するために、ローカルフォント・Webフォント・画像が使えることを見てきました。どの方法も一長一短ですが、昨今のWeb制作ではほとんどのケースで多かれ少なかれWebフォントが採用されています。
最後に、Webフォントの読み込みを高速化するテクニックについて見ていきましょう。
使用するWebフォントの数を減らす
まずは、デザインする段階から使用するフォントの数を減らしましょう。特に日本語フォントは容量が大きいですから、ユーザビリティを考慮するならできるだけ少ないWebフォントを使用する方が良いです。
太さや斜体の違いも１フォントデータですので注意しましょう。
フォントの再現にこだらないのであれば、ローカルフォントを使用することで高速化できますし、見出しなどポイント使いであればわざわざWebフォントを読み込まずにSVG画像として実装してしまった方が容量の面でも運用の面でもメリットがあります。
font-displayを指定する
CSSには @font-face 内で使える font-display というプロパティが存在していて、Webフォントの読み込みに関する挙動を指定できます。
レンダリングブロックしてでも狙ったフォントで表示させたいケースと、狙ったフォントでなくてもいいからとにかく早く表示させたいケース、そしてその間とさまざまなケースに対応できます。
| 値 | 説明 |
| auto | ブラウザのデフォルトです |
| block | 少しの間レンダリングブロックし、Webフォントが読み込まれたら代替フォントと入れ替えます |
| swap | 一瞬だけレンダリングブロックし、Webフォントが読み込まれたら代替フォントと入れ替えます |
| fallback | 一瞬だけレンダリングブロックし、その後は少しだけWebフォントの読み込みを受け付けます |
| optical | 一瞬だけレンダリングブロックし、その後はWebフォントの読み込みを受け付けません |
※ブラウザによって挙動が異なるためあくまでも目安です。
プリコネクトする
フォントファイルが外部にある場合は、プリコネクトをheadに記述し、外部サーバーとの接続確立を高速化します。
<link rel="preconnect" href="https://example.com">プリロードする
プリロードをheadに記述し、フォントファイル読み取りの優先順位を上げます。
<link rel="preload" as="font" href="/path/to/font.woff">静的サブセット化する
日本語フォントは文字数が多いので、使用しそうな文字だけに限定することでフォントの容量を小さくすることができます。これを事前に行なっておくのが静的サブセット化です。
方法はいくつかあり、自分でサブセット化するなら Font Forge が有名です。
Google Fonts を使用している場合は subsetパラメータやtextパラメータを付与することでサブセット化できます。
動的サブセット化を利用する（ダイナミックサブセッティング）
静的サブセット化の欠点として、後からコンテンツが変更された場合に対応できない可能性があげられます。そこで、実際のWebページを解析してオンデマンドにサブセット化を行うことを動的サブセット化（ダイナミックサブセッティング）といいます。
有料のWebフォントサービスであれば、動的サブセット化をサポートしていることが多いので、ぜひ利用してみましょう。
まとめ
この記事では、Web業界が抱えるフォントの悩みと使い分け、そしてWebフォントの高速化について見てきました。
ローカルフォントは高速表示やオフライン環境に強く、Webフォントはデバイスを問わず同じフォントが使えて、画像は極めてデザイン性が高い場合にも対応できます。
それぞれ得意なことと不得意なことがあり、適切なものを使用することが重要ですね。
また、Webフォントの容量が大きすぎるという欠点をカバーする高速化テクニックも紹介しました。
まずは使用するWebフォントを減らすこと、そしてプリロードやサブセット化を駆使して上手に付き合っていきましょう！
