SPA、Core Web Vitals、現在の測定の制限に対処するための Google の計画に関するよくある質問とその回答
2020 年 5 月に Web Vitals イニシアチブを初めて導入して以来、Chrome チームにはこのプログラムに関する多くの質問とフィードバックが寄せられています。
シングルページ アプリケーション（SPA）で Core Web Vitals を測定する方法と、SPA アーキテクチャが Core Web Vitals スコアにどのように影響するかについては、最も多くの質問が寄せられているトピックであり、おそらく最も回答が難しい質問でもあります。
問題は非常に微妙なため、これらの質問に答えるのは難しいですが、この投稿では、できるだけ詳細とコンテキストを提供しながら、よくある質問に回答できるよう努めます。
具体的な内容に入る前に、Google はサイトの構築に使用するアーキテクチャやテクノロジーに優先順位を付けていないことを明記しておきます。Google は、SPA とマルチページ アプリケーション（MPA）の両方がユーザーに高品質のエクスペリエンスを提供できると考えています。Web Vitals イニシアチブの目的は、テクノロジーに依存しないエクスペリエンスを測定する指標を提供することです。現時点では、ウェブ プラットフォームの制限により、すべてのケースでこの対応をすることはできませんが、差異を解消するための取り組みを積極的に進めています。
よくある質問
Core Web Vitals の指標には SPA ルート遷移が含まれますか？
いいえ。ウェブに関する主な指標の各指標は、現在のトップレベルのページ ナビゲーションに対して測定されます。ページが新しいコンテンツを動的に読み込んでアドレスバーのページの URL を更新しても、Core Web Vitals 指標の測定方法には影響しません。指標の値はリセットされず、各指標の測定値に関連付けられる URL は、ユーザーがページ読み込みを開始した URL です。
Core Web Vitals の指標は、SPA ルートの変更を従来のページ読み込みと同じように扱えますか？
残念ながら、現時点ではご利用いただけません。
現在、SPA を構築する標準化された方法はありません。また、一般的な SPA ライブラリやルーティング ライブラリでも、アプリによってユーザー エクスペリエンスが大きく異なる場合があります。
- 一部の SPA では、新しい「フルページ」コンテンツを読み込むときにのみ URL が更新されますが、他のサイトでは、コンテンツのわずかな変更や UI 状態の変更でさえ URL が更新されます。
- 一部の SPA は History API を使用して URL を更新しますが、古いブラウザをサポートするためにハッシュ変更を使用する SPA もあります（URL をまったく更新しない SPA もあります）。
- コンテンツを読み込んでから URL を更新する SPA もあれば、コンテンツを読み込む前に URL を更新する SPA もあります。
- 一部の SPA では、コンテンツを 1 つの JavaScript タスクで同期的に一度に読み込みますが、他の SPA では、コンテンツを複数のタスクにまたがって非同期で遷移します（明確な遷移終了イベントはありません）。
- 一部の SPA は常にネットワークからコンテンツを読み込みますが、他の SPA はすべてのコンテンツを事前にプリロードして、ルート変更をメモリから即座に読み込みます。
これらの違いにより、SPA ルートの変更、さらには SPA 自体を定義して特定することは、大規模に行うのが非常に困難です。
SPA のルート変更が論理的に MPA のページ読み込みと同じである場合もあります。そのような場合は、既存の Core Web Vitals 指標を適用できると便利です。
ただし、他のすべての URL 変更から「実際の」ルート変更を信頼性を持って識別する確固としたヒューリスティクスと、そのような遷移の開始と終了を示す明確なシグナルがなければ、このような場合に Core Web Vitals 指標を報告すると、データが不明瞭になり、有用性が低下したり、サイトの実際のユーザー エクスペリエンスを代表するものではなくなったりする可能性があります。
MPA よりも SPA の方が Core Web Vitals で高い評価を得にくいですか？
SPA アーキテクチャには、MPA の類似ページと同じくらいすばやく読み込まれ、Core Web Vitals のすべての指標で同じスコアが得られるようにする機能が備わっています。
ただし、適切に最適化された MPA には、Core Web Vitals のしきい値を満たすという点で、現在 SPA にはないいくつかの利点があります。これは、MPA アーキテクチャでは、各「ページ」が（コンテンツを動的に取得して既存のページに挿入するのではなく）フルページ ナビゲーションとして読み込まれるためです。つまり、MPA にアクセスするユーザーは、サイトから複数のページを読み込む可能性が高いため、MPA のすべてのページ読み込みの分布の大部分は、サブリソースの一部またはすべてがキャッシュに保存されることを意味します。
ただし、MPA が SPA よりも Core Web Vitals 指標で優れたパフォーマンスを発揮するには、いくつかの条件を満たす必要があります。
- 同じオリジンのページの読み込みが、75 パーセンタイルにおいてクロスオリジンのページの読み込みよりも確実に速くなるように、MPA ではサブリソース キャッシュを最適化する必要があります。
- MPA にアクセスするユーザーは、サイトがキャッシュのメリットを受け、ページの読み込みを高速化するために、複数のページにアクセスする必要があります。
Core Web Vitals の評価ではページ訪問の75 パーセンタイルが考慮されるため、データセットにパフォーマンスの高いページ訪問がより多く含まれていれば、分布の 75 パーセンタイルの訪問が推奨されるしきい値内に収まる可能性が高くなります。
ウェブに関する Core Web Vitals スコアを比較する際には、データの集計方法（分布のデータセットにサイトまたはオリジンのすべてのページが含まれているか、特定のページ URL のページ読み込みのみが含まれているか）に注意してください。
オリジン内のすべてのページのスコアを集計すると、個々の高速ページによってオリジン全体の 75 パーセンタイル値が改善される可能性があります。ただし、個々のページで集計する場合、1 ページのスコアが次のページのスコアに影響することはありません。つまり、ページごとに MPA のスコアを集計する場合、購入手続きページで高速なキャッシュ読み込みがあっても、サイトのランディング ページで発生した遅い初期読み込みのスコアは改善されません。
PageSpeed Insights または Chrome ユーザー エクスペリエンス レポート API を使用して、さまざまな集計方法でサイトのスコアを確認できます。これらのツールでは、個々のページ URL とオリジン全体の両方のスコアがレポートされます。
SPA アーキテクチャが Core Web Vitals スコアに影響するもう 1 つの方法は、ページの全期間を考慮する指標です。SPA にアクセスするユーザーは、セッション全体で同じ「ページ」にとどまる傾向があるため、時間の経過とともに蓄積される指標は、MPA よりも SPA で厳しい結果になる可能性があります。
2021 年 4 月に、この問題の一部に対処するCLS 指標の変更を発表しました。以前は、CLS はページのライフサイクル全体で累積されていましたが、現在は特定の時間枠（基本的には特定のページでのレイアウト シフトの最大バースト）でのみ累積されます。
ただし、新しい CLS の定義でも、SPA は依然として不利な立場にあります。これは、MPA でのページ全体の読み込み時のように、ルートの遷移後に CLS 値が「リセット」されないためです。また、ルート遷移後に発生するレイアウトのずれは、ずれの時点でのアドレスバーの URL ではなく、読み込み時のページの URL に関連付けられるため、混乱を招く可能性があります（詳細は下記）。
SPA アーキテクチャによってユーザー エクスペリエンスが改善された場合、その改善は指標に反映されるべきではないでしょうか？
はい、対応しています。ただし、前述のように、今日のウェブで SPA が実装されているさまざまな方法を考えると、エクスペリエンスがどれだけ改善されたかを大規模に定量化することは困難です。
実際のところ、ウェブ パフォーマンス業界（Google を含む）は、ページの読み込み自体に費やしてきた時間と労力に比べ、ページの読み込み後のパフォーマンスに関するユーザー中心の指標の開発に費やしてきた時間と労力は、はるかに少ないのが現状です。これは、読み込み後のパフォーマンスが重要ではないためではなく、読み込み後の UX とインタラクションが非常に多様で明確に定義されていないため、それらの指標を設計するのが難しいためです。
ただし、SPA のパフォーマンスを測定するための読み込み後の指標が明確に定義されている場合でも、読み込み後のエクスペリエンスが改善されたからといって、読み込みエクスペリエンスを無視することはできません。
ウェブに関する指標イニシアチブの目標の一つは、ウェブページの読み込みと使用のできるだけ多くの側面で優れたユーザー エクスペリエンスを促進し、インセンティブを与えることです。十分な良い体験で補うことができるにもかかわらず、悪い体験が正当化されるようなシナリオを奨励することはできません。ユーザーはページの読み込みが速く、新しいコンテンツに素早く移動することを望んでいます。Google は、そうしたエクスペリエンスを重視した指標を設計しようと努めました。
そのため、同じサイトの MPA バージョンが Core Web Vitals の指標の 75 パーセンタイルにおいて、同じサイトの SPA バージョンよりも優れている場合もありますが、SPA バージョンでも「良好」の基準を満たすようにする必要があります。SPA バージョンがほとんどのユーザーにとって「良好」の基準を満たしていない場合、その後のページ内ナビゲーション エクスペリエンスが優れていても、最初の読み込みエクスペリエンスは良好と見なされない可能性があります。
今後、Google は、優れた読み込み後のエクスペリエンスを促進する指標を開発する予定です。これは、最初の読み込みエクスペリエンスを損なうことなく、高品質の SPA を奨励する最善の方法であると考えています。Google はすでに、ページのライフサイクル全体でインタラクション レイテンシを測定する Interaction to Next Paint（INP）という新しい指標をリリースしています。また、SPA ルート遷移を測定する指標など、その他の読み込み後の指標にも積極的に取り組んでいます（下記を参照）。
サイトを MPA から SPA に切り替えたところ、スコアが低下しました。これは正常な動作ですか？
場合によって変わります。アーキテクチャの大幅な移行後にスコアが変化する理由はいくつかありますが、ウォーム キャッシュの読み込み数が減少すると、スコアが変化する可能性があります。
簡単に確認するには、Lighthouse でランディング ページの MPA バージョンと SPA バージョンの両方をテストします。SPA バージョンの Core Web Vitals 指標のいずれかで Lighthouse スコアが低下している場合は、更新後に読み込みエクスペリエンスが悪化した可能性があります。
Core Web Vitals のスコアを改善するために、サイトを SPA から MPA に切り替えるべきですか？
おそらく、そうではありません。SPA スタックに満足しておらず、MPA の方が優れたユーザー エクスペリエンスを提供できると判断できる場合にのみ、SPA から MPA に切り替えてください。
ウェブに関する主な指標が改善され、ブラウジング エクスペリエンス全体のより多くの部分をカバーするようになれば、優れた UX を提供する SPA を適切に構築しているチームは、ウェブに関する主な指標のスコアがそれを反映することを期待できます。
Core Web Vitals スコアが SPA のランディング ページでのみ報告される場合、ルート遷移後に「ページ」で発生する問題をデバッグするにはどうすればよいですか？
Core Web Vitals 指標のフィールド データを報告する Google ツール（Search Console や PageSpeed Insights など）は、Chrome ユーザー エクスペリエンス レポート（CrUX）からデータを取得します。CrUX では、オリジンまたはページ URL（読み込み時のページ URL）でデータが集計されます。
上記の理由により、CrUX では SPA ルートごとにデータを集計できません。ただし、独自のアーキテクチャに精通しているサイト所有者であれば、ご自身で測定することも可能です。多くの分析ツールでは、SPA ルートの変更が発生したときに通知し、測定データを適宜更新できます。
分析ツールで Web Vitals 指標を測定する際は、現在のルート URL と元のページ URL の両方を測定するようにしてください。これにより、ページのライフサイクル全体で発生する個々の問題をデバッグできるだけでなく、元のページ URL で集計して、Google ツールによる指標の測定とレポートの方法に合わせることができます。
このトピックの詳細とベスト プラクティスについては、フィールドでパフォーマンスをデバッグするをご覧ください。
MPA が SPA と比べて不当な優位性を得ないように、Google はどのような取り組みを行っていますか？
前述のとおり、適切に最適化された MPA では、キャッシュに保存されたページへのアクセスの割合が高くなるため、75 パーセンタイルにおける Core Web Vitals スコアが優れている場合があります。逆に、適切に最適化された SPA でのユーザー エクスペリエンスの実際の改善は、現在、Core Web Vitals のどの指標でも捉えられていません。
Google は、このことがウェブバイタル イニシアチブの目標と完全に一致しないインセンティブを生み出していることを認識しており、この問題を解決する方法について積極的に検討しています。現在、短期的な解決策と長期的な解決策の 2 つの解決策を検討しています。
- クロスオリジン ページと同一オリジン ページのアクセスを別々に評価します。
- SPA の測定を改善する新しい API を設計します。
クロスオリジンと同一オリジンのページ訪問を別々に評価する
現在、Core Web Vitals 指標では、すべてのページアクセスが 1 つのバケットに集約されます。新規訪問とリピーター訪問、ランディング ページと購入手続きページ、またはキャッシュ状態がパフォーマンスに影響する可能性のあるその他の集計タイプを区別しません。
SPA と MPA のパフォーマンスの違いを正規化する方法の一つは、さまざまな種類のアクセスに異なる重み付けを適用することです。推奨されるしきい値がまったく異なる場合もあります。
効果的なキャッシュの実装を評価することは間違いありませんが、サイト内の高速なナビゲーションが、ランディング ページの読み込みの遅さを補うことは望んでいません。また、指標のスコアを改善するためだけに、長いページを短いページのコレクションに分割するようサイトを誘導することも意図していません。
クロスオリジン ページ訪問と同一オリジン ページ訪問を個別に評価することで、特定のサイトにおける 1 つのタイプの相対的な人気が特定の指標の分布を歪めないようにし、両方のタイプのエクスペリエンスの重要性を保証できます。
SPA の測定を改善する新しい API を設計する
積極的に開発が進められているもう 1 つのソリューションは、新しい App History API です。これは、現在の SPA パターンを標準化し、大規模な SPA の使用状況を簡単に測定して把握できるようにするものです。
App History API には、新しい navigate イベントが導入されています。このイベントには、SPA 測定に固有の 2 つの重要な機能があります。
userInitiatedフラグ。リンクのクリック、フォームの送信、ブラウザの「戻る」または「進む」UI を介してナビゲーションが開始された場合にのみ true に設定されます。transitionWhile()メソッド。Promise を受け取り、ナビゲーションを実行するために開始した処理が完了したことをデベロッパーが通知できるようにします。
userInitiated フラグを使用すると、SPA ルート遷移のセマンティックな開始点を決定し、明確なユーザーの意図を示します。transitionWhile() プロミスの解決により、ブラウザはペイントを特定のルート遷移と関連付けることができます。これにより、その遷移に関連する Largest Contentful Paint を特定できます。
前のセクションで説明したアイデアを基に、SPA ルートの遷移時間を MPA の同一オリジンのページ読み込みと同じバケットに集約することもできます。これは、MPA から SPA に移行するサイトが、移行前後のパフォーマンスを実際に比較できるため、非常に便利です。
もちろん、これらの判断を正確に行うことができるかどうかを判断するには、さらなる調査が必要です。これらの提案についてご提案やフィードバックがある場合は、web-vitals-feedback@googlegroups.com までメールでお送りください。
最後に
Google は、Web Vitals 指標の改善に全力で取り組んでおり、ユーザーにとって重要な高品質なエクスペリエンスを測定し、インセンティブを付与しています。ただし、現在、測定に差異があることは認識しています。現在、これらの指標はユーザー エクスペリエンスのすべての側面を網羅しているわけではありませんが、Google はこれらのギャップを埋めるために積極的に取り組んでいます。
現在の制限にもかかわらず、既存の指標が捉えている領域は、ウェブの健全性と成功にとって重要であると Google は考えています。また、サイトが（アーキテクチャに関係なく）推奨しきい値を満たしていない場合、改善の余地があると考えています。
この投稿が、複雑で微妙なこの問題について理解を深める一助となれば幸いです。現在の Web Vitals 指標や今後の指標についてご意見やご感想がございましたら、web-vitals-feedback@googlegroups.com までメールでお送りください。