針對單頁應用程式、網站體驗核心指標，以及網站體驗核心指標如何處理這些應用程式，提供常見問題的解答。
發布日期：2021 年 9 月 14 日，上次更新時間：2026 年 8 月 11 日
自 2020 年 5 月首次推出 Web Vitals 計畫以來，Chrome 團隊收到許多關於這項計畫的絕佳問題和意見回饋。
我們收到最多問題的主題，可能也是最難回答的問題，就是如何在單頁應用程式 (SPA) 中評估 Core Web Vitals，以及 SPA 架構如何影響 Core Web Vitals 分數。
這些問題很難回答，因為問題相當細微，因此我們將盡力在本文中回答最常見的問題，並盡可能提供詳細資料和背景資訊。
不過，在深入探討具體細節之前，請務必瞭解 Google 對於網站建構所用的架構或技術，並無任何偏好。我們認為單頁應用程式和多頁應用程式都能為使用者提供優質體驗，而我們推出「網站使用體驗核心指標」計畫，是為了提供與技術無關的體驗評估指標。
常見問題
以下是我們最常收到的相關問題。歡迎透過意見回饋群組或提出問題，提供意見回饋，協助我們擴充這份常見問題。
Core Web Vitals 指標是否包含 SPA 路線轉換？
剛推出時，系統會根據目前的頂層網頁導覽，評估各項網站體驗核心指標。如果網頁動態載入新內容，並更新網址列中的網頁網址，這不會影響 Core Web Vitals 指標的評估方式。
指標值不會重設，且與各項指標評估相關聯的網址，是使用者導向的網址，會啟動載入網頁。
Chrome 151 推出了新版 API，可讓您評估 SPA 路由轉換期間的 Core Web Vitals。撰寫本文時 (2026 年 8 月)，這些 API 才剛開始用於 web-vitals 等評估程式庫、RUM 解決方案，以及 Chrome 開發人員工具等工具。Chrome 尚未公布將這些指標整合至 Chrome 使用者體驗報告 (CrUX) 的時間範圍。此外，其他瀏覽器引擎尚未支援這些新 API，因此只能在這些瀏覽器完整載入網頁時，才能評估 Core Web Vitals。
為什麼這個問題難以解決？
目前沒有建構 SPA 的標準方式，即使是熱門的 SPA 和路由程式庫，使用者體驗也可能因應用程式而異：
- 部分 SPA 只會在載入新的「完整網頁」內容時更新網址，其他網站則會在內容有微小變更，甚至是 UI 狀態變更時更新網址。
- 部分 SPA 會使用 History API 更新網址，其他 SPA 則會使用雜湊變更，以便支援舊版瀏覽器 (還有一些 SPA 完全不會更新網址)。
- 部分 SPA 會先載入內容，再更新網址；其他 SPA 則會先更新網址，再載入內容。
- 有些 SPA 會在單一 JavaScript 工作中，同步載入所有內容，有些則會在多項工作中非同步轉換內容 (沒有明確的轉換結束事件)。
- 有些 SPA 一律會從網路載入內容，有些則會預先載入所有內容，以便從記憶體即時載入路徑變更。
這些差異導致難以大規模定義及識別 SPA 路徑變更，甚至是 SPA 本身。
在某些情況下，SPA 路徑變更在邏輯上與 MPA 載入網頁相同，因此如果能套用現有的 Core Web Vitals 指標，將會非常實用。
不過，如果沒有可靠的啟發式方法，可從所有其他網址變更中，找出「實際」路徑變更，以及標示這類轉換開始和結束的明確信號，在這些情況下回報網站體驗核心指標，就會混淆資料，導致資料不夠實用，或無法代表網站的實際使用者體驗。
軟性導覽工作已透過兩項新的效能 API 提供解決方案：
PerformanceSoftNavigation，用於評估使用者互動導致繪製和網址變更的時間。無論使用哪種架構，以及先前提到的一些差異，這三項要素的組合都能提供「軟性導覽」的標準化定義。這可將成效時間軸分割為個別的「導覽」，以便針對每次導覽測量 CLS 和 INP。InteractionContentfulPaint，可測量互動後的「有內容的繪製」，進而測量這些軟性導覽的 FCP 和 LCP。
結合這兩個 API，即可在完整網頁載入和軟性導覽中，評估 Core Web Vitals。
單頁應用程式 (SPA) 的路徑變更是否與 Core Web Vitals 的完整網頁載入相同？
不會，這兩種導覽方式仍有許多差異，可能會導致網站體驗核心指標不同。
軟性導覽會顯示網頁內容，並更新部分或所有內容，以顯示新的「網頁」。在許多方面，這與未快取完整載入網頁與部分或所有網頁資源快取時的載入網頁之間的差異類似，但由於部分內容可能會保持呈現狀態，因此情況更加極端。
理論上，主要差異在於軟性導覽的速度可能會快上許多。但還有其他更細微的差異。
新的軟性導覽 API 只會考量新內容。因此，如果網頁更新了 <h1> 和文字內容，但網頁間的相同主頁橫幅未重新繪製，系統就不會將該主頁橫幅視為 LCP 候選項目。這會導致系統根據網頁是以完整載入網頁，還是從其他現有網頁以軟性導覽方式載入，使用不同的元素計算 LCP 時間。
同樣地，由於網站執行所需的許多 JavaScript 都已載入，因此軟性導覽的 INP 可能較低。同樣地，軟性導覽可能包含較少 (或更多！) 如果相同內容在完整載入網頁時會導致 CLS，但在軟性導覽時不需要載入或重新算繪，則 CLS。
此外，在完整網頁載入 (從導覽互動處理後開始測量) 與軟性導覽 (從互動開始時間開始測量) 中，進行測量的時間點也略有不同。
如前所述，許多差異與未快取和已快取的網頁類似，而 Core Web Vitals 嘗試評估的概念仍然適用。不過，在調查網站體驗核心指標問題時，瞭解這些細微差異很有幫助。
與 MPA 相比，SPA 是否更難在 Core Web Vitals 方面表現良好？
單頁應用程式架構本身不會妨礙單頁應用程式中的網頁載入速度，也不會影響網頁在所有網站體驗核心指標中的得分，多頁應用程式中的類似網頁也是如此。
不過，如果 MPA 經過適當最佳化，在達到網站體驗核心指標門檻方面，確實比 SPA 有些優勢。先前討論的軟性導覽作業已大幅減輕這個問題，但如果尚未使用這些新版 API，可能仍會發生這種情況。 這是因為在 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 架構影響 Core Web Vitals 分數的另一種方式，是針對考量網頁完整生命週期的指標。由於造訪 SPA 的使用者在整個工作階段中，往往會停留在同一個「網頁」，因此與 MPA 相比，SPA 的指標可能會隨著時間累積而變得更嚴苛。
我們認為，在軟性導覽功能推出後，單頁應用程式在 Core Web Vitals 評估方面應該不會有任何缺點。不過，在所有工具和報表解決方案中全面整合這些 API 需要時間。
如果 SPA 架構能提升使用者體驗，指標應該會反映這項改善，不是嗎？
應該是。由於目前網路上導入 SPA 的方式各不相同，因此很難大規模量化體驗的改善程度。我們現在有解決成效評估問題的解決方案，使用這些新 API 時，改用 SPA 帶來的任何改善都應會反映在指標中。
事實上，網頁效能產業 (包括 Google) 一直以來投入開發以使用者為中心的指標，評估網頁載入後效能的時間和精力，遠不及評估載入網頁本身。並非載入後效能不重要，而是載入後的使用者體驗和互動變化更多，且定義較不明確，因此難以設計相關指標。
但即使現在有更多載入後指標可評估 SPA 效能，我們也不會因為載入後體驗變好，就忽略載入體驗。
Web Vitals 計畫的目標之一，是盡可能從多個層面推廣並鼓勵提供優質的使用者體驗，包括網頁的載入和使用方式。我們不希望鼓勵使用者以足夠的良好體驗來彌補不良體驗，藉此合理化不良體驗。使用者希望網頁能快速載入並快速轉換至新內容，因此我們嘗試設計出有利於這類體驗的指標。
我們將網站從 MPA 換成 SPA，分數就退步了。這是正常的嗎？
視情況而定。重大架構遷移後，分數可能會因多種原因而改變，但暖快取載入次數減少可能是其中一個原因。
如要快速檢查，請使用 Lighthouse 測試其中一個到達網頁的 MPA 和 SPA 版本。如果 SPA 版本的任何網站使用體驗核心指標的 Lighthouse 分數較低，表示更新後載入體驗可能變差。
我是否應將網站從 SPA 換成 MPA，以提高網站體驗核心指標分數？
別緊張。只有在不滿意 SPA 堆疊，且有理由相信 MPA 能提供更優質的使用者體驗時，才應從 SPA 切換至 MPA。
我們認為軟性導覽工作已解決評估問題，因此光是為了這個原因而遷移並不合理。
不過，如果您有理由證明效能會提升，而不只是指標改善，那麼這或許就是從 SPA 移至 MPA (或反之) 的原因！
如果系統只回報 SPA 登陸網頁的 Core Web Vitals 分數，我該如何偵錯路徑轉換後「網頁」上發生的問題？
Google 工具 (例如 Search Console 和 PageSpeed Insights) 會從 Chrome 使用者體驗報告 (CrUX) 取得資料，並據此回報 Core Web Vitals 指標的現場資料。此外，CrUX 會依來源或網頁網址 (即載入時的網頁網址) 匯總資料。
我們正在努力，讓 CrUX 能夠在匯總資料中納入 SPA 路線的資料。不過，網站擁有者現在可以使用新的 API，預先依 SPA 路徑評估 Core Web Vitals，瞭解分數可能會如何變化。
如要進一步瞭解這項功能和最佳做法，請參閱「評估軟性導覽」。
Google 採取哪些措施，確保 MPA 不會比 SPA 享有不公平的優勢？
如先前所述，我們相信在軟性導覽作業完成後，SPA 在這方面應該不會有任何缺點，但全面整合所有工具和報表解決方案需要時間。
分別評估跨源和同來源的網頁造訪
目前，網站使用體驗核心指標會將所有網頁造訪彙整到單一儲存區，不會區分新訪客與回訪者、到達網頁與結帳頁面，或任何其他可能因快取狀態而影響效能的彙整類型。
如要讓 SPA 和 MPA 的成效差異趨於正常，其中一種方法是為不同類型的造訪套用不同的權重，甚至可能採用完全不同的門檻建議。
我們確實希望獎勵有效的快取實作方式，但不想讓快速的站內導覽掩蓋緩慢的到達網頁載入速度。我們也不希望網站為了提高指標分數，而將長網頁拆成多個短網頁。
分別評估跨來源和同來源網頁造訪次數，有助於確保這兩種體驗都很重要，且不會因為特定網站上某種體驗的相對熱門程度，而導致任何特定指標的分布情形出現偏差。
結論
Google 致力於改善 Web Vitals 指標，確保這些指標能評估並鼓勵提供對使用者而言重要的優質體驗。不過，我們也承認目前確實存在評估缺口。現在指標可以涵蓋 SPA 路線轉換，解決其中一個主要缺口。
我們也認為，除了評估軟性導覽的核心網頁指標，這些新 API (尤其是 InteractionContentfulPaint) 還有其他用途和潛在優點。現在主要導入原因已解決，我們很期待能繼續擴充這些功能。
希望這篇文章有助於您瞭解這個複雜且細微的主題。和往常一樣，如果您對目前或未來的網頁指標有任何意見，歡迎傳送電子郵件至 web-vitals-feedback@googlegroups.com。