SPA、Core Web Vitals、Core Web Vitals による SPA の処理方法に関するよくある質問とその回答
公開日: 2021 年 9 月 14 日、最終更新日: 2026 年 8 月 11 日
2020 年 5 月に ウェブに関する指標 イニシアティブを初めて発表して以来、Chrome チームにはこのプログラムについて多くの質問やフィードバックが寄せられています。
おそらく最も多く寄せられた質問は、回答が難しいものでもありますが、 シングルページ アプリケーション （SPA）で Core Web Vitals を測定する方法と、SPA アーキテクチャが Core Web Vitals のスコアに与える影響についてです。
この質問に答えるのが難しいのは、問題が非常に複雑であるためです。この記事では、よくある質問にできる限り詳細かつ具体的な回答を提供します。
具体的な内容に入る前に、Google はサイトの構築に使用されるアーキテクチャやテクノロジーを特に推奨していないことを明記しておく必要があります。Google は、SPA とマルチページ アプリケーション（MPA）のどちらもユーザーに高品質のエクスペリエンスを提供できると考えています。Web Vitals イニシアティブの目的は、テクノロジーに依存しないエクスペリエンスを測定する指標を提供することです。
よくある質問
このトピックについてよく寄せられる質問を以下に示します。フィードバック グループまたは Issue を作成して、この FAQ に追加するフィードバックをお寄せください。
Core Web Vitals の指標には SPA のルート遷移が含まれますか？
導入当初、Core Web Vitals の各指標は、現在の最上位ページのナビゲーションを基準に測定されていました。ページで新しいコンテンツが動的に読み込まれ、アドレスバーのページの URL が更新されても、Core Web Vitals の指標の測定方法には影響しませんでした。
指標の値はリセットされず、各指標の測定に関連付けられた URL は、ユーザーが移動してページの読み込みを開始した URL です。
Chrome 151 では、SPA のルート遷移全体で Core Web Vitals を測定できる新しい API が導入されました。この記事の執筆時点（2026 年 8 月）では、これらの API は、web-vitals などの測定ライブラリ、RUM ソリューション、Chrome DevTools などのツールで使い始められています。Chrome は、これらの API を Chrome ユーザー エクスペリエンス レポート（CrUX） に統合する時期をまだ公開していません。また、他のブラウザ エンジンはこれらの新しい API をまだサポートしていないため、これらのブラウザでは Core Web Vitals はページ全体の読み込みでのみ測定できます。
この問題を解決するのが難しかったのはなぜですか？
現在、SPA を構築する標準的な方法はありません。人気の高い SPA ライブラリやルーティング ライブラリでも、アプリによってユーザー エクスペリエンスが大きく異なる場合があります。
- 一部の SPA では、新しい「ページ全体」のコンテンツを読み込むときにのみ URL が更新されますが、他のサイトでは、わずかなコンテンツの変更や UI の状態の変更だけでも URL が更新されます。
- 一部の SPA では History API を使用して URL を更新しますが、古いブラウザをサポートするためにハッシュの変更を使用する SPA もあります（URL をまったく更新しない SPA もあります）。
- 一部の SPA では、コンテンツを読み込んでから URL を更新しますが、コンテンツを読み込む前に URL を更新する SPA もあります。
- 一部の SPA では、1 つの JavaScript タスクでコンテンツをすべて同期的に読み込みますが、複数のタスクにわたって非同期的にコンテンツを遷移させる SPA もあります（遷移終了イベントが明確ではありません）。
- 一部の SPA では常にネットワークからコンテンツを読み込みますが、他の SPA ではすべてのコンテンツを事前に読み込んで、ルートの変更をメモリから即座に読み込めるようにします。
これらの違いにより、SPA のルート変更、さらには SPA 自体を定義して識別することが非常に難しくなります。
SPA のルート変更が MPA のページ読み込みと論理的に同じである場合、既存の Core Web Vitals の指標を適用できると便利です。
ただし、他のすべての URL 変更から「実際の」ルート変更を確実に識別するための確固たるヒューリスティックがない場合や、このような遷移の開始と終了を示す明確なシグナルがない場合、これらのケースで Core Web Vitals の指標を報告すると、データが不明確になり、サイトの実際のユーザー エクスペリエンスを正確に表すことができなくなります。
ソフト ナビゲーションの作業では、次の 2 つの新しいパフォーマンス API を使用してこの問題を解決しました。
PerformanceSoftNavigationは、ユーザー インタラクションによってペイントと URL の両方が変更されたタイミングを測定します。これらの 3 つの要素を組み合わせることで、使用するフレームワークや前述の違いに関係なく、「ソフト ナビゲーション」の標準的な定義が提供されます。これにより、パフォーマンス タイムラインを個別の「ナビゲーション」に分割し、各ナビゲーションの CLS と INP を測定できます。InteractionContentfulPaintは、操作後の「コンテンツフル ペイント」を測定し、これらのソフト ナビゲーションの FCP と LCP を測定できるようにします。
これらの 2 つの API を組み合わせることで、ページ全体の読み込みとソフト ナビゲーションの両方で Core Web Vitals を測定できます。
SPA のルート変更は、Core Web Vitals のページ全体の読み込みと同じですか？
いいえ。これらのナビゲーション タイプにはまだ多くの違いがあり、Core Web Vitals の指標が異なる場合があります。
ソフト ナビゲーションでは、ページにコンテンツがあり、そのコンテンツの一部またはすべてを更新して新しい「ページ」を表示します。これは、キャッシュされていないページ全体の読み込みと、ページリソースの一部またはすべてがキャッシュされている場合のページ読み込みの違いに似ていますが、一部のコンテンツがレンダリングされたままになるため、さらに極端な状態になります。
理論的には、主な違いはソフト ナビゲーションがはるかに高速になる可能性があることです。ただし、他にも微妙な違いがあります。
新しいソフト ナビゲーション API は新しいコンテンツのみを考慮します。<h1> とテキスト コンテンツを更新するページでも、ページ間で同じヒーロー画像が残っている場合、再ペイントされなければ、ヒーロー画像は LCP の候補とは見なされません。これにより、同じページがページ読み込みとして読み込まれるか、別の既存のページからのソフト ナビゲーションとして読み込まれるかによって、LCP 時間の計算に使用される要素が異なります。
同様に、サイトの実行に必要な JavaScript の多くがすでに読み込まれているため、ソフト ナビゲーションでは INP が少なくなる可能性があります。同様に、同じコンテンツがページ全体の読み込みで CLS を引き起こすが、ソフト ナビゲーションで読み込みや再レンダリングを行う必要がない場合、ソフト ナビゲーションの CLS が少なくなる（または多くなる）可能性があります。
また、ページ全体の読み込み（ナビゲーション操作の処理後から測定）とソフト ナビゲーション（操作の開始時刻から測定）で、測定が行われるタイミングに若干の違いがあります。
前述のように、これらの違いの多くは、キャッシュされていないページとキャッシュされているページの違いに似ており、Core Web Vitals が測定しようとしている概念は依然として適用されます。ただし、Core Web Vitals の問題を調査する際は、これらの微妙な違いを理解しておくことが重要です。
SPA は MPA よりも Core Web Vitals で高いスコアを獲得するのが難しいですか？
SPA アーキテクチャには、SPA のページが MPA の同様のページと同じくらい速く読み込まれ、Core Web Vitals のすべての指標で同じくらい高いスコアを獲得することを妨げる固有の要素はありません。
ただし、適切に最適化された MPA には、SPA にはない Core Web Vitals のしきい値を満たす上でいくつかの利点があります。これは、前述のソフト ナビゲーションの作業でほぼ解消されましたが、これらの新しい API がまだ使用されていない場合は、依然として当てはまる可能性があります。 その理由は、MPA アーキテクチャでは、各「ページ」がページ全体のナビゲーションとして読み込まれるため（コンテンツを動的に取得して既存のページに挿入するのではなく）、MPA にアクセスするユーザーはサイトから複数のページを読み込む可能性が高くなります。つまり、MPA のすべてのページ読み込みの分布の大部分で、一部またはすべてのサブリソースがキャッシュされます。
ただし、MPA が SPA よりも Core Web Vitals の指標で優れたパフォーマンスを発揮するには、次の条件を満たす必要があります。
- MPA では、同一オリジンのページ読み込みが 75 パーセンタイルでクロスオリジンのページ読み込みよりも高速になるように、サブリソース キャッシュを最適化する必要があります。
- サイトがページ読み込みの高速化につながるキャッシュのメリットを得るには、MPA にアクセスするユーザーが複数のページにアクセスする必要があります。
Core Web Vitals のテストでは、ページ訪問の 75 パーセンタイルが考慮されるため、データセット内のパフォーマンスの高いページ訪問が多いほど、分布の 75 パーセンタイルの訪問が推奨しきい値内になる可能性が高くなります。
Core Web Vitals のスコアを比較する際に考慮すべき重要な点は、データの集計方法です。つまり、分布のデータセットにサイトまたはオリジンのすべてのページが含まれているか、特定のページ URL のページ読み込みのみが含まれているかです。
オリジン内のすべてのページのスコアを集計すると、個々の高速ページによってオリジン全体の 75 パーセンタイルが改善される可能性があります。ただし、個々のページで集計する場合、1 ページのスコアは次のページのスコアに影響しません。つまり、MPA のスコアをページごとに集計する場合、購入手続きページで高速なキャッシュ 読み込みが行われても、サイトのランディング ページで発生する初期 読み込みの遅延のスコアは改善されません。
PageSpeed Insights または Chrome ユーザー エクスペリエンス レポート API を使用して、さまざまな集計方法でのサイトのスコアを確認できます。 この API は、個々のページ URL とオリジン全体のスコアを報告します。
SPA アーキテクチャが Core Web Vitals のスコアに影響するもう 1 つの方法は、ページのライフサイクル全体を考慮する指標です。SPA にアクセスするユーザーはセッション全体で同じ「ページ」に滞在する傾向があるため、時間の経過とともに累積される指標は、MPA よりも SPA で厳しくなる可能性があります。
ソフト ナビゲーションの作業により、Core Web Vitals の測定方法に関して SPA にデメリットはないと考えています。ただし、すべてのツールとレポート ソリューションでこれらの API を完全に統合するには時間がかかります。
SPA アーキテクチャでユーザー エクスペリエンスが向上する場合、その改善は指標に反映されるべきではないですか？
はい、反映されるべきです。現在、ウェブで SPA が実装されている方法はさまざまであるため、エクスペリエンスがどの程度改善されたかを大規模に定量化することは困難でした。測定の問題に対する解決策が用意されました。これらの新しい API を使用すると、SPA への移行による改善が指標に反映されます。
実際、ウェブ パフォーマンス業界（Google を含む）は、ページの読み込み自体よりも、ページの読み込み後のパフォーマンスに関するユーザー中心の 指標の開発に、これまで十分な時間と労力を費やしてきませんでした。これは、読み込み後のパフォーマンスが重要ではないためではなく、読み込み後の UX とインタラクションが非常に多様で、明確に定義されていないため、指標を設計するのが難しいためです。
SPA のパフォーマンスを測定するための読み込み後の指標が増えたとしても、読み込み後のエクスペリエンスが向上したからといって、読み込みエクスペリエンスを無視することはできません。
ウェブに関する指標イニシアティブの目標の一つは、ウェブページの読み込みと使用のさまざまな側面で優れたユーザー エクスペリエンスを促進し、インセンティブを提供することです。十分な優れたエクスペリエンスで補えるからといって、悪いエクスペリエンスを正当化するようなシナリオは推奨しません。ユーザーはページが速く読み込まれ、新しいコンテンツに速く遷移することを望んでいます。Google は、このようなエクスペリエンスを重視する指標を設計しようとしてきました。
サイトを MPA から SPA に切り替えたところ、スコアが低下しました。これは想定されることですか？
場合によって変わります。アーキテクチャを大幅に移行した後にスコアが変化する理由はいくつかありますが、ウォーム キャッシュの読み込み回数の減少が変化の一因となる可能性があります。
簡単に確認するには、ランディング ページの MPA バージョンと SPA バージョンの両方を Lighthouse でテストします。SPA バージョンの Core Web Vitals の指標で Lighthouse のスコアが低い場合は、更新後に読み込みエクスペリエンスが悪化した可能性があります。
Core Web Vitals で高いスコアを獲得するために、サイトを SPA から MPA に切り替えるべきですか？
おそらく、そうではありません。SPA スタックに満足しておらず、MPA の方が優れたユーザー エクスペリエンスを提供できると考える理由がある場合にのみ、SPA から MPA に切り替える必要があります。
ソフト ナビゲーションの作業により、測定の問題は解決されたと考えているため、その理由だけで移行するのは意味がありません。
ただし、測定値が改善されるだけでなく、パフォーマンスが向上することを証明する理由がある場合は、SPA から MPA への移行（またはその逆）を検討する理由になる可能性があります。
Core Web Vitals のスコアが SPA のランディング ページに対してのみ報告される場合、ルート遷移後の「ページ」で発生する問題をデバッグするにはどうすればよいですか？
Core Web Vitals の指標のフィールド データを報告する Google ツール（Search Console や PageSpeed Insights など）は、Chrome ユーザー エクスペリエンス レポート （CrUX）からデータを取得します。CrUX は、オリジンまたはページ URL（読み込み時のページ URL）でデータを集計します。
CrUX が集計データに SPA ルート別のデータを含められるように取り組んでいます。 ただし、サイト所有者は、新しい API を使用して、SPA ルート別に Core Web Vitals を事前に測定し、スコアがどのように変化するかを把握できます。
詳細とベスト プラクティスについては、ソフト ナビゲーションの測定をご覧ください。
MPA が SPA よりも不当に有利にならないように、Google はどのような対策を講じていますか？
前述のように、ソフト ナビゲーションの作業により、この点に関して SPA にデメリットはないと考えていますが、すべてのツールとレポート ソリューションで完全に統合するには時間がかかります。
クロスオリジンと同一オリジンのページ訪問を個別に評価する
現在、Core Web Vitals の指標はすべてのページ訪問を 1 つのバケットに集計します。新しい訪問とリピーターの訪問、ランディング ページと購入手続きページなど、キャッシュの状態がパフォーマンスに影響する可能性のある集計タイプを区別しません。
SPA と MPA のパフォーマンスの違いを正規化する方法の一つは、 訪問タイプごとに異なる重みを適用することです。場合によっては、 完全に異なる しきい値 の推奨事項を適用することもできます。
効果的なキャッシュ実装には報酬を与えたいと考えていますが、サイト内の高速なナビゲーションでランディング ページの読み込みの遅さを隠すことは望んでいません。また、指標スコアを向上させるためだけに、長いページを短いページの集まりに分割するようサイトにインセンティブを与えることも望んでいません。
クロスオリジンと同一オリジンのページ訪問を個別に評価することで、特定のサイトでの一方のタイプの相対的な人気によって、特定の指標の分布が偏ることなく、両方のタイプのエクスペリエンスが重要であることを保証できます。
最後に
Google は、ウェブに関する指標を改善し、ユーザーにとって重要な高品質のエクスペリエンスを測定してインセンティブを提供することに深くコミットしています。ただし、現時点では測定にギャップがあることを認識しています。指標で SPA のルート遷移をカバーできるようになり、主なギャップの一つが解消されました。
また、これらの新しい API（特に InteractionContentfulPaint）には、ソフト ナビゲーションの Core Web Vitals の測定以外にも用途とメリットがあると考えています。導入の主な理由が解決されたため、今後もこれらの API を活用していくことを楽しみにしています。
この記事が、この複雑で微妙なトピックを理解する一助となれば幸いです。 現在または今後の Web Vitals の指標についてフィードバックがある場合は、 web-vitals-feedback@googlegroups.com まで メールでお送りください。