Google Fontsの表示速度改善｜読み込み・文字のずれ・日本語フォントの確認手順

Google Fontsを使うと、閲覧する端末に同じ書体が入っていなくても、ブランドに合った文字を表示できます。一方、文字がなかなか見えない、読み始めた後で文章が動く、スマホだけ見出しが大きく折り返す、といった問題が起きることがあります。対策の出発点は、フォントを全部外すことでも、読み込み用のコードを一律に追加することでもありません。どの文字を、いつ、どれだけの通信で表示しているかを確認することです。

この記事は、企業のWeb担当者と実装担当者が同じ確認表で話せるよう、測定、設定、表示確認、更新後の管理までを整理したガイドです。Google Fonts、Chrome、W3Cの一次資料と、The Economic Timesの公開改善事例を参照します。本文中の店舗名・数値・作業場面を使う記入例は説明用の架空例であり、Acquaの顧客実績ではありません。

1. Webフォントの問題を、表示・ずれ・通信量に分ける

文字が見えるまでの待ち時間を確認する

Webフォントは、ページのHTMLに文字の形そのものが埋め込まれる仕組みではありません。ブラウザーがCSSで書体の指定を確認し、必要なフォントファイルを取得して文字を描きます。Google Fontsを外部配信で使う場合には、書体を定義するCSSと、文字の形を収めたファイルを区別して考えます。CSSの取得が終わっただけで、すべての文字が目的の書体で表示できるとは限りません。

最初に見るべきものは、ページを開いてから説明文やボタン名を読めるまでの様子です。見出しが空白なのか、別の書体で先に表示されるのか、背景や写真だけが先に出るのかを記録します。スクリーンショット一枚では途中経過が分からないため、画面録画やブラウザーの読み込み記録を使うと、制作担当者に状況を伝えやすくなります。

文字が動く問題と、遅い問題は同時に見る

代わりの書体を先に表示し、後からWebフォントへ切り替えると、文字幅や高さの違いで改行位置が変わる場合があります。たとえば見出しが二行から三行になると、その下の価格や相談ボタンまで押し下げられます。文字が早く読めても、押そうとしているボタンの位置が動けば、操作上の問題は残ります。

GoogleのWebフォントの実装ガイドも、文字の表示遅延とレイアウトのずれを別の影響として説明しています。そこで改善の記録には「文字が読めた時点」と「切り替えによる動き」の両方を残します。表示完了後の書体だけで合否を決めず、最初に訪れた人が目にする途中の状態もデザインの確認対象にします。

容量は書体名から決めつけず、実際の取得量を調べる

「日本語フォント一つは必ず何MB」と固定して見積もると、実態を取り違えることがあります。配信形式、文字の分割、指定する太さ、ブラウザー、ページ内の文字、キャッシュの状態によって取得する内容は変わります。ダウンロードしたフォント一式の容量と、一回のページ表示で転送された容量も同じではありません。

たとえば架空の測定で、初回にフォントを240KB取得し、再訪では保存済みのファイルを使ったとします。再訪だけを見て「通信量はゼロだから問題ない」と判断すると、初めて広告や検索から来る人の状態を見落とします。反対に、使っていない書体を含む配布パッケージ全体の容量を、毎回の通信量として説明するのも不適切です。対象ページと条件を添えて測ります。

2. 変更前の状態を、再現できる形で記録する

トップだけでなく、文字の役割が異なるページを選ぶ

確認ページは、トップ、サービス詳細、長い記事、問い合わせフォームなど、文字の使われ方が異なるものから選びます。同じサイトでも、トップだけ別の見出し書体を使い、フォームではプラグインが別のCSSを読み込んでいる可能性があります。全ページに共通する設定なのか、特定のテンプレートだけの問題なのかを先に分けます。

さらに、英数字が多い料金表、長い商品名、人名や地名を含む文章も用意します。短い仮原稿では問題がなくても、本番の見出しで改行が増えることがあります。確認表にはURL、ページの役割、主要な書体、使う太さ、症状が出る端末を並べます。デザイン上の指定と実際の表示が一致しているかも、この段階で照合します。

