「ページは表示されているのに、クリックしても反応しない…」「FIDってよく聞くけど、INPと何が違うんだろう？」
このような疑問を感じているウェブ担当者の方は多いのではないでしょうか。
本記事では、FIDの基本的な仕組みや評価基準、改善施策、2024年3月のINP移行について解説しました。
最後まで読めば、自サイトのFIDスコアが低下している原因を把握し、具体的な改善アクションに移せるようになります。
FIDとは？コアウェブバイタルが求める初回入力遅延の仕組み
コアウェブバイタルは、Googleがページ体験の品質を評価するために設けた指標群であり、FIDはその中で「操作応答性」を測るために用いられてきました。
FIDはユーザーが最初にページを操作したときの入力遅延を測定する指標で、ページ読み込み後にボタンやリンクをクリックしてから、ブラウザが反応を開始するまでの時間を指します。
FIDを理解するうえで重要なポイントは以下のとおりです。
- FIDが測定するユーザー操作の種類
- メインスレッドの混雑がFIDを悪化させる理由
- FIDとTBT（Total Blocking Time）の相関関係
それぞれ詳しく解説します。
FIDが測定するユーザー操作の種類
FIDはすべてのユーザー操作を測定対象とするわけではなく、特定のインタラクションに限定されています。
具体的に測定対象となる操作は以下のとおりです。
- リンクのクリック・ボタンのクリック
- テキストフィールド・チェックボックス・ラジオボタンへの入力
- カスタムJavaScriptで実装されたインタラクション要素の操作
一方で、スクロール・ピンチ操作・ズームはFIDの測定対象には含まれません。
これらの連続的な操作はブラウザが別経路で処理するため、入力遅延の評価に適さないとGoogleは判断しているのです。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
メインスレッドの混雑がFIDを悪化させる理由
なぜFIDが長くなるのか、その仕組みを理解しておくことはFID改善の出発点となります。
ブラウザのメインスレッドは、HTMLの解析・CSSの適用・JavaScriptの実行をすべて1つのスレッドで処理しているのが特徴です。
そのため、ページ読み込み中にJavaScriptの実行などでメインスレッドが長時間ブロックされると、ユーザーが操作しようとした瞬間に、ブラウザはその入力を処理できない状態に陥ります。
つまり、FIDが高くなる根本的な要因は、操作のタイミングにメインスレッドが占有されているという状況です。
この仕組みを理解することで、JavaScriptの最適化やタスクの分割がFID改善に直結する理由が明確になるでしょう。
参考：First Input Delay（FID）｜web.dev（https://web.dev/articles/fid?hl=ja）
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
FIDとTBT（Total Blocking Time）の相関関係
FIDはフィールドデータ（実際のユーザー操作）がなければ測定できない指標です。
そこで、ラボ環境でFIDの代替として活用されるのがTBT（Total Blocking Time：合計ブロック時間）で、FIDと強い相関関係があるとされています。
TBTは、FCP（最初のコンテンツ描画）からTTI（インタラクティブになるまでの時間）の間に存在する「長いタスク」の超過時間を合計した値です。
FIDとTBTの主な違いを整理すると以下のとおりです。
| 比較項目 | FID | TBT |
| 測定環境 | フィールドデータ（実ユーザー） | ラボデータ（シミュレーション） |
| 測定対象 | 最初の入力に対する遅延 | ページ読み込み中の全ブロック時間 |
| 計測ツール | Search Console・CrUX | Lighthouse・PageSpeed Insights |
TBTが高い場合はFIDも悪化している可能性が高く、TBTを改善することがFIDスコア向上の直接的な手がかりになります。
ラボ環境ではFIDを直接測れないため、TBTを指標にしてボトルネックを特定するアプローチが実践的です。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
FIDの評価基準と判定レベルの見方
ページのFIDがどのレベルにあるかを正確に把握することは、改善の優先度を決めるうえで不可欠です。
Googleは100ms・300msを境界値としてFIDを3段階で評価しており、ユーザー体験に直接影響する数値として重視されてきました。
評価基準の見方は以下のとおりです。
- 良好・要改善・不良の数値の目安（100ms・300ms）
- 75パーセンタイルで評価される理由
- モバイルとデスクトップで数値傾向が異なる点
各項目を詳しく解説します。
良好・要改善・不良の数値の目安（100ms・300ms）
FIDの評価は3段階で区分されており、数値が低いほどユーザーの操作体験が良好となります。
| 評価 | 数値の範囲 | ユーザーへの影響 |
| 良好（Good） | 100ms未満 | 操作に対して即座に反応していると感じる |
| 要改善（Needs Improvement） | 100ms〜300ms | わずかなもたつきを感じる可能性がある |
| 不良（Poor） | 300ms超 | 明らかな遅延としてユーザーが知覚する |
100ms未満という基準はユーザーが「即座の反応」として知覚できる上限とされており、これを超えると操作感の低下につながります。
ページの評価はこの基準値をもとに、Search ConsoleやPageSpeed Insightsに表示されるのです。
参考：First Input Delay（FID）｜web.dev（https://web.dev/articles/fid?hl=ja） ※100ms・300msの評価基準値を引用
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
75パーセンタイルで評価される理由
Googleがすべてのコアウェブバイタル指標に75パーセンタイルを採用している理由は、1人のユーザーの体験だけを取り上げるのではなく、大多数のユーザー体験を代表する値で評価するためです。
たとえば、あるページに100件のアクセスがあった場合、FIDの値を低い順に並べて75番目の値が「そのページのFID」として評価されるという仕組みになっています。
つまり、75%のユーザーが基準値以内の体験を得られていれば良好と判断するという設計です。
一方で、web.devの公式ドキュメントではFIDについては特に95〜99パーセンタイルも確認することを推奨しており、最初の入力体験が極端に悪いケースを見逃さないための配慮が求められます。
全体スコアが良好であっても、一部のユーザーが不良を経験している場合があるため、上位パーセンタイルも合わせて確認しておくといいでしょう。
参考：First Input Delay（FID）｜web.dev（https://web.dev/articles/fid?hl=ja） ※75パーセンタイルの評価方法および95〜99パーセンタイル確認推奨の記述を引用
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
モバイルとデスクトップで数値傾向が異なる点
FIDの数値は、同じサイトでもアクセス環境によって大きく異なる傾向があります。
特にモバイルデバイスはCPU処理能力がデスクトップと比べて低いため、JavaScriptの解析・実行に時間がかかりやすく、モバイルのFIDスコアはデスクトップよりも高く（悪く）なる傾向があるのが特徴です。
Googleのモバイルファーストインデックスが適用されているサイトでは、モバイルのFIDスコアが検索評価により大きな影響を与えるという点も注意が必要です。
モバイルとデスクトップで傾向が異なる主な要因は以下のとおりです。
- CPU処理能力の差（モバイルのほうが処理に時間がかかる）
- ネットワーク速度（モバイルは4G/5G環境が混在し不安定になりやすい）
- バッテリー管理（省電力モードではCPU速度が制限される場合がある）
Search Consoleのコアウェブバイタルレポートはモバイルとデスクトップを分けて確認できるため、それぞれの数値を定期的にチェックすることが重要です。
両方のデバイスで良好なスコアを維持することが、幅広いユーザーへの最適な体験提供につながるでしょう。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
FIDを計測する4つのツールと確認方法
FIDの改善を進めるには、現在のスコアを正確に把握することが最初のステップです。
Googleは複数の公式ツールを提供しており、目的に応じて使い分けることでFIDの課題を効率的に特定できます。
FIDを計測する4つのツールと確認方法は以下のとおりです。
- Google Search Console
- PageSpeed Insights
- Lighthouse
- Web Vitals Chrome拡張機能
それぞれのツールの特徴を詳しく見ていきましょう。
① Google Search Console
Google Search Consoleは、実際にサイトを訪問したユーザーのフィールドデータをもとにFIDスコアを確認できる公式ツールです。
「ウェブに関する主な指標」レポートを開くと、URL単位でFIDの良好・要改善・不良の判定状況を確認できます。
同じ問題を持つ複数のURLをグループ表示する機能もあるため、サイト全体のFIDの傾向をまとめて把握するのに適しているのが特徴です。
ただし、Search ConsoleはFIDの廃止（2024年9月）に伴い、新しいデータはINPに切り替わっています。
過去のFIDデータは引き続き閲覧できるため、改善経緯の確認や参照資料としての活用が考えられるでしょう。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
② PageSpeed Insights
PageSpeed Insightsは、URLを入力するだけでFIDを含むコアウェブバイタルのスコアを確認できるGoogleの無料ツールです。
| 項目 | 内容 |
| データの種類 | フィールドデータ（CrUX）＋ラボデータ（Lighthouse）の両方 |
| 確認できる指標 | FID（廃止後はINP）・LCP・CLS・TBT など |
| モバイル/デスクトップ | 切り替えて確認可能 |
| 利用方法 | URLを入力して「分析」をクリックするだけ |
フィールドデータとラボデータの両方を同時に確認できる点がPageSpeed Insightsの大きな特徴で、実ユーザーの体験とシミュレーション結果を照合しながら分析できます。
ただし、FIDのフィールドデータはCrUXに蓄積された実測値を使うため、アクセスが少ないページでは表示されないことがあるのです。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
③ Lighthouse
LighthouseはChromeブラウザに組み込まれた開発者向けツールで、実際のユーザー入力がなくてもラボ環境でパフォーマンスを測定できます。
FIDは実ユーザーの操作を必要とするため、Lighthouseでは代替指標のTBT（Total Blocking Time）が測定されるのが仕様です。
LighthouseでTBTを改善することは、実際のFIDスコア向上に直結する施策として広く活用されています。
Lighthouseの主な確認手順は以下のとおりです。
- ChromeのDevToolsを開いてLighthouseタブを選択する
- モバイル/デスクトップを選択してレポートを生成する
- パフォーマンスセクションのTBT値と改善提案を確認する
TBTに加えてLCPやCLSなどのコアウェブバイタル全体を一度に把握できるため、総合的なパフォーマンス改善の起点として活用するといいでしょう。
開発環境でのデバッグや施策効果の事前確認にも向いています。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
④ Web Vitals Chrome拡張機能
Web Vitals Chrome拡張機能はGoogleが公式に提供する拡張機能で、ブラウザで任意のページを開くだけでFID・LCP・CLSをリアルタイムに確認できます。
インストール後はツールバーのアイコンをクリックするだけで各指標のスコアが表示されるため、開発者でなくても直感的に使えるのが強みです。
ページを操作したタイミングでFIDが即座に計測されるため、特定の操作でスコアが悪化するかどうかの確認に向いています。
ただし、フィールドデータではなく当該ブラウザのセッションに基づく測定値であるため、参考値として扱うことが重要です。
Search ConsoleやPageSpeed Insightsと組み合わせることで、より精度の高い診断が可能になります。
関連記事：SEOのおすすめChrome拡張機能20選！初心者からプロも愛用｜（https://infosuccess.jp/seo-chrome/）
FIDが低下する主な原因
FIDスコアが悪化している場合、その背景には特定の技術的要因が潜んでいることがほとんどです。
根本原因を理解せずに施策を打っても効果は限定的となるため、まず原因を正確に把握することが改善への近道となります。
FIDが低下する主な原因は以下のとおりです。
- 重いJavaScriptバンドルによるメインスレッドのブロック
- サードパーティスクリプトが引き起こす遅延
- 過多なHTTPリクエストとキャッシュ未設定の影響
一つずつ確認していきましょう。
重いJavaScriptバンドルによるメインスレッドのブロック
FIDスコアの悪化で最も多い原因のひとつが、大きなJavaScriptバンドルによるメインスレッドのブロックです。
ブラウザはJavaScriptを受け取ったとき、まずコードを解析・コンパイルし、続けて実行するという処理をメインスレッド上で行います。
このとき、バンドルサイズが大きいほどメインスレッドの占有時間が長くなり、ユーザーの操作に応答できない「長いタスク」が発生しやすくなるのです。
特にReactやAngularなどのフロントエンドフレームワークを使用している場合、不要なコンポーネントや過剰な再レンダリングがFIDを悪化させる一因となります。
Lighthouseのパフォーマンスレポートで「JavaScriptの実行時間の短縮」という提案が表示されている場合は、バンドルの肥大化が疑われるでしょう。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
サードパーティスクリプトが引き起こす遅延
広告タグ・アクセス解析・チャットウィジェット・SNSボタンなどのサードパーティスクリプトは、自社でコントロールできない外部のJavaScriptをページに読み込ませます。
これらのスクリプトはページ読み込み時にメインスレッドを占有するため、場合によってはFIDを数百ミリ秒単位で悪化させる原因となるのです。
特に複数のサードパーティスクリプトが競合して読み込まれる環境では、影響がさらに大きくなるという点に注意が必要です。
PageSpeed Insightsの「サードパーティコードの影響を低減してください」という診断項目が表示されている場合、この原因が該当している可能性が高くなります。
FIDの改善を進める際は、サードパーティスクリプトの整理・優先順位付けを早期に取り組むべき施策として位置づけるといいでしょう。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
過多なHTTPリクエストとキャッシュ未設定の影響
FIDへの影響が見落とされやすい要因として、HTTPリクエストの多さとブラウザキャッシュの未設定があります。
ページ読み込み時に大量のリクエストが発生すると、ブラウザは多くのファイルの取得・処理を同時にこなす必要があり、メインスレッドの負荷が高まるのが特徴です。
また、キャッシュが設定されていない場合、リピート訪問者もページを開くたびにすべてのリソースを再取得することになり、初回読み込み時と同等のメインスレッド負荷が繰り返し発生します。
HTTPリクエストとキャッシュに関する主な問題点と対処の方向性を整理すると以下のとおりです。
| 問題点 | 影響 | 対処の方向性 |
| リクエスト過多 | メインスレッドの占有時間増加 | リソースの統合・不要ファイルの削除 |
| キャッシュ未設定 | リピートユーザーも毎回重い読み込み | Cache-Controlヘッダーの適切な設定 |
| 大きな画像・フォント | パース時間の増加 | 遅延読み込み・フォーマット最適化 |
PageSpeed Insightsで「効率的なキャッシュポリシーを使用して静的なアセットを配信してください」という指摘が出ている場合は、キャッシュ設定の見直しが必要になります。
HTTPリクエストの最適化とキャッシュ設定は比較的実装コストが低く、FIDだけでなくLCPなど他の指標改善にもつながるため、優先的に着手するといいでしょう。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
FIDを改善する具体的な施策
FIDを改善するためのアプローチは、共通してメインスレッドの負荷を下げることに集約されます。
施策ごとの難易度と効果を把握したうえで取り組むことで、限られたリソースで最大の改善効果を得やすくなるでしょう。
FIDを改善する具体的な施策は以下のとおりです。
- JavaScriptの分割・遅延読み込みで長いタスクを減らす
- 不要なサードパーティスクリプトの削除と見直し
- Webワーカーを活用してメインスレッドの負荷を分散する
各ポイントをしっかり把握しておきましょう。
JavaScriptの分割・遅延読み込みで長いタスクを減らす
FIDを効果的に改善するうえで、JavaScriptの扱い方を見直すことは最も優先度の高い施策のひとつです。
大きなJavaScriptバンドルを分割し、そのページで必要なコードだけを最初に読み込む「コードスプリッティング」は、長いタスクを削減する基本的なアプローチとなります。
50ms以上かかるJavaScriptタスクは「長いタスク」として定義されており、これを複数の短いタスクに分割することでメインスレッドへの連続的な負荷を軽減するのが重要なポイントです。
具体的な実装手順は以下のとおりです。
- Lighthouseのレポートで長いタスクを特定する
- 該当するJavaScriptモジュールをダイナミックインポートで分割する
- defer属性またはasync属性を使って非重要スクリプトの読み込みを遅延させる
- 実装後にLighthouseおよびPageSpeed InsightsのTBTが改善されているか確認する
コードスプリッティングはWebpackやViteなどのバンドラーに標準的な機能として含まれており、大きな追加コストなく導入できます。
まずLighthouseでボトルネックを特定してから着手することで、効率よく改善を進められるでしょう。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
不要なサードパーティスクリプトの削除と見直し
サードパーティスクリプトはFIDに大きな影響を与えますが、すべてを削除することは現実的ではなく、必要性の高いものとそうでないものを仕分けることが出発点となります。
まず全スクリプトをリストアップし、実際に使用されているか・代替手段があるかを確認するという整理を行うことが重要です。
たとえば、すでに使用していない旧バージョンの広告タグや、A/Bテストツールの残存スクリプトは、即座に削除できる候補として早めに整理しておきましょう。
どうしても残さなければならないスクリプトについては、defer属性を付けてページ本体の読み込み後に遅延させるか、ユーザー操作後にスクリプトを動的に読み込む「Facade（ファサード）パターン」が有効です。
定期的なサードパーティスクリプトの棚卸しは、FIDだけでなくページ全体の表示速度の維持にもつながるでしょう。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
Webワーカーを活用してメインスレッドの負荷を分散する
JavaScriptはシングルスレッドで動作する言語ですが、Web Workers（Webワーカー）を使用することで、一部の処理をメインスレッドとは独立したバックグラウンドスレッドに移管できます。
データの変換・ソート・暗号化処理など、UI描画に直接関係しない重い処理をWebワーカーに移すことで、メインスレッドをユーザー操作の応答に専念させる設計が実現するのです。
FIDとWebワーカーの関係を整理すると以下のとおりです。
| 処理の種類 | メインスレッド | Webワーカー |
| DOM操作・UI更新 | ○ 必須 | × 不可 |
| データ計算・変換 | △ 負荷になる | ○ 推奨 |
| 暗号化・圧縮処理 | △ 負荷になる | ○ 推奨 |
| ファイル読み込み | △ 負荷になる | ○ 推奨 |
Webワーカーは比較的導入コストが低く、メインスレッドの長いタスクを分散させるシンプルな手段として広く活用されています。
すべての処理をWebワーカーに移すことはできませんが、負荷の大きい処理を選別して移管することで、FID改善の効果を実感しやすくなるでしょう。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
FIDからINPへ｜2024年3月の変更点と今後の対応
2024年3月、GoogleはコアウェブバイタルのFIDをINP（Interaction to Next Paint）に正式に置き換えました。
この変更はウェブパフォーマンスの評価方法に大きな影響を与えており、FIDで培った知識をINP対策にどう活かすかが重要な課題となっています。
FIDからINPへの変更に関するポイントは以下のとおりです。
- FIDが廃止されINPが新コアウェブバイタルになった背景
- FIDとINPの測定範囲の違い
- FID改善の知識をINP対策に活かす方法
それぞれの内容を理解していきましょう。
FIDが廃止されINPが新コアウェブバイタルになった背景
2024年3月12日、GoogleはINP（Interaction to Next Paint）をコアウェブバイタルの正式指標として採用し、FIDをその役割から退けました。
FIDが廃止された主な理由は、FIDが「ページ最初の操作の入力遅延」しか測定しないという測定範囲の制約です。
たとえば、ページ最初のクリックには即座に反応しても、その後のボタン操作や入力フォームに何百ミリ秒もかかるケースをFIDは検出できていなかったのです。
INPはページ上のすべてのインタラクションを観測し、その中で最も長いレスポンスタイムを代表値として採用することで、ページ全体の応答性をより正確に評価できます。
Googleは同年9月9日にChromeのFIDサポートを完全終了し、PageSpeed InsightsやCrUXからもFIDデータが削除されたことで、INPへの移行が完結しました。
参考：Chrome ends support for First Input Delay｜web.dev（https://web.dev/blog/fid?hl=en） ※FIDのChromeツールサポート終了日（2024年9月9日）を引用
関連記事：GoogleのSEOガイドライン6選｜チェックリスト150個紹介！｜（https://infosuccess.jp/seo-guidline/）
FIDとINPの測定範囲の違い
FIDとINPの最も根本的な違いは、何を・いつ測定するかという点にあります。
FIDは「ページ読み込み後の最初の操作の入力遅延」のみを測定しており、測定対象は1インタラクションに限定されていました。
一方INPは、ページ訪問中のすべてのクリック・タップ・キーボード操作を対象とし、最も遅かった操作のレスポンスタイムをページの代表値として使用します。
FIDとINPの違いを比較すると以下のとおりです。
| 比較項目 | FID | INP | 備考 |
| 測定対象 | 最初の操作のみ | すべてのインタラクション | INPのほうが広範囲 |
| 測定内容 | 入力遅延のみ | 入力遅延＋処理時間＋描画遅延 | INPはサイクル全体 |
| 良好の基準 | 100ms未満 | 200ms未満 | 基準値が異なる |
| 不良の基準 | 300ms超 | 500ms超 | 閾値も異なる |
FIDが入力遅延だけを測定するのに対し、INPは応答サイクル全体を測定するため、実際のユーザー体験をより正確に反映しているといえます。
この違いを理解することで、INP対策がFID対策よりも広い範囲の最適化を必要とすることが明確になるでしょう。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
FID改善の知識をINP対策に活かす方法
FIDからINPへの移行は、FID改善のために積み重ねてきた知識や施策が無駄になることを意味しません。
メインスレッドの負荷軽減・JavaScriptの最適化・サードパーティスクリプトの整理といった施策は、INP改善においても同様に有効であるためです。
FIDで実施した施策がINP対策に直接つながる主なポイントは以下のとおりです。
- JavaScriptの分割・遅延読み込みはINPの入力遅延フェーズにも効果がある
- Webワーカーによるメインスレッド分散はINPの全フェーズで恩恵を受けられる
- サードパーティスクリプトの整理はINPスコアの安定化に寄与する
ただし、INPはFIDが測定しなかった「処理時間」と「描画遅延」も評価するため、イベントハンドラ内の処理の簡素化や、描画コストの高いアニメーションの見直しも新たに必要になります。
FIDの知識を土台にしつつ、INP特有の測定範囲に対応する追加施策を組み合わせることが、効率的な対策の進め方となるでしょう。
関連記事：テクニカルSEOとは？優先順位の決め方と主要施策を解説｜（https://infosuccess.jp/technical-seo/）
FIDに関するよくある質問
FIDに関するよくある質問について解説します。
FIDとTBTは何が違う？
FIDはフィールドデータに基づく実ユーザーの測定値であるのに対し、TBTはLighthouseなどで計測できるラボデータです。
FIDはユーザーの実際の操作が必要なため、シミュレーション環境では直接測定できません。
TBTはFIDの代替指標として用いられ、TBTを改善することがFIDスコア向上に間接的に影響します。
PageSpeed InsightsでFIDが表示されないのはなぜ？
2024年9月のChromeによるFIDサポート終了以降、PageSpeed InsightsではFIDのフィールドデータが表示されなくなっています。
新しいコアウェブバイタル指標であるINPに切り替わっているため、現在はINPのスコアを確認・改善することが必要です。
アクセスが少ないページでは、INPを含むフィールドデータ自体が表示されない場合もあります。
Search ConsoleにFIDがまだ表示されるのはなぜ？
Search Consoleでは過去のフィールドデータがアーカイブとして残っているため、一定期間はFIDのデータが表示される場合があります。
ただし、新規データの収集はすでに停止されており、表示されている数値は過去の履歴データです。
現在進行中のコアウェブバイタル対応は、INPのスコアを指標として判断してください。
まとめ｜FIDの理解を土台にINP対策を始めよう
本記事では、FIDの基本的な仕組みと評価基準、FIDスコアを悪化させる原因と改善施策、そして2024年3月のINP移行の背景について解説しました。
FIDはすでに廃止された指標ですが、その根本にある「メインスレッドの負荷を減らしてユーザー操作への応答性を高める」という考え方は、INP対策においても変わらず重要です。
自サイトのINPスコアを確認しながら、まずJavaScriptの最適化とサードパーティスクリプトの整理から着手することが、現時点での最も実践的なアプローチとなるでしょう。
FIDで積み上げた知識を活かして、INP対策を着実に進めてください。