PageSpeed Insightsの点数が悪かった時の考え方と改善方法

サイトの表示速度はユーザーが訪問した時の体験に大きな影響を与えます。サイトに訪問したけど読み込み時間が長すぎて、訪問を諦めた方も多いのではないでしょうか。

サイトの読み込み速度が遅ければ、ユーザーに見てもらうというスタートラインにすら立てなくなるリスクがあります。

読み込み速度に関する調査はたくさんありますので、気になる方は以下の記事を見てみてください。

47% の人は、平均的なサイトが 2 秒以内に読み込まれることを期待しています。

モバイルデバイスでページの読み込みに 3 秒以上かかると、53% のユーザーがそのページを離れます。

（Google 翻訳）

引用：https://www.sitebuilderreport.com/website-speed-statistics

読み込み速度を改善しようと思い立つキッカケは様々かと思います。今回はGoogleが提供している「PageSpeed Insightsの点数が悪いために改善したいと思いたった」という前提で、そもそも対応が必要かどうかといったところから、PageSpeed Insightsの役割や改善の方法について整理しました。

サイトの表示速度を改善したいと考えている方は参考にしてもらえると嬉しいです。

PageSpeed Insightsとは？

改めてPageSpeed Insightsとは何かといったところですが、公式のドキュメントを改めて見ていきましょう。

PageSpeed Insights（PSI）は、モバイルとパソコンの両方のデバイスでページのユーザーエクスペリエンスに関するレポートを提供し、そのページを改善する方法に関する最適化案を提供します。

PSI では、ページのラボデータとフィールドデータを確認できます。ラボデータは、制御された環境で収集されるため、問題のデバッグに役立ちます。ただし、実際のボトルネックを捕らえていないおそれがあります。フィールドデータは実際のユーザーエクスペリエンスをそのまま把握するのに役立ちますが、使用できる指標セットが限られます。思考の考え方、この 2 種類のデータについて詳しくは、速度ツールについてをご覧ください。

引用：https://developers.google.com/speed/docs/insights/v5/about?hl=ja

PageSpeed Insightsは、ユーザーエクスペリエンスに関するレポートを提供してくれるものになります。

大事なポイントとしては、「ラボデータ」と「フィールドデータ」の2つが存在するという事です。PageSpeed Insightsといえば、パフォーマンスの点数を思い浮かべる方が多いと思いますが、これは「ラボデータ」の結果となります。

実際に見てみましょう。以下は2025年11月時点の「https://haniwaman.com/」のPageSpeed Insightsでの結果です。「ラボデータ」のパフォーマンスの結果として52点ということが分かります。

そして、実は上の方に「実際のユーザーの環境で評価する」というセクションがあります。こちらが「フィールドデータ」の結果になります。

このように、PageSpeed Insightsでは、「ラボデータ」と「フィールドデータ」の2つの観点から、サイトの状況を分析してレポートを提供してくれるサービスとなります。

「ラボデータ」と「フィールドデータ」の違い

もう少し「ラボデータ」と「フィールドデータ」について見ていきましょう。両者はどういった違いがあるのでしょうか。

ざっくり言うと、ラボデータは特定の環境下でのシミュレーション結果で、フィールドデータは実際のユーザーの環境でのアクセス情報を集合した結果となります。

フィールドデータは、特定の URL のパフォーマンスに関する過去のレポートであり、さまざまなデバイスとネットワーク状況で実際のユーザーから収集された匿名化されたパフォーマンスデータです。ラボデータは、一連の固定されたネットワーク条件で 1 台の端末でページ読み込みをシミュレートしたデータです。

引用：https://developers.google.com/speed/docs/insights/v5/about?hl=ja#why-do-the-field-data-and-lab-data-sometimes-contradict-each-other

ラボデータの「特定の環境下」ですが、この条件はとても厳しい環境下でシミュレーションしています。デバイスの性能とネットワーク環境を制限した状態でアクセスした状況を想定しています。

具体的には以下の通りです。

メモリ：658MB
CPU：処理速度を1.2倍減速
ネットワーク：1.6Mbps
アクセスしている地域：アジア圏

このように、ラボデータは「特定の環境下（厳し目の環境下）」のため、実際のユーザーの環境であるフィールドデータと結果が一致しないことがあります。

