針對 SPA、網站體驗核心指標和 Google 解決目前評估限制的計畫，提供常見問題解答。
自 2020 年 5 月首次推出 Web Vitals 計畫以來，Chrome 團隊收到了許多關於這項計畫的寶貴問題和意見回饋。
我們收到最多問題的話題，也是最難回答的問題，可能是如何在單頁應用程式 (SPA) 中評估 Core Web Vitals，以及 SPA 架構如何影響 Core Web Vitals 分數。
這些問題很難回答，因為問題相當複雜，因此我們會在本文中盡力回答最常見的問題，並盡可能提供詳細資訊和背景資訊。
不過，在深入探討具體內容之前，我們必須強調，Google 並未偏好使用哪種架構或技術建構網站。我們認為 SPA 和多頁面應用程式 (MPA) 都能為使用者提供優質體驗，而 Web Vitals 計畫的用意在於提供指標，讓您能不受技術限制地評估使用者體驗。雖然目前無法在所有情況下實現這項功能 (因為網頁平台有限制)，但我們積極致力於縮小差距。
常見問題
Core Web Vitals 指標是否包含 SPA 路徑轉換？
否。每個 Core Web Vitals 指標都是相對於目前的頂層網頁導覽來評估。如果網頁會動態載入新內容，並更新位址列中的網頁網址，這對 Core Web Vitals 指標的評估方式不會有任何影響。系統不會重設指標值，且與每項指標評估相關聯的網址，就是使用者導向啟動網頁載入的網址。
Core Web Vitals 指標是否會將 SPA 路徑變更視為傳統網頁載入？
很抱歉，目前還沒有。
目前沒有標準的 SPA 建構方式，即使是常見的 SPA 和路徑程式庫，使用者體驗也可能因應用程式而異：
- 有些 SPA 只會在載入新的「完整網頁」內容時更新網址，而其他網站則會在內容有微小變更，甚至只是 UI 狀態有變更時更新網址。
- 有些 SPA 會使用 History API 更新網址，其他 SPA 則會使用雜湊變更來支援舊版瀏覽器 (其他 SPA 則完全不會更新網址)。
- 有些 SPA 會先載入內容，然後更新網址，有些則會在載入內容前更新網址。
- 有些 SPA 會在單一 JavaScript 工作中同步載入所有內容，而其他 SPA 則會在多個工作中以非同步方式轉換內容 (且沒有明確的轉換結束事件)。
- 有些 SPA 一律會從網路載入內容，其他則會預先載入所有內容，讓路徑變更能立即從記憶體載入。
由於這些差異，因此很難大規模定義及識別 SPA 路徑變更，甚至是 SPA 本身。
在某些情況下，SPA 路徑變更在邏輯上與 MPA 頁面載入相同，在這種情況下，如果可以套用現有的 Core Web Vitals 指標，那就太好了。
不過，如果沒有可靠的推論法，無法可靠地從所有其他網址變更中識別「實際」路線變更，以及標示這類轉換開始和結束的明確信號，在這些情況下回報網站體驗核心指標就會導致資料混淆，使其無法有效代表網站上的實際使用者體驗。
SPA 是否比 MPA 更難達到 Core Web Vitals 的良好表現？
SPA 架構中沒有任何內在因素會導致 SPA 中的網頁無法以與 MPA 中類似網頁相同的速度載入，並在所有網站體驗核心指標指標上獲得相同的分數。
不過，經過妥善最佳化的 MPA 在滿足 Core Web Vitals 門檻方面確實有一定優勢，而 SPA 目前則不具備這項優勢。這是因為在 MPA 架構中，每個「網頁」都會以全頁導覽的方式載入 (而非動態擷取內容並插入現有網頁)，這表示造訪 MPA 的使用者較有可能從網站載入多個網頁，進而表示 MPA 的所有網頁載入作業中，有較高比例會涉及部分或所有子資源的快取作業。
不過，要讓 MPA 在 Core Web Vitals 指標方面勝過 SPA，必須符合以下幾點：
- MPA 需要最佳化子資源快取功能，確保在 75 百分位數時，同源網頁的載入速度確實比跨來源網頁快。
- 使用者必須造訪多個 MPA 頁面，網站才能享有快取的好處，進而加快網頁載入速度。
由於 Core Web Vitals 評估會考量網頁造訪次數的第 75 百分位數，因此資料集中網頁造訪次數的數量越多，成效越佳，第 75 百分位數的造訪次數就越有可能落在建議的門檻內。
請注意，比較 Core Web Vitals 分數時，請務必考量資料的匯總方式，也就是分布資料中是否包含網站或來源的所有網頁，或是僅包含特定網頁網址的網頁載入作業。
當匯總來源中所有網頁的分數時，個別快速網頁可改善來源的整體第 75 百分位數。不過，如果是依個別網頁匯總，一個網頁的得分不會影響下一個網頁的得分。換句話說，當您依頁面匯總 MPA 分數時，結帳頁面快速快取載入的速度不會改善網站到達網頁的初始載入速度分數。
您可以使用 PageSpeed Insights 或 Chrome 使用者體驗報告 API，查看網站在不同匯總方法下的分數。這兩種方法都會針對個別網頁網址和整個來源回報分數。
SPA 架構會影響網站體驗核心指標分數的另一種方式，是透過考量網頁完整生命週期的指標。由於造訪 SPA 的使用者在整個工作階段中通常會停留在同一個「頁面」上，因此與 MPA 相比，SPA 的累積指標可能會更嚴苛。
我們在 2021 年 4 月宣布CLS 指標的異動，部分解決了這個問題。先前 CLS 會在整個網頁生命週期累積，但現在只會在特定時間範圍內累積，也就是特定網頁上最嚴重的版面配置位移爆發情形。
不過，即使採用新的 CLS 定義，SPA 仍處於劣勢，因為 CLS 值在路徑轉換後不會「重設」，而 MPA 中的整頁載入則會。這也可能導致混淆，因為路徑轉換後發生的版面配置變更會歸因於網頁載入時的網址，而不是變更時位址列中的網址 (詳情請見下文)。
如果 SPA 架構可改善使用者體驗，那麼指標不應該反映這項改善嗎？
是的，不過，如先前所述，由於目前網站上實作 SPA 的方式各不相同，因此很難量化體驗的改善幅度。
事實上，網頁效能產業 (包括 Google) 過去在開發以使用者為中心的指標時，並未投入與網頁載入本身同等的時間和心力，以評估網頁載入後的效能。這並非因為負載後效能不重要，而是因為負載後的使用者體驗和互動變化多端且不易定義，因此很難為其設計指標。
不過，即使我們已明確定義後載入指標來評估 SPA 效能，也不應因為後載入體驗改善而忽略載入體驗。
Web Vitals 計畫的其中一個目標，就是盡可能在載入和使用網頁的各個層面中，促進並鼓勵提供良好的使用者體驗。我們不希望鼓勵使用者在有足夠良好體驗彌補不佳體驗的情況下，仍認為不佳體驗是合理的。使用者希望網頁能快速載入，並快速轉換至新內容，我們也嘗試設計出有利於這類體驗的指標。
因此，雖然 MPA 版本的網站在 Core Web Vitals 指標的 75 百分位數上，確實比同網站的 SPA 版本表現得更好，但 SPA 版本仍應盡力達到「良好」門檻。如果 SPA 版本未達到大多數使用者的「良好」門檻，那麼即使後續的網頁內導覽體驗非常出色，初始載入體驗仍可能不會被視為良好。
我們預計在未來開發指標，鼓勵開發人員提供優質的載入後體驗。我們認為，這是在不影響初始載入體驗的情況下，鼓勵開發人員打造高品質 SPA 的最佳方式。我們已推出名為「Interaction to Next Paint (INP)」的新指標，可評估整個網頁生命週期中的互動延遲時間。我們也積極致力於其他的後載入指標，包括評估 SPA 路徑轉換的指標 (請參閱下方)。
我們將網站從 MPA 改為 SPA，但分數卻下滑。這是正常的嗎？
視情況而定。在重大架構遷移後，分數可能會因多種原因而有所變動，但溫快取載入次數減少可能會導致部分變化。
如要快速確認，可以使用 Lighthouse 測試其中一個到達網頁的 MPA 和 SPA 版本。如果 SPA 版本的 Core Web Vitals 指標中，任何一項 Lighthouse 分數較低，則更新後的載入體驗可能確實變差。
我是否應將網站從 SPA 改為 MPA，以便在 Core Web Vitals 中獲得更高的分數？
別緊張。只有在您不滿意 SPA 程式堆疊，且有理由相信 MPA 可提供更好的使用者體驗時，才應從 SPA 切換為 MPA。
隨著 Core Web Vitals 指標持續改善，並涵蓋更多完整的瀏覽體驗，如果團隊已建構出可提供出色使用者體驗的 SPA，Core Web Vitals 分數應該也會反映這一點。
如果 Core Web Vitals 分數只針對 SPA 的到達網頁回報，如何偵錯路徑轉換後「網頁」發生的問題？
回報 Core Web Vitals 指標現場資料的 Google 工具 (例如 Search Console 和 PageSpeed Insights)，會從 Chrome 使用者體驗報告 (CrUX) 取得資料。CrUX 會依據來源或網頁網址 (也就是載入時的網頁網址) 匯總資料。
基於上述所有原因，CrUX 無法依據 SPA 路徑匯總資料。不過，身為熟悉自家架構的網站擁有者，您可以自行評估這項指標，許多分析工具也能讓您在 SPA 路徑發生變更時發出信號，並據此更新評估資料。
使用數據分析工具評估 Web Vitals 指標時，請務必同時評估目前路徑網址和原始網頁網址。這樣一來，您就能針對整個網頁生命週期中發生的個別問題進行偵錯，並依原始網頁網址匯總資料，以便與 Google 工具評估及回報指標的方式相符。
如需進一步瞭解這個主題的詳細資訊和最佳做法，請參閱「在實地偵錯效能」。
Google 採取哪些措施，確保 MPA 不會比 SPA 享有不公平的優勢？
如上所述，在某些情況下，經過適當最佳化的 MPA 可能會回報較佳的 Web Vitals 分數 (位於第 75 百分位數)，因為該網站的快取網頁造訪百分比可能較高。相反地，在經過適當最佳化的 SPA 中，Core Web Vitals 指標目前無法擷取使用者體驗的實際改善情形。
Google 瞭解這會造成不完全符合 Web Vitals 計畫目標的誘因，因此我們正積極尋找解決方法。我們目前正在研究兩種潛在解決方案，一個是短期解決方案，另一個是長期解決方案：
- 分別評估跨來源和同源網頁造訪
- 設計新的 API，以便更妥善地評估 SPA。
分別評估跨來源和同來源的網頁造訪
目前，網站使用體驗核心指標會將所有網頁瀏覽次數匯總為單一分類，不會區分新訪客和回訪者、到達網頁和結帳頁面，或任何快取狀態可能會影響效能的匯總類型。
如要將 SPA 和 MPA 成效差異標準化，一種方法是為不同類型的造訪套用不同的權重，甚至可以採用完全不同的建議門檻值。
雖然我們確實希望獎勵有效的快取導入，但我們不希望快速的網站內導覽功能能夠掩蓋載入速度緩慢的到達網頁。我們也不希望網站為了提升指標分數，就將長篇文章分割成多篇較短的文章。
透過分別評估跨網域和同網域網頁的造訪次數，我們可以確保這兩種體驗都很重要，且不會因為某個網站上某種體驗的相對人氣，而使任何特定指標的分配出現偏差。
設計新的 API，以便更有效地評估 SPA
另一個正在積極開發的解決方案 (與上述解決方案並行) 是新的 App History API，可協助標準化目前的 SPA 模式，讓您更輕鬆地評估及瞭解 SPA 的大規模使用情形。
應用程式記錄 API 推出了新的 navigate 事件，其中包含兩項專屬於 SPA 評估的關鍵功能：
userInitiated標記，只有在透過連結點擊、表單提交或瀏覽器的返回或前進 UI 啟動導覽時，才會設為 true。transitionWhile()方法會採用 promise，讓開發人員能夠在他們啟動執行導覽作業時發出信號。
userInitiated 旗標可用於判斷 SPA 路徑轉換的語意起點，表示明確的使用者意圖。transitionWhile() 承諾解決方案可協助瀏覽器將繪製作業與特定路徑轉換相關聯，以便判斷與該轉換相關的最大內容繪製。
在前一個章節提出的想法基礎上，您甚至可以將 SPA 路徑轉換時間匯入相同的桶，就像在 MPA 中載入相同來源的頁面一樣。這項功能令人振奮，因為它可讓網站從 MPA 遷移至 SPA，實際比較遷移前後的成效。
當然，我們需要進行更多研究，才能知道是否能準確做出這些判斷。如果您對這些提案有任何建議或意見，請傳送電子郵件至 web-vitals-feedback@googlegroups.com。
結論
Google 致力於改善 Web Vitals 指標，確保這些指標可評估並鼓勵提供對使用者重要的高品質體驗。不過，我們也瞭解目前仍存在評估缺口。這些指標目前不涵蓋使用者體驗的所有面向，但我們正積極努力彌補這些缺口。
儘管目前仍有限制，但我們認為現有指標確實可擷取的領域，對網站的健康和成功至關重要，而且如果網站 (不論架構為何) 未達建議門檻，我們認為仍有改善空間。
希望這篇文章能讓您對這個複雜且細微的議題有更深入的瞭解。 如想針對目前或未來的 Web Vitals 指標提供意見，請傳送電子郵件至 web-vitals-feedback@googlegroups.com。