Networkで取得元・容量・開始時刻を確認する

Chromeの開発者ツールでは、Networkパネルで通信を記録できます。対象ページを開いた後でパネルを出すだけでは最初の通信を取り逃がすため、記録できる状態で再読み込みします。Fontの種類で絞り、ファイル名、取得元、転送サイズ、所要時間を確認し、必要に応じてCSSのリクエストも調べます。読み込みを開始したきっかけはInitiator、時間の内訳はTimingで確認できます。

Chrome DevToolsのNetwork公式資料には、通信の絞り込み、キャッシュ無効化、速度制限などの操作が載っています。初回相当の測定ではキャッシュを無効にした条件を記録し、通常の再訪条件も別に試します。速度制限は利用者の回線そのものを完全再現するものではありませんが、同じ条件で変更前後を比較する材料になります。

PageSpeed Insightsの実測と診断を混同しない

PageSpeed Insightsには、実際の利用者に基づくデータと、Lighthouseによる診断があります。GoogleのPageSpeed Insightsの説明によると、実利用データは過去28日間を対象とし、ページのデータが足りない場合にはサイト全体の単位が使われたり、データ自体が表示されなかったりします。公開直後の修正が、その欄へすぐ全面的に反映されるわけではありません。

記録には測定日時、モバイルかPCか、ページ単位かサイト全体か、診断条件を添えます。LCPは主要な内容の表示、CLSは予期しないレイアウトのずれを調べる手掛かりになります。ただし、主要要素が写真なら画像やサーバーの影響も確認が必要です。総合スコアの上下だけでフォントが原因と判断せず、該当要素と読み込み記録を結び付けます。

3. 書体・太さ・文字の範囲を必要な量へ整理する

実際に使う太さと、読み込み指定を揃える

まず本文、見出し、ボタン、注釈ごとに使う太さを整理します。デザインでは通常と太字の二種類しか使わないのに、過去の試作で指定した複数の書体が残っていれば、整理の候補です。一方、細い文字や中間の太さをブランド表現に使っている場合、その役割を確認せず削ると見た目が変わります。削除する対象は、使っていないことと影響範囲を確認して決めます。

Google FontsのCSS APIの公式資料では、使うスタイルを具体的に指定し、連続した太さが必要なら範囲を指定する方法が説明されています。可変フォントは一つのファイルで複数の太さを扱えるため、「太さの数だけ同じ大きさのファイルが増える」とは限りません。二種類の固定指定と可変範囲のどちらが適するかは、デザイン上の必要性と実際の配信内容を見て判断します。

日本語の分割配信と、固定文字への絞り込みを区別する

フォントを文字の範囲ごとに分け、CSSのunicode-rangeで使用範囲を指定すると、ブラウザーはページで必要となる範囲に応じてファイルを取得できます。これは、文字の範囲をCSSに書くだけで元ファイルが小さくなるという意味ではありません。自分で配信する場合には、分割した実ファイルとCSSの対応まで管理します。

Google Fonts APIのtextパラメーターは、使用文字が決まっている場合に、その文字へ絞ったフォントを要求する別の方法です。固定の短い見出しには検討できますが、日々投稿する記事本文へ今日の文字だけを指定すると、明日追加する文字が対象外になります。「現在の文章が表示できた」だけでは運用できる設計か判断できません。更新する人と、対象文字の変更方法まで決めます。

書体を使い分ける範囲を、読者の体験から決める

見出しにブランドの書体、長文の本文に端末の標準書体を使う構成も選べます。全ページのすべての文字へ同じWebフォントを当てる以外にも、必要な箇所へ限定する方法があるということです。ただし標準書体はOSごとに見た目が変わるため、Windows、macOS、iPhone、Androidでの確認を省略できるわけではありません。

説明用の架空例として、地域の工務店が見出しだけ明朝体にし、施工説明と問い合わせ欄は読みやすいゴシック体にしたい場合を考えます。優先するのは会社の雰囲気を表す見出しと、長い説明や入力項目を読めることです。担当者には「軽くしてほしい」だけでなく、残したい書体と変更できる範囲を伝えます。書体数を減らすこと自体を最終目的にしません。