特に日本の場合はスマートフォンのネットワーク環境が整っているため、ラボデータの結果が悪くても実際のユーザーは満足してサイトを閲覧しているというケースがあり得ます。

「ラボデータ」と「フィールドデータ」のどちらが重要？

PageSpeed Insightsの前提の説明が長くてすみませんが、もう少し「ラボデータ」と「フィールドデータ」について見ていきましょう。

PageSpeed Insightsの結果から「サイトの読み込みスピードを改善したい」と思う理由の1つとしてユーザー体験の向上があると思いますが、もう一つ重要な視点として「SEOに影響するから改善して順位を上げたい」という考えがあるかと思います。

結論から言うと、「ラボデータ」の点数はSEOに直接的に影響しません。

では何が影響するかというと、「フィールドデータ」の指標になります。もう少し具体的にいうと「Core Web Vitals」の指標です。

Core Web Vitals は、ページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性に関する実際のユーザーエクスペリエンスを測定する一連の指標です。検索結果でのランキングを上げ、全般的に優れたユーザーエクスペリエンスを提供できるよう、サイト所有者の皆様には、Core Web Vitals を改善することを強くおすすめします。Core Web Vitals は、その他のページエクスペリエンス要素とともに、Google のコアランキングシステムがランキングを決定する際に考慮する要素です。

引用：https://developers.google.com/search/docs/appearance/core-web-vitals?hl=ja

大事なポイントとしては、Core Web Vitalsは「実際のユーザーエクスペリエンスを測定する一連の指標」ということです。そして、実際のユーザーの結果は「フィールドデータ」ということになります。

「ラボデータ」と「フィールドデータ」はそれぞれ重要な結果ではあるのですが、「実際のユーザー」に対するアプローチで考えるなら、「フィールドデータ」の結果に注目して改善していけると良いのかなと考えます。

Core Web Vitalsの結果は「Search Console」でも確認可能

PageSpeed Insightsの中の「フィールドデータ」の中のCore Web Vitalsですが、Google Search Consoleからも確認が可能です。

その前に、Core Web Vitalsについてあまり紹介していなかったので、Core Web Vitalsとは何かというところですが、実際のユーザー環境におけるページの「読み込みパフォーマンス」、「インタラクティブ性」、「視覚的安定性」の3つの指標になります。

具体的には以下の通りです。略して呼ばれることが多いので「LCP」「INP」「CLS」という用語も押さえておくと良いかもしれません。

Largest Contentful Paint（LCP）: 読み込みパフォーマンスの尺度。優れたユーザーエクスペリエンスを提供するには、ページの読み込み開始から 2.5 秒以内に LCP を実現するようにします。

Interaction To Next Paint (INP): 応答性の尺度。優れたユーザーエクスペリエンスを提供するには、INP を 200 ミリ秒未満に収めるようにします。

Cumulative Layout Shift（CLS）: 視覚的安定性の尺度。優れたユーザーエクスペリエンスを提供するには、CLS スコアを 0.1 未満に収めるようにします。

引用：https://developers.google.com/search/docs/appearance/core-web-vitals?hl=ja

これらの指標は、PageSpeed Insightsの中の「フィールドデータ」にあります。（上の3つです）

そして、同様の指標はGoogle Search Consoleに登録していれば結果を確認することが可能です。場所としては、「エクスペリエンス」の中の「ウェブに関する主な指標」です。この結果は、Core Web Vitalsの指標に基づいて表示されています。

Core Web Vitals では、実際の使用状況データ（フィールドデータとも呼ばれます）に基づくページのパフォーマンスを確認できます。

引用：https://support.google.com/webmasters/answer/9205520?hl=ja

サイト訪問時のユーザーの体感を左右する「LCP」の指標

ここまでで、PageSpeed Insightsには「ラボデータ」と「フィールドデータ」の2つがあり、実際のユーザーの体験に対して改善するなら「フィールドデータ」の結果が重要であることを紹介してきました。

フィールドデータの中身をもう少し見ていくと、

ウェブに関する主な指標
- LCP（Largest Contentful Paint）
- INP（Interaction to Next Paint）
- CLS（Cumulative Layout Shift）
その他の重要な指標
- FCP（First Contentful Paint）
- TTFB（Time to First Byte）

