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