4. font-displayと代替書体で、読み始められる状態を作る

swap・fallback・optionalを用途に合わせて選ぶ

font-displayは、フォントの読み込み中や取得できないときの表示方法を制御します。swapは短い非表示期間の後に代替書体を表示し、Webフォントが届けば切り替えます。fallbackは待機と切り替えの期間を限定します。optionalは、間に合わない場合にその表示ではWebフォントへ切り替えない動作を選べます。厳密な時間や判断はブラウザーの実装にも関係します。

W3CのCSS Fonts仕様を踏まえると、swapをすべての場所へ入れることが唯一の正解ではありません。本文を早く読めることを重視するのか、ブランド書体への切り替えを許容するのかを決めます。optionalを試す場合は、初回に標準書体のまま表示されても内容とデザインが成立することを確認してください。

代替書体の行数とボタン幅を見比べる

font-familyには、Webフォントが使えない場合の候補と、sans-serifなどの総称ファミリーを指定します。候補を列挙しただけで、意図した書体がすべての端末に存在するわけではありません。実際の端末で、見出しの行数、本文の密度、数字の区切り、ボタン内の文字がどう見えるかを確認します。特に「無料相談を予約する」のような長いラベルは、小さい画面で差が表れます。

GoogleのCLS改善ガイドは、代替書体との大きさの差を調整するsize-adjustなどを紹介しています。ascent-overrideやdescent-overrideを含め、他サイトの数値をそのまま使うのではなく、対象書体の組み合わせに合わせて調整します。行の高さだけが揃っても文字幅の差による折り返しは残るため、長文と短いUIの両方で見ます。

フォントが届かない場合にも操作できるか試す

通常回線で表示できた後は、検証環境でフォント配信元への通信を止めた状態も確認します。本文が読めるか、メニュー名が見えるか、送信ボタンが押せるかを見ます。アイコンフォントを使っている場合には、文字用フォントと同じ扱いで一括変更すると、メニューや矢印の意味が失われることがあるため別に確認します。

この点検は、画像で文字を置き換える理由にはなりません。会社名や料金、サービス説明は、文字として読める状態を保つことが大切です。必要に応じて文字拡大やキーボード操作まで確かめます。読みにくさの見直しを広げる場合は、企業サイトのアクセシビリティ改善ガイドも確認すると、フォント以外の問題を一緒に整理できます。

5. 読み込みを早める施策は、役割を理解して使う

preconnectは接続準備、preloadは特定ファイルの先読み

preconnectは、配信元との接続を事前に準備するためのヒントです。フォント本体を先にダウンロードする指定ではありません。preloadは、対象ファイルを早期に取得するためのヒントです。同じ「先に準備する」施策でも働きが異なるため、設定が入っているかだけでなく、どの待ち時間を短くする狙いなのかを説明できる状態にします。

Googleのフォント読み込み解説では、必要なフォントを発見する時点と取得・表示の関係を整理しています。最初の画面に使わない書体まで先読みすると、重要な画像などと通信資源を取り合う可能性があります。分割された日本語フォントをすべてpreloadする方法も避け、実際に必要なファイルを特定できるか、先読み後に他の表示が遅くならないかを検証します。

Google Fontsの外部配信と自社配信を同条件で比較する

外部配信はフォントの配信管理を任せやすい一方、自社配信では第三者への接続を減らせます。ただし自社のサーバーが遅い、圧縮やキャッシュが整っていない、大きな日本語ファイルをそのまま置く、といった状態では、自社配信の方が速いとは限りません。「月間何PV以上なら自社配信」と一律に区切るより、実際の配信時間と維持管理の負担で比較します。

Google Fontsの技術上の考慮事項では、ブラウザーに応じたCSSなど、配信サービス側の処理が説明されています。外部のCSSを一度保存して自社に置く場合、その時点の内容を自分で管理することになります。書体を更新する人、配信元の変更、文字の不足を見つけたときの対応を決め、利用するフォントの配布条件も確認します。