に分類されていることが分かります。

LCPというのは、最初の画面に表示される「最大コンテンツ」が表示されるまでの速度になります。「最大コンテンツ」なのでサイトの作り方によって対象のコンテンツは異なるのですが、Webサイトのトップページの場合の多くはファーストビューの画像にあたる可能性が高いです。

INPは、ユーザーの操作に対する応答を評価するものです。例えば、スマホのハンバーガーアイコンを押した時にメニューが適切な時間で表示されるかどうか、などを測っています。

CLSは、よく使われる日本語だと「レイアウトシフト」です。広告のあるサイトやYoutubeなどのiframeが読み込まれている場合に体験したことある方も多いと思いますが、スクロールしている間にコンテンツが読み込まれて、表示している画面がガタッと移動する動きを指します。

このように、LCPは表示速度の体験、INPはインタラクションの体験、CLSは快適な閲覧の体験、ということで役割が分かれています。これらの3つがウェブに関する主な指標（Core Web Vitals）ということで評価される指標になるわけですが、その他の重要な指標は何かというと、LCPに内包されるようなイメージ持ってもらえると良いかと思います。

FCPは、最初のコンテンツが表示されるまでの速度です。TTFBは、最初のデータがサーバーから返ってくるまでの速度です。つまり、TTFBが速いとFCPが早くなり、FCPが速いとLCPが早くなるという関係となります。LCPを早くするという対応は、FCPを早くすることでもあり、TTFBを早くすることでもあります。なので、役割としては同じで、これらをまとめて「表示速度の体験」に分類されると捉えてもらうと整理しやすいかと思います。

長々と書いてきましたが、サイトの表示速度の改善という名目の場合に、Core Web Vitalsの中で最初にアプローチすると良いのは「LCP」の指標になり、LCPを改善するには「FCP」や「TTFB」に対する調査も必要になるというイメージです。

LCP の内訳を見よう

では、「LCP」を改善するためのアプローチを探っていきましょう。主に参考となるのはChromeデベロッパーツールの「パフォーマンス」「ネットワーク」、PageSpeed Insightsの「ラボデータ」の3つです。

「ラボデータ」を見ると「インサイト」として具体的な改善方法を提案してくれますが、ラボデータのスコアの改善だけをゴールに片っ端から対応していくアプローチは消耗戦になりやすいと個人的な経験から思います。（やれどもやれどもスコアが改善しない、のような）

おすすめなのは、実際の数字が改善しているかどうか確認しながら進める方法です。そのために「パフォーマンス」「ネットワーク」が参考になります。

Chromeデベロッパーツールで「パフォーマンス」を見よう

先ほどLCPとFCPとTTFBの関係として、「TTFBが速いとFCPが早くなりFCPが速いとLCPが早くなるという関係」を紹介しました。まずは、LCPの表示速度に関わる内訳を確認しましょう。

Chromeデベロッパーツールの「パフォーマンス」から確認しやすいと思います。少し閲覧環境の性能を落として計測すると見やすくなるかと思います。環境については右上の歯車から設定が可能です。

CPU：4倍減速
ネットワーク：高速 4G

また、拡張機能のコードはパフォーマンスに影響を与えるので、できれば拡張機能が入っていないChromeのシークレットモードで確認しましょう。

そして、左上の更新アイコンから「記録して再読み込み」で更新すると、記録されます。

記録中…

更新が終わると、結果が表示されます。左側のパネルにLCPとINP、CLSが並んでいて、LCPの結果が「2.75秒」ということで分かりやすく表示されていることが分かります。

この左側のパネルから、「LCP の内訳」を確認できるので、開いてみましょう。すると、「Time to First Byte（TTFB）」「リソース読み込みの遅延」「リソース読み込み時間」「要素のレンダリングの遅延」に分類されていることが分かります。

「Time to First Byte（TTFB）」は、サーバーとの接続を確立して最初の応答が返ってくるまでの時間。「リソース読み込みの遅延」は、ダウンロードを開始するまでに待っている時間。「リソース読み込み時間」は実際にダウンロードされる時間。「要素のレンダリングの遅延」はダウンロードした後の描画までの時間。

