コアウェブバイタルのスコアは発リンクのクロールに関係する？

2026年6月追記 — Core Web Vitals（ページエクスペリエンス）の最新基準と改善

2026年6月時点の「合格基準」（Google公式）

ページエクスペリエンスの中核であるCore Web Vitalsは、3つの指標で評価されます。Googleの現行の「good（良好）」閾値は次の通りです。

評価は実ユーザーデータ（CrUX）の75パーセンタイルで行われます。訪問者の75%以上が「good」である必要があります。

⚠️ FIDは廃止された — INPへの移行（2024年3月12日）

かつて応答性の指標だったFID（First Input Delay）は、2024年3月12日にINPへ正式に置き換えられました。FIDはSearch Consoleから即削除され、他ツールでも2024年9月までに削除されています。「FID 100ms未満を目指す」という古い解説は、2026年の基準では誤りです。応答性はINP 200ms未満で見ます。

指標別の改善手順

• LCP（読み込み） — 主要画像の最適化（WebP化・適切なサイズ）、サーバー応答の高速化、重要リソースのpreload
• INP（応答性） — 長いJavaScriptタスクの分割、イベントハンドラの軽量化、不要なサードパーティスクリプトの削減
• CLS（安定性） — 画像・動画にwidth/height指定、広告枠の領域を事前予約、Webフォントのfont-display設定

「2026年にLCPが2.0秒に厳格化」説について

一部のSEOブログで「2026年にLCPの基準が2.0秒に厳格化される」「INPが主要ランキングシグナルに昇格する」といった情報が見られますが、Google公式ドキュメント（2026年2月時点）はLCPを依然2.5秒と記載しており、公式の裏付けはありません。業界の推測と公式基準は区別して扱うべきです。なお「サイトの約43%がINP 200ms閾値に未達」という統計は業界調査由来で、Google公式統計ではない点も付記します。

出典: Google Search Central「Core Web Vitals」公式ドキュメント / web.dev「INPがCore Web Vitalに（2024-03-12）」/ CrUX公式

PageSpeed InsightsとSearch Console、コアウェブバイタルはどちらで見るべきか

結論から言うと両方を役割で使い分けます。同じCore Web Vitalsを扱いますが、見えるものが違います。

実務の順序は Search Console →（不良URL群を特定）→ PageSpeed Insights（個別の直し方を調べる）です。Search Consoleは「どこが悪いか」、PageSpeed Insightsは「どう直すか」に強い、と覚えておくと迷いません。

INPを改善するJavaScriptの具体策

• 長いタスク（50ms超）を分割 — 重い処理を setTimeout や scheduler.yield() で区切り、メインスレッドを明け渡す
• サードパーティJSの遅延読み込み — チャット・広告・解析タグを defer / async や遅延ロードで後回しにする
• イベントハンドラの軽量化 — クリックや入力の処理内で重い計算を避け、requestIdleCallback に逃がす
• 不要なJSバンドルの削減・コード分割 — 初期表示に不要なスクリプトを読み込まない

PageSpeed Insights以外の計測ツール（代替・併用）

• Lighthouse（Chrome DevToolsに内蔵）— ローカルで何度でも計測
• WebPageTest — 回線・端末を細かく指定した詳細計測
• CrUX Vis — 実ユーザーデータの推移を継続モニタリング（旧CrUX Dashboard（Looker Studio版）は2025年11月末で廃止）
• Chrome UX Report API — フィールドデータをプログラムから取得

出典: Google Search Central / web.dev「Optimize INP」/ CrUX公式ドキュメント

2026年6月の最新動向 — しきい値は不変、ツールと作法が変わった

Google I/O 2026（2026年5月19日）でも新しいCore Web Vitals指標やしきい値変更の発表はありませんでした。INPはgood≦200ms / poor＞500msのまま（web.dev、2025-09-02更新で確認）。変わったのは計測ツールと改善の作法です。

• INP改善の第一推奨は await scheduler.yield() に — web.dev「Optimize long tasks」が明記。setTimeout(0)での分割は旧手法になりました。対応はChrome/Edge 129+・Firefox 142+で、Safariは未対応のため globalThis.scheduler?.yield での機能検出＋フォールバックが実務の書き方です
• isInputPending() は「もはや推奨しない」とGoogle公式が明記 — 偽陰性の問題のため。これを推奨している2024年以前の記事は要注意
• INPデバッグの主力はLoAF（Long Animation Frames API） — web-vitalsライブラリv4以降はINPのattributionにLoAFデータを自動で含めます。「どのスクリプトがINPを悪化させたか」まで特定可能に
• CrUX Dashboard（Looker Studio版）は2025年11月末で廃止 — 後継はCrUX Vis。継続モニタリングのブックマークを張り替えておきましょう
• SPAの計測に進展 — Soft Navigations APIがChrome 147から最終オリジントライアル入り。SPAの画面遷移ごとにLCP/CLS/INPを測れるようになりますが、公式CWVへの組み込みは「未決定」とGoogle自身が明言しています

実ユーザーデータの現在地も添えておきます。CrUXの最新月次統計（2026年5月分・1,840万オリジン）では、INPがgoodのサイトは86.6%、LCPは68.6%、CLSは81.3%、3指標すべてgoodは55.9%。HTTP Archiveの分析でも、いまボトルネックになりやすいのはINPよりLCPです。「INP対応で手一杯」というチームは、実はLCP（特に画像とサーバー応答）に伸びしろが残っていることが多い——これが2026年の実態です。

出典: web.dev「INP」「Optimize long tasks」/ Chrome Developers Blog「Chrome at I/O 26」「Soft navigations」（2026-05-14更新）/ CrUX Release Notes・月次統計（2026-06-09公表）/ HTTP Archive Web Almanac 2025

よくある疑問3つ — クロール・順位・関連用語

Q1. コアウェブバイタルのスコアはGooglebotのクロール頻度に影響するか？
CWVのスコア自体はクロール頻度のシグナルではありません。ただしサーバー応答が速いサイトはクロール能力の上限（クロールバジェット）が上がるとGoogleのクロールバジェット公式ドキュメントが明記しています。つまり「LCP改善のためにサーバー応答を速くする」施策は、結果としてクロール面にも好影響を与える——指標がつながっているのはこの経路です。

Q2. CWV改善で順位が上がった実例はあるか？
正直に書くと、2025〜2026年の新規大規模相関調査は存在しません（よく引用されるSistrixの+3.7%は2021年の調査）。Google公式の現行表現は「CWVはコアランキングシステムが報いようとするものと整合する」（Search Central、2025年12月更新）で、John Mueller氏は「CWVはランキングの巨大要因ではない」と繰り返し発言しています。実務感覚では「悪いと損をするが、良くしても勝てるわけではない」防御的な指標。順位目的より、直帰率・CVRなどユーザー行動の改善目的で取り組むほうが投資対効果を説明しやすいはずです。

Q3. 「発リンク」とは何か？ CWVと関係あるか？
発リンク（外部リンク）は、自サイトのページから外部サイトへ張るリンクのこと。出典明示などコンテンツの信頼性に関わるSEO要素ですが、表示性能を測るCWVとは別軸です。ただし発リンク先のウィジェットや埋め込み（SNS埋め込み・広告タグ等）を大量に読み込むとINP・LCPを悪化させるため、「リンクは張る、重い埋め込みは絞る」が両立のコツです。

出典: Google Search Central「クロールバジェット管理」「Core Web Vitals」公式ドキュメント / DebugBear「Core Web Vitals as a ranking factor」