テーマやプラグインからの二重指定を整理する

WordPressでは、テーマ、ページビルダー、追加CSS、最適化プラグインなど、複数の場所がフォントを指定することがあります。HTMLへ新しい読み込みコードを足しても、古い指定が残っていれば整理になりません。外観上は一つの書体でも、別のCSSから同じ配信元へ要求している可能性があるため、Networkと設定箇所を照合します。

変更は検証環境で対象を絞り、元の設定とファイルを残して進めます。たとえばテーマの設定を直した直後に複数の最適化機能も有効にすると、どの変更で崩れたか切り分けにくくなります。一つの仮説を検証し、通常ページだけでなくメニュー、フォーム、編集で追加したページも確認します。依頼時の記録は、ホームページの修正依頼の伝え方に沿ってまとめられます。

6. 公開事例から、自社で試す条件を読み取る

The Economic Timesはフォント以外も同時に改善した

Googleのweb.devに掲載されたThe Economic Timesの公開事例では、font-displayをautoからswapへ変更して文字の表示を早めたことが説明されています。同時に、重要な通信の優先、圧縮、キャッシュ、画像や広告枠の寸法確保などにも取り組んでいます。これはAcquaの制作事例ではなく、同サイトの担当者による外部の実践報告です。

同報告にはサイト全体の成果もありますが、その結果を「swap一つの効果」として紹介すると因果関係を誤って伝えます。この記事で参考にするのは、読む人の体験に関係する指標を選び、複数の原因を調べ、修正を検証した進め方です。大規模なニュースサイトと地域企業の案内サイトでは、広告、記事量、訪問頻度が異なるため、同じ設定で同じ結果を期待しません。

架空例：文字の表示は早まったが、ボタンが動いた

ここからは説明用の架空例です。ある企業の採用ページで、見出しが表示されるまで空白になる問題に対してswapを試したとします。代替書体で文字は読めるようになりましたが、Webフォントへ切り替わると見出しが二行から三行になり、応募ボタンが下へ移動しました。この場合、表示待ちの問題は改善しても、操作位置が動く問題は残っています。

次の検証では、代替書体、見出しの幅、余白、文字サイズを順に確認します。文章を短くするなら、単に行数を揃えるために募集条件を削るのではなく、意味を保てるか採用担当者と相談します。変更後にもう一度低速条件で読み込み、文字が見えることと位置が安定することを同時に確認してから採用します。スコア一つで完了としない判断例です。

架空例：固定文字の軽量化が、更新で崩れた

別の架空例として、店舗サイトの「季節のおすすめ」という見出しだけに専用書体を使い、textで文字を絞ったとします。公開時には表示できていても、翌月に担当者が「秋のおすすめ」へ変更すると、追加した文字が対象に含まれず、一部だけ代替書体になる可能性があります。これは表示速度の測定ではなく、更新方法まで設計したかという問題です。

対策は、固定文言だけへ絞り込みを使う、更新のたびに対象文字を生成し直す仕組みを用意する、通常の文字範囲を持つ配信へ戻す、といった選択肢から決めます。編集担当者がコードを触らない運用なら、毎月手作業を頼む方法が本当に続くかも考えます。軽量化で削れた容量と、更新時に増える確認作業を並べて、管理できる方法を選びます。

7. 制作会社へ渡せる、改善依頼と検証の確認表

依頼書には症状と、残したい見た目を書く

依頼は「Google Fontsを最適化してください」だけで終わらせず、困っている画面と判断基準を添えます。たとえば「スマホのサービス詳細で見出しが後から動く。見出しの明朝体は残したいが、本文の書体は変更を相談できる」と書けば、担当者は優先事項を理解できます。発生を確認できないときには、その事実と試した条件を伝え、推測を確定事項として書かないようにします。