このように分類されていると、どの工程で時間がかかっているかの判断がしやすくなります。

Time to First Byte（TTFB）の内訳

Time to First Byte（TTFB）の内訳をさらに確認したいので、ネットワークも確認してみます。ネットワークを開いて、ドキュメントを押します。すると、名前の列に開いているページが表示されると思いますので選択して、右側の「タイミング」を開いてみてください。

このタイミングの内訳の「サーバーの応答を待機しています」までが、Time to First Byte（TTFB）の内訳になります。

リソースのスケジュール設定
- キュー
接続開始
- 停止しました
- DNS ルックアップ
- 初期接続
- SSL
リクエスト / レスポンス
- リクエストを送信しました
- サーバーの応答を待機しています ← ここまで
- コンテンツのダウンロード

この中で改善しやすいのは「サーバーの応答を待機しています」の部分かと思います。サーバーの処理性能にも依存するため、サーバーの性能が低い場合は、改善することで待機時間を早めることができたりします。

また、プログラムで処理してからHTMLドキュメントを返すようなサイトの場合は、処理方法を見直すことで待機時間を早めることが可能です。ページによっては、サーバー側であらかじめHTMLファイルとしてキャッシュしておいて、リクエストに対してキャッシュしたHTMLファイルをレスポンスすることで応答速度を早めるというアプローチも考えられます。

このように、Time to First Byte（TTFB）の中でもさらに細分化が可能です。とはいえ、主には「サーバーの応答を待機しています」に注目して、遅い場合は対応を考えるという形になるのかと思います。

リソース読み込みの遅延の改善

パフォーマンスのLCP の内訳の中で「リソース読み込みの遅延」をクリックすると、タイムライン上で対象の範囲を確認することができます。

Webページを表示するために様々なリソースが必要になります。具体的には、CSS、JavaScript、画像、動画、Webフォントです。

HTMLドキュメントを読み込んだ後にブラウザが何をしているかというと、HTMLの内容を上から解析を行い、リソースが出てきたタイミングで、ダウンロード対象としてマークしていきます。ダウンロード対象となったリソースは、ブラウザが優先度や混雑状況を見ながら順番にダウンロードし、それらを組み合わせて画面に描画していきます。

ここの確認のポイントとしては、LCP要素を描画するのに必要なリソースが、すぐにダウンロードを開始できているかです。

遅れる理由：リソース量が多くて待たされている

ダウンロードが必要なリソースが多いほどリソース読み込みも遅くなります。HTMLの内容を上から解析を行い、リソースが出てきたタイミングで、ダウンロード対象としてマークしていきます。ブラウザが状況を考慮してダウンロードしていくのですが、たくさんダウンロード対象があると順番待ちによる遅延は起きやすくなります。

遅れる理由：優先度がブラウザに伝わっていない

リソースのダウンロードは順番待ちになるのですが、ブラウザに対して優先度を伝えることが可能です。例えば、LCPに影響する画像ファイルを早くダウンロードして欲しい場合は、その画像の優先度を上げることでダウンロードを早めてもらえます。

遅れる理由：ブラウザが忙しくて混雑している

ブラウザは画面への描画の処理を1人で行なっているようなイメージを持ってもらえたらと思います。マルチタスクは基本的にできません。なので、何か1つ処理が走っていると他の処理は止まります。

処理を止める代表格として、JavaScriptの実行があります。JavaScriptはダウンロードされた時点で実行されます。実行されている間は画面の描画の処理は止まるという仕組みです。

極端な例だとJavaScriptの実行に3秒かかる処理が入っていると、描画まで3秒待つということになるので、重たい処理になっていないか注意する必要があります。

リソース読み込み時間の改善

リソースの読み込み時間は、LCPの対象となるコンテンツがダウンロードされるまでの時間です。画像の場合が画像のサイズに依存することが多いです。

パフォーマンスのLCP の内訳から「リソースの読み込み時間」をクリックすると、LCPの対象となっているリソースを確認できます。

画像サイズの見直しや圧縮、拡張子の変更など、できる限り、画像のサイズを小さくできる工夫をするとリソース読み込み時間は軽減されるはずです。

要素のレンダリングの遅延の改善

