Google検索はSPAのソフトナビゲーションをCore Web Vitalsランキングに採用していますか？

現時点の公式CrUXフィールドデータおよび検索ランキング指標は、初回ハードナビゲーションを評価対象としています。ソフトナビゲーションは web-vitals ライブラリによる実験的計測段階にあります。

なぜクライアント側のハイドレーションはINPやLCPを悪化させるのですか？

ハイドレーション処理はブラウザのメインスレッドを占有してコンポーネントツリーの再構築とイベント登録を行うため、ユーザーのタップ操作への応答が遅延し（INP悪化）、描画要素の遅延（LCP悪化）を招きます。

ガイド

シングルページアプリ (SPA) の Core Web Vitals 診断

SPA（React、Vue、Next.js、Nuxtなど）は従来のWebサイトとは異なるパフォーマンス特性を持ちます。クライアント側での画面遷移や巨大なスクリプト群が指標に大きな影響を及ぼします。

WebAudit Lab による監修 · 更新日 2026-10-02

要約・回答

CrUXの実ユーザーデータを基盤とし、サーバーサイドレンダリング (SSR) で初回LCPを改善、長大なタスクの分割によってINP応答性を高め、コンテナ寸法を固定してCLSを防ぎます。

通常ナビゲーションとSPAソフトナビゲーションの違い

Googleの公式 Core Web Vitals（LCP、INP、CLS）は初回ドキュメント読み込み時に記録されます。SPA内でクライアント側ルーター（React Router等）による画面遷移が行われても、全体再読み込みは発生しません。web-vitals ライブラリの実験的ソフトナビゲーションAPIを活用し、画面切り替え時の応答速度を正確に計測してください。

クライアントレンダリング環境におけるLCPの改善

SPAでは主要コンテンツを表示する前に巨大なJavaScriptファイルを読み込んで実行する必要があるため、Largest Contentful Paintが悪化しがちです。SSRまたはSSGの導入を検討し、インラインクリティカルCSSを含む軽量な初期HTML（150KB未満）を配信した上で、ヒーロー画像に fetchpriority='high' を指定します。

Interaction to Next Paint (INP) の応答速度向上

INPはクリックやタップ、キー入力に対するインターフェースの機敏さを評価します。SPAではユーザーの操作によって重いコンポーネント再描画が引き起こされ、メインスレッドが停止することがあります。scheduler.yield() や requestIdleCallback() で50ms以上のタスクを分割し、高負荷処理は Web Worker へ委譲します。

ハイドレーション時の急激なレイアウトずれ (CLS) の抑制

クライアント側でのハイドレーション処理は表示崩れの主因です。サーバー出力HTMLとクライアント初期状態に不一致がある場合や、非同期で挿入される広告バナーに高さが指定されていない場合、配置が大きくズレます。動的要素には aspect-ratio や min-height を指定して描画領域をあらかじめ確保してください。

実環境 (RUM) とラボ計測を組み合わせた継続監視

単一環境でのラボテストだけでは低スペック端末やモバイル通信環境のボトルネックを捉えきれません。web-vitals ライブラリを用いたリアルユーザーモニタリング (RUM) を実装し、75パーセンタイル値を監視します。CI/CDパイプラインにパフォーマンスバジェットを導入し、意図しない肥大化を未然に防止します。

パフォーマンス: HTML配信、データ転送量、レンダリングブロック要因。

無料診断を開始 →