提供有關 SPA、Core Web Vitals 以及 Google 如何因應目前評估限制的常見問題解答。
自 2020 年 5 月首次推出網站體驗指標計畫以來 Chrome 小組收到許多有關 計畫。
也許我們最常收到的主題 最難回答的問題可能是： 單頁應用程式 (SPA)，以及 SPA 架構如何影響 Core Web Vitals 分數。
這些問題都很複雜，所以很難回答， 這篇文章，我們會盡可能回答最常見的問題 盡量提供詳細資訊和背景資訊
但在深入探討任何細節前 我們還是得先聲明 但無法選擇用於建構模型或技術的架構或技術 網站。我們相信 SPA 和多頁面應用程式 (MPA) 都能 讓使用者享有優質體驗，我們用意 Android Vitals 計畫旨在提供獨立評估體驗的指標 這項技術的發展雖然目前並非每一種情況都適用這項做法 (因為 這類限制)，我們也正積極努力關閉這些限制。 落差。
常見問題
Core Web Vitals 指標是否包含 SPA 路徑轉換？
不會。每項 Core Web Vitals 指標都會 頂層頁面導覽如果網頁動態載入 同時更新網址列中的網頁網址， 影響網站體驗核心指標指標的評估方式指標值不是 且與各項指標評估相關聯的網址就是使用者網址
Core Web Vitals 指標是否能比照傳統網頁載入的方式處理 SPA 路徑變更？
很抱歉，不行。目前還不會。
目前還沒有標準化的打造方式， 許多熱門 SPA 和轉送程式庫，因此使用者體驗可能大不相同 切換應用程式：
- 部分 SPA 只會在載入新的「完整頁面」時更新網址內容，而 其他網站也會針對微小的內容變更或甚至是使用者介面狀態更新網址 並輸入變更內容
- 部分 SPA 使用 History API 更新網址，其他 SPA 則使用雜湊值 不過，其他版本沒有更新 )。
- 部分 SPA 會載入內容並更新網址，其他 SPA 則會更新網址 再載入內容
- 部分 SPA 在單一 JavaScript 中，以同步方式一次載入所有內容 工作，而其他人則會在 工作 (沒有明確轉換結束事件) 的工作。
- 有些 SPA 一律會從網路載入內容，有些 SPA 則是預先載入所有內容 ，讓路徑變更立即從記憶體載入。
以便定義及識別構成 SPA 路徑的含義 或甚至 SPA 本身，也非常難以大規模進行。
在某些情況下，SPA 路徑變更與 MPA 網頁載入完全相同， 在這種情況下，如果現有的 Core Web Vitals 指標
但沒有穩固的經驗法則，無法可靠地辨識出「真實」從 出發的路線變更 這項動作也會變更網址的開頭和結尾 因此回報 Core Web Vitals 指標就不太容易 變得較不實用，或無法代表實際使用者體驗 。
Core Web Vitals 是否比 MPA 更難提供？
SPA 架構中沒有會妨礙 與所有核心指標一樣快速載入 SPA Web Vitals 指標：類似 MPA 中的類似網頁。
然而，經過適當最佳化的 MPA 在符合 Core Web 規範方面有幾項優點 SPA 目前並未實施的 Vitals 門檻。因為 MPA 之前 架構，每個「頁面」是在整頁導覽期間載入 (而非 動態擷取內容並插入現有網頁)。 表示，造訪 MPA 的使用者較有可能透過搜尋結果頁面載入多個網頁 這意味著 載入 MPA 的網頁時，會納入部分或所有子資源 快取。
授予權限，讓 MPA 在 Core Web Vitals 指標上的表現比 SPA 機構更好 以下幾件事必須符合：
- MPA 必須最佳化子資源快取，才能 同一來源頁面載入時間的實際速度，實際上比 第 75 個百分位數。
- 造訪 MPA 的使用者需造訪多個網頁，才能在網站上 以便加快網頁載入速度。
由於 Core Web Vitals 評估會將第 75 項 頁面的百分位數 造訪次數越多、成效良好的資料集造訪次數越多， 發生分佈 建議門檻
請注意，比較 Core Web Vitals 分數時，請特別留意 是資料的匯總方式，即資料分佈範圍中的資料集 包含您網站或來源的所有網頁，或只載入某個特定的網頁 網頁網址。
在匯總某個來源中所有網頁的分數時，每個快速網頁 提高來源整體的第 75 個百分位數。但如果匯總函式 則不會影響網頁的分數 下一步。換句話說，依網頁匯總 MPA 分數時，系統會快速快取 結帳頁面載入的載入速度不會改善初始緩慢的分數 在網站到達網頁上發生的載入 頁面。
您可以使用以下項目查看網站的分數，瞭解不同的匯總方法： PageSpeed Insights 或 Chrome 使用者體驗報告 API ，其中會回報個別網頁網址和整個來源的分數。
SPA 架構也會影響網站體驗核心指標分數 會將網頁完整效期納入考量使用者造訪 SPA 往往會停留在同一個「頁面」在整個工作階段中 長期下來可能會比 MPA 更嚴厲。
我們在 2021 年 4 月宣布的CLS 指標相關異動， 部分已解決這項問題過去的 CLS 會累計 整個網頁效期，但現在累計時間只到 通常是特定頁面版面配置位移的最差的部分。
然而，即使採用新的 CLS 定義，SPA 仍會處於劣勢 因為 CLS 值並未「reset」但類似情況經過路徑轉換 而且 MPA 會載入整頁內容這也會造成混淆 轉換之後發生的變動將歸因於 而不是移位時的網址列 (瞭解詳情 。
如果 SPA 架構改善了使用者體驗，指標中不應出現改善嗎？
是，應該。但如前所述 必須大規模改善的使用體驗 現今網路上的垃圾內容實施方式
事實上，網站成效產業 (由 Google 加入) 一直以來都沒有 投入相當多的時間和心力，開發以使用者為中心的策略 查看載入後成效指標 與網頁載入的實際結果相同這並不是因為載入後 不重要，因為載入後的使用者體驗和互動 但定義較明確，因此難以設計 具體做法是指示 Kubernetes 建立並維護 一或多個代表這些 Pod 的物件
但即使我們妥善定義載入後指標來評估 SPA 系統 我們不會忽略載入體驗 成效提升時
Web Vitals 計畫的目標之一是促進及鼓勵良好 從載入和存取網頁 我們不希望鼓勵有負面體驗的情況 如果你能有足夠體驗來創造新生活，才是明智的決定。位使用者 希望網頁能快速載入，同時轉換至新的內容，我們也試著 打造更適合這些體驗的指標。
因此，雖然網站的 MPA 版本在 Core Web 上的表現可能比較好 與完全相同的 SPA 版本相比，第 75 個百分位數的 Vitals 指標 SPA 版本仍應努力達到「良好」門檻。如果 SPA 版本不符合「良好」狀態對多數使用者來說 即使之後的 網頁內導覽體驗非常棒
我們希望日後會開發能在載入後產生良好成效的指標 同時也認為這是鼓勵 以不影響初始載入體驗的方式使用 SPA。我們 已採用名為「與下一個顯示內容互動 (INP)」的新指標，評估整個網頁生命週期的互動延遲時間；我們正積極著手改善其他 載入後指標，包括測量 SPA 路徑轉換的指標 (請見下文)。
我們把網站從 MPA 改成了 SPA 系統，分數也大幅降低。這是正常現象嗎？
視情況而定。分數有可能在 遷移主要架構，但暖快取負載數量減少 部分變更都必須納入考量
如要快速加以確認，您可以同時測試兩個版本的 MPA 和 SPA 版本 到達網頁 Lighthouse。如果 針對 SPA 中心的「Core Web Vitals」指標，Lighthouse 分數較低 版本那麼在載入網頁後 更新。
為了提升網站體驗核心指標的分數，我應該將網站從 SPA 切換至 MPA 嗎？
別緊張。如果不滿意，才應該從 SPA 改用 MPA 因此，您相信 MPA 能 使用者體驗
隨著 Core Web Vitals 指標持續改善，且涵蓋更多 此外，如果團隊為了提供優質使用者體驗而建構完善的 SPA 系統 應該會看到 Core Web Vitals 的分數
如果只記錄 SPA 到達網頁的 Core Web Vitals 分數，該如何為「網頁」上發生的問題偵錯如何判斷？
回報 Core Web Vitals 指標 (例如 Google 搜尋) 的欄位資料 控制台和 PageSpeed Insights) 從 Chrome 使用者體驗 檢舉 (CrUX)。而且 CrUX 會按來源或網頁網址 (也就是 載入時的網頁網址)。
基於上述所有原因，CrUX 無法依據 SPA 路徑。不過，身為網站擁有者，已經熟悉您的架構 可以自行評估，許多分析工具 在 SPA 路徑發生變更時傳送訊號，並更新你的測量結果 做為參考依據
使用分析工具評估網站體驗指標時，務必 評估目前路徑網址以及原始網頁的網址這將 可讓您針對整個網頁上發生的個別問題進行偵錯 以及按原始網頁網址彙整的資料，以配合 Google 評估指標並建立相關報表
如需詳細資訊和最佳做法，請參閱：偵錯 欄位。
Google 會採取哪些做法確保 MPA 遠高於 SPA 系統的不公平優勢？
如前所述，經過適當最佳化的 MPA 在某些情況下可以 事實上，網站體驗指標的分數是第 75 個百分位數 快取網頁造訪次數的比例較高相反地 目前未擷取適當最佳化 SPA 中的使用者體驗 任何網站體驗核心指標的表現
Google 我們瞭解，這會產生無法完全一致的獎勵 希望透過這項計劃達成這個目標，而我們目前正積極尋求解決之道 才能解決這個問題目前我們正在尋找兩種可能的解決方案， 以及另一個較長的字詞：
- 分別評估跨來源與同源網頁造訪次數。
- 設計新的 API，改善 SPA 評估品質。
分別評估跨來源與同源網頁造訪次數
Core Web Vitals 指標目前會將所有網頁造訪次數匯總為單一 - 不會區分新訪客與回訪者或到達網頁 網頁、結帳頁面或任何其他匯總類型 (快取狀態) 都可能會影響效能
要標準化 SPA 和 MPA 成效差異的其中一種方式，就是 對不同類型的造訪套用不同權重，即使 完全不同的門檻 最佳化建議。
雖然我們一定會想獎勵有效的快取實作，但我們不會 希望能快速完成站內瀏覽，彌補到達網頁速度緩慢的問題 載入。我們也不想誘導網站將較長的網頁 以便提高指標分數。
分別評估不同來源和相同來源網頁的造訪情形，我們可以提供協助 確保這兩種體驗都很重要，避免使用相對 任一類網站的熱門程度，與任何網站的分佈狀況出現偏差 指標。
設計新的 API 來提升 SPA 測量品質
另一項正積極開發的解決方案 (與上述做法平行) 為 新的 App History API 可協助您將最新版本的 SPA 模式，方便我們大規模評估及瞭解 SPA 用量。
App History API 推出了
navigate 事件，需要用到
有兩個與 SPA 評估相關的主要功能：
- A 罩杯
userInitiated敬上 旗標，只有在使用透過 開啟導覽功能時，才會設為 true 這個連結、點選表單提交頁面 或瀏覽器的返回/轉寄使用者介面 - A 罩杯
transitionWhile()敬上 方法，以承諾讓開發人員在作業期間 啟動的導覽程序已經完成。
userInitiated 旗標可用來決定
SPA 路徑轉換，表明使用者意圖。transitionWhile()
承諾解析有助於瀏覽器將繪製內容與特定路線建立關聯
以便判斷模型在最大型的
與轉換相關
結合上一節提到的想法，甚至可以 可以將 SPA 路徑的轉場時間匯總至同一個值區 相同來源的頁面會在 MPA 中載入。這很令人興奮，因為這能讓網站 從 MPA 遷移至 SPA，然後實際比較 。
當然，我們需要進行更多研究，才能確定我們是否 做出決定如果你對這類型的內容有任何建議或意見 提案，請透過電子郵件 web-vitals-feedback@googlegroups.com。
結論
Google 致力於改善網站體驗指標， 評估並鼓勵消費者提供至關重要的優質體驗， 使用者。儘管如此，我們確實瞭解評估作業目前仍有缺口， 目前並未涵蓋所有使用者體驗指標， 設法消弭這些落差。
儘管目前的限制有限，我們仍認為現有指標確實能改善 是影響網路健康狀態與成功的關鍵， 任何架構都未達建議的門檻 仍有進步的空間
希望這篇文章有助於瞭解這個複雜又複雜的主題。 一如既往，如果您對目前或未來的 Web Vitals 指標有任何意見， 請寄電子郵件 web-vitals-feedback@googlegroups.com。