要素のレンダリングの遅延は、リソースが揃っているにも関わらず描画が遅れている状態を指します。

これは例えば、ブラウザが混雑している場合です。ブラウザは基本的には1人で処理しているので、ダウンロードしたLCPの対象のコンテンツを表示したくても、他で手いっぱいになっている場合は、その処理が終わってから表示するという流れになります。

LCPの対象コンテンツを早く表示するための最初のステップ

LCP の内訳を確認してきましたが、優先的に取り組むこととしてはLCPの対象となるコンテンツの優先度を高めてリソース読み込みの遅延を減らす、サイズを減らしてダウンロード時間を短くする、というアプローチです。

※ LCP対象コンテンツが画像という想定で進めていきます。

LCPの対象コンテンツの優先度を高める

「リソース読み込みの遅延」のタイムラインの中で、LCP対象コンテンツより優先度の低そうなリソースが先にダウンロード開始されている場合は見直しの余地がありそうです。

優先度が低そうな例としては、JavaScriptであったりWebフォントですね。これらのリソースは、LCPの対象コンテンツが画像の場合に直接的に影響することは少ないです。

そういった場合は、LCP対象コンテンツの優先度を高めると早くダウンロードを開始してくれるようになります。

具体的には、headタグ内のpreloadでfetchpriorityをhighで以下のように画像を指定することで優先度を高めることが可能です。

<head>
  <!-- 中略 -->
  <link rel="preload" as="image" href="./assets/img/hoge.webp" fetchpriority="high">
  <!-- 中略 -->
</head>

preload：「先にダウンロードしてください」という指定
fetchpriority：ネットワークの競合時に「優先度を上げてください」という指定

ちなみに、スマホとPCで表示する画像が異なる場合はmedia属性で分けることが可能です。

レスポンシブ画像をプリロードする | Articles | web.dev

LCPの対象コンテンツのサイズを減らしてダウンロード時間を短くする

LCPの対象コンテンツが画像の場合に影響を受けやすいのは、画像のサイズです。サイズが大きいとダウンロード時間が長くなります。

画像のサイズを減らすアプローチは大きくは3つあります。

画像の縦横のサイズを小さくする
画像をWebP形式に変換する
画像を圧縮する

縦横のサイズは、Retinaディスプレイを考慮しても幅780pxあれば十分な画像の場合に、幅4000pxの画像を配置していたら幅780pxにして配置するという対応です。これだけでもかなりダウンロード時間は短縮されます。

そして、WebP形式で圧縮すると、さらに画像のサイズを小さくすることが可能です。以下のSquooshのサービスを使うことで、WebP形式の変換、圧縮、縦横サイズの変更を一括で行うことができますので、画像がサイズが大きくてダウンロードに時間がかかっている場合は試してみてください。

Squoosh

画像に関連するLighthouseの提案：

画像配信を改善する：https://developer.chrome.com/docs/performance/insights/image-delivery?hl=ja

さらにLCPを早くするための手法

LCPの対象コンテンツへのアプローチで少なからず早く表示されるようになるかと思います。さらに改善したい場合は、その他のLCPに関係するアプローチもありますので確認していきましょう。

レンダリングブロックの排除

LCPは最大コンテンツを描画するまでの時間になるので、描画を妨げる処理が入っていると遅くなります。「レンダリングブロック」という言葉を聞いたことある方も多いと思いますが、CSSやJavaScriptはレンダリングをブロックする処理になりやすいので注意が必要です。

CSS

CSSファイルの読み込みは100%レンダリングブロックに繋がります。たくさんCSSファイルを読み込んでいても中には必要のないファイルもあるはずです。

LCPに対するCSSのレンダリングブロックの排除するという場合に（おそらく）最も効果的なのは、ファーストビューのCSSだけHTMLドキュメントにインライン化して、ファーストビューに関係ないCSSは遅延読み込みするという方法です。

これで、LCPのコンテンツを描画するためにCSSファイルをダウンロードせずに、ファーストビューを表示した後にその他のCSSを読み込んで描画する、といった動きにすることが可能になります。

CSSに関連するLighthouseの提案：

