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