以下の表は、そのまま項目を転記できる依頼メモです。空欄を無理に埋める必要はありません。「未確認」と記載して、調査を担当する人を決めます。改善作業だけでなく、調査、検証、公開、戻す作業が見積もりに含まれるかも確認すると、作業範囲を揃えやすくなります。

比較は一つの変更から始め、悪化した点も残す

変更前後は同じURL、同じ画面幅、同じ速度制限とキャッシュ条件で比較します。一回だけの測定値で断定せず、複数回の結果が大きくぶれないかを見ます。フォントの容量が減っていても、主要画像が遅くなったり、読みやすさが下がったりしていれば、その点も記録します。都合のよい結果だけを残すと、次の担当者が判断を引き継げません。

架空の記録例なら「通常回線では差を確認できず。低速条件では見出しの空白が短くなった。一方、390px幅で三行へ折り返したため調整継続」と書けます。秒数を測っていなければ秒数を創作せず、観察できた内容を記載します。画像やJavaScriptも変更した場合には併記し、フォント単独で得られた効果として報告しません。

公開後は閲覧と更新の両方を確認する

検証環境で問題がなくても、本番ではキャッシュや配信設定が違う場合があります。公開後のURLで、修正した設定と表示を照合します。キャッシュを削除した直後だけでなく通常の閲覧も試し、メニューを開く、記事を読む、フォームを入力するなど、主要な操作を確かめます。実際の送信を試す場合は、関係者に分かるテストとして実施してください。

その後、編集担当者が文章を追加しても文字が欠けないか、太字や見出しが意図どおりかを確認します。変更するたびに専門家へ依頼しなければならない箇所は、運用手順へ残します。実利用データの評価は期間を置いて行い、公開当日の診断結果とは分けて記録します。更新が続く企業サイトでは、今回の速さと来月の管理のしやすさを一緒に確認します。

8. よくある疑問と、最初に取り組む順番

Google Fontsを外せば、必ず速くなるのか

フォントの通信を減らせる可能性はありますが、ページ全体が必ず体感できるほど速くなるとは限りません。大きな画像、サーバーの応答、重いスクリプトが主要な待ち時間なら、それらも調査が必要です。フォントを外した結果、見出しの改行やブランドの印象が変わることもあります。まず検証環境で外した案と残した案を比べ、必要な改善と見た目の条件が両立するかを見ます。

制作会社へ相談するときは、デザインを守りたい理由も伝えてください。「書体は何でもよい」と任せた後で全面的に戻すより、重要な見出しと変更できる本文を最初に示す方が検証を絞れます。ブランド書体を使うことと、読みやすい代替表示を準備することは両立できます。

スコアが上がれば、SEOや問い合わせも増えるのか

表示改善の確認と、検索・問い合わせの成果の確認は別です。フォントの読み込みが改善しても、サービスの説明や価格条件が分かりにくければ、相談に必要な判断材料は不足します。検索から来た人が求める内容とページが合っているか、連絡方法を見つけられるかも確認します。表示速度だけを理由に検索順位や問い合わせ数を保証する説明は避けます。

フォームまで到達した後の課題は、問い合わせフォーム改善のガイドで整理できます。フォントの変更日、ページ内容の変更日、広告の変更などを分けて記録しておくと、後から成果が変化した際に理由を検討しやすくなります。施策を実施したことと、その効果を確認できたことを分けて報告します。

今日の点検から、無理なく継続する

最初は、よく読まれるページ一つをスマホで開き、文字が表示される途中を確認してください。次に担当者と、取得している書体・太さ・容量を整理します。その結果に応じて、不要な指定の削減、表示方法と代替書体の調整、読み込み開始の改善を選びます。見つけた設定を全部変えるのではなく、どの症状に効くかを確かめながら進めます。

完了時には、対象URL、変更内容、比較条件、残る課題、次に確認する日を一枚にまとめます。技術に詳しくない担当者も「何が読めるようになり、どの画面で確認したか」を説明できれば、改善を続けやすくなります。Acquaへのご相談では、対象URLと困っている画面、残したいデザインをお知らせください。調査する範囲と、表示・操作を確認する内容から整理します。