レンダリングをブロックしているリクエスト：https://web.dev/learn/performance/understanding-the-critical-path
使用していない CSS の削減：https://developer.chrome.com/docs/lighthouse/performance/unused-css-rules
CSS の最小化：https://developer.chrome.com/docs/lighthouse/performance/unminified-css/

自前のJavaScript

JavaScriptは、「ダウンロード中にHTMLの解析を止める」と「ダウンロードされたら即実行」、「実行中は画面描画の処理を止める」という特徴があるため、注意して扱う必要があります。

JavaScriptによるレンダリングブロックを防ぐ1つの方法として、scriptタグにdeferを指定することです。deferを指定することでダウンロード自体は進みますが、実行のタイミングが初回の描画の後になることが多い（そう）です。

<script src="./assets/js/main.js" defer></script>

JavaScriptに関連するLighthouseの提案：

レンダリングをブロックしているリクエスト：https://web.dev/learn/performance/understanding-the-critical-path
使用していない JavaScript の削減：https://developer.chrome.com/docs/lighthouse/performance/unused-javascript/
重複する JavaScript：リンクなし
JavaScript の最小化：https://developer.chrome.com/docs/lighthouse/performance/unminified-javascript/
JavaScript の実行にかかる時間：https://developer.chrome.com/docs/lighthouse/performance/bootup-time/
強制リフロー：https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing

サードパーティのJavaScript

サードパーティのJavaScriptの場合は、埋め込むタグが決まっていたりします。例えば、Tag Managerだとscriptを生成しますが、asyncの属性で追加されます。asyncの場合はJavaScriptファイルのダウンロードの間にHTMLの解析を妨げることはありませんが、ダウンロードされたタイミングで即実行されるという特徴があります。

そのため、LCPの対象コンテンツを描画する前に、描画の処理を止める可能性があることを押さえておくことが重要です。特にTag Managerの場合は、付随して様々なJavaScriptを実行している可能性がありますので、どういった処理を行なっているかを注意して管理することが大事です。

サードパーティに関連するLighthouseの提案：

サードパーティ：https://web.dev/articles/optimizing-content-efficiency-loading-third-party-javascript

Webフォントの代替表示

LCPの対象コンテンツがテキストの場合はWebフォントは直接的な影響はない想定です。ただし、例えばGoogle Fontsの場合は、CSSファイルのダウンロードと大量のフォントファイルのダウンロードによる影響があるため紹介します。

例えば、Google FontsでNoto Sans JPを読み込む場合は、以下のような読み込み方をします。

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@100..900&display=swap" rel="stylesheet">

Noto Sans Japanese – Google Fonts

link rel="stylesheet"から分かるように、CSSファイルの読み込みが起点となります。このCSSファイルの中身を見てみましょう。

@font-face {
  font-family: 'Noto Sans JP';
  font-style: normal;
  font-weight: 100 900;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosansjp/v55/-F62fjtqLzI2JPCgQBnw7HFowwII2lcnk-AFfrgQrvWXpdFg3KXxAMsKMbdN.0.woff2) format('woff2');
  unicode-range: U+25ee8, U+25f23, U+25f5c, U+25fd4, U+25fe0, U+25ffb, U+2600c, U+26017, U+26060, U+260ed, U+26222, U+2626a, U+26270, U+26286, U+2634c, U+26402, U+2667e, U+266b0, U+2671d, U+268dd, U+268ea, U+26951, U+2696f, U+26999, U+269dd, U+26a1e, U+26a58, U+26a8c, U+26ab7, U+26aff, U+26c29, U+26c73, U+26c9e, U+26cdd, U+26e40, U+26e65, U+26f94, U+26ff6-26ff8, U+270f4, U+2710d, U+27139, U+273da-273db, U+273fe, U+27410, U+27449, U+27614-27615, U+27631, U+27684, U+27693, U+2770e, U+27723, U+27752, U+278b2, U+27985, U+279b4, U+27a84, U+27bb3, U+27bbe, U+27bc7, U+27c3c, U+27cb8, U+27d73, U+27da0, U+27e10, U+27eaf, U+27fb7, U+2808a, U+280bb, U+28277, U+28282, U+282f3, U+283cd, U+2840c, U+28455, U+284dc, U+2856b, U+285c8-285c9, U+286d7, U+286fa, U+28946, U+28949, U+2896b, U+28987-28988, U+289ba-289bb, U+28a1e, U+28a29, U+28a43, U+28a71, U+28a99, U+28acd, U+28add, U+28ae4, U+28bc1, U+28bef, U+28cdd, U+28d10, U+28d71, U+28dfb, U+28e0f, U+28e17, U+28e1f, U+28e36, U+28e89, U+28eeb, U+28ef6, U+28f32, U+28ff8, U+292a0, U+292b1, U+29490, U+295cf, U+2967f, U+296f0, U+29719, U+29750, U+29810, U+298c6, U+29a72, U+29d4b, U+29ddb, U+29e15, U+29e3d, U+29e49, U+29e8a, U+29ec4, U+29edb, U+29ee9, U+29fce, U+29fd7, U+2a01a, U+2a02f, U+2a082, U+2a0f9, U+2a190, U+2a2b2, U+2a38c, U+2a437, U+2a5f1, U+2a602, U+2a61a, U+2a6b2, U+2a9e6, U+2b746, U+2b751, U+2b753, U+2b75a, U+2b75c, U+2b765, U+2b776-2b777, U+2b77c, U+2b782, U+2b789, U+2b78b, U+2b78e, U+2b794, U+2b7ac, U+2b7af, U+2b7bd, U+2b7c9, U+2b7cf, U+2b7d2, U+2b7d8, U+2b7f0, U+2b80d, U+2b817, U+2b81a, U+2d544, U+2e278, U+2e569, U+2e6ea, U+2f804, U+2f80f, U+2f815, U+2f818, U+2f81a, U+2f822, U+2f828, U+2f82c, U+2f833, U+2f83f, U+2f846, U+2f852, U+2f862, U+2f86d, U+2f873, U+2f877, U+2f884, U+2f899-2f89a, U+2f8a6, U+2f8ac, U+2f8b2, U+2f8b6, U+2f8d3, U+2f8db-2f8dc, U+2f8e1, U+2f8e5, U+2f8ea, U+2f8ed, U+2f8fc, U+2f903, U+2f90b, U+2f90f, U+2f91a, U+2f920-2f921, U+2f945, U+2f947, U+2f96c, U+2f995, U+2f9d0, U+2f9de-2f9df, U+2f9f4;
}
@font-face {
  font-family: 'Noto Sans JP';
  font-style: normal;
  font-weight: 100 900;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/notosansjp/v55/-F62fjtqLzI2JPCgQBnw7HFowwII2lcnk-AFfrgQrvWXpdFg3KXxAMsKMbdN.1.woff2) format('woff2');
  unicode-range: U+1f235-1f23b, U+1f240-1f248, U+1f250-1f251, U+2000b, U+20089-2008a, U+200a2, U+200a4, U+200b0, U+200f5, U+20158, U+201a2, U+20213, U+2032b, U+20371, U+20381, U+203f9, U+2044a, U+20509, U+2053f, U+205b1, U+205d6, U+20611, U+20628, U+206ec, U+2074f, U+207c8, U+20807, U+2083a, U+208b9, U+2090e, U+2097c, U+20984, U+2099d, U+20a64, U+20ad3, U+20b1d, U+20b9f, U+20bb7, U+20d45, U+20d58, U+20de1, U+20e64, U+20e6d, U+20e95, U+20f5f, U+21201, U+2123d, U+21255, U+21274, U+2127b, U+212d7, U+212e4, U+212fd, U+2131b, U+21336, U+21344, U+213c4, U+2146d-2146e, U+215d7, U+21647, U+216b4, U+21706, U+21742, U+218bd, U+219c3, U+21a1a, U+21c56, U+21d2d, U+21d45, U+21d62, U+21d78, U+21d92, U+21d9c, U+21da1, U+21db7, U+21de0, U+21e33-21e34, U+21f1e, U+21f76, U+21ffa, U+2217b, U+22218, U+2231e, U+223ad, U+22609, U+226f3, U+2285b, U+228ab, U+2298f, U+22ab8, U+22b46, U+22b4f-22b50, U+22ba6, U+22c1d, U+22c24, U+22de1, U+22e42, U+22feb, U+231b6, U+231c3-231c4, U+231f5, U+23372, U+233cc, U+233d0, U+233d2-233d3, U+233d5, U+233da, U+233df, U+233e4, U+233fe, U+2344a-2344b, U+23451, U+23465, U+234e4, U+2355a, U+23594, U+235c4, U+23638-2363a, U+23647, U+2370c, U+2371c, U+2373f, U+23763-23764, U+237e7, U+237f1, U+237ff, U+23824, U+2383d, U+23a98, U+23c7f, U+23cbe, U+23cfe, U+23d00, U+23d0e, U+23d40, U+23dd3, U+23df9-23dfa, U+23f7e, U+2404b, U+24096, U+24103, U+241c6, U+241fe, U+242ee, U+243bc, U+243d0, U+24629, U+246a5, U+247f1, U+24896, U+248e9, U+24a4d, U+24b56, U+24b6f, U+24c16, U+24d14, U+24e04, U+24e0e, U+24e37, U+24e6a, U+24e8b, U+24ff2, U+2504a, U+25055, U+25122, U+251a9, U+251cd, U+251e5, U+2521e, U+2524c, U+2542e, U+2548e, U+254d9, U+2550e, U+255a7, U+2567f, U+25771, U+257a9, U+257b4, U+25874, U+259c4, U+259cc, U+259d4, U+25ad7, U+25ae3-25ae4, U+25af1, U+25bb2, U+25c4b, U+25c64, U+25da1, U+25e2e, U+25e56, U+25e62, U+25e65, U+25ec2, U+25ed8;
}

一部だけ抜粋しましたが、@font-faceの定義が大量にあります。フォントファイルをダウンロードするまでの流れとしては、HTMLファイルの解析→CSSファイルのダウンロード→CSSの解析→フォントファイルのダウンロード（使っているものだけ）という流れです。

この流れの中で、レンダリングブロックする工程は「CSSファイルのダウンロード」の部分だけです。フォントファイルのダウンロードは描画と非同期で進むので特に関係ありません。

つまり、「CSSファイルのダウンロード」をできるだけ早くできれば良いのですが、その工夫が以下になります。preconnectでCSSとフォントを格納している外部サーバーへの接続を確立を早めに行い、スムーズにダウンロードできるようになっています。

<!-- Google FontsのCSSファイルのダウンロードに備えて -->
<link rel="preconnect" href="https://fonts.googleapis.com">

<!-- Google Fontsのwoff2ファイルのダウンロードに備えて -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

代替フォントを表示する

改めて@font-faceの定義を見ていただくとfont-display: swap;と書かれていることが分かります。Webフォントは、フォントファイルがダウンロードされてから対象のテキスト部分に当てはめる、という処理の流れになります。

ダウンロードされるまでは、どういう表示にするかは、このfont-displayで指定が可能です。4つ指定があるのですが、swapを指定することによって、ダウンロードされるまではデバイスフォントで代替して、ダウンロードされたらWebフォントに置き換える、という動きになります。

font-display – CSS | MDN

このようにダウンロードが完了していなくても何かしらのフォントで表示されることによって、ユーザーは最低限で閲覧できるようにすることが可能になります。

フォントに関連するLighthouseの提案：

フォント表示：https://developer.chrome.com/blog/font-fallbacks

おわりに

長々と書いてきましたが、最後に改めてまとめていきたいと思います。

PageSpeed Insightsについて、
- PageSpeed Insightsには「ラボデータ」「フィールドデータ」の2つの結果が表示される
- 実際のユーザーエクスペリエンスの結果は「フィールドデータ」
- フィールドデータの指標はCore Web Vitals
- Core Web Vitalsは実際のユーザーエクスペリエンスを評価対象としている
- Core Web Vitalsの指標はSearch Consoleでも確認が可能

ページ読み込み速度の改善について、
- LCPの対象画像のサイズを縮小
- LCPの対象画像の優先度を上げる
- CSSとJavaScriptのレンダリングブロックの排除
- Webフォントの代替表示

というところを紹介してきました。

調べながらのところも多く至らぬ点が多々あると思いますが、解釈や情報が誤っている場合は、お手数ですが@haniwa008までご一報いただけますと幸いです🙇‍♂️