SPA 架構對網站體驗核心指標的影響

回答 SPA、網站體驗核心指標,以及 Google 為解決目前評估限制方面的常見問題。

Yoav Weiss
Yoav Weiss

自 2020 年 5 月首次推出網站體驗指標計畫以來,Chrome 團隊收到了許多關於這項計畫的問題和意見回饋。

也許使用者最常回答的主題 (這也是最難回答的問題) 是如何在單頁應用程式 (SPA) 中評估 Core Web Vitals 指標,以及 SPA 架構對網站體驗核心指標分數的影響。

這些問題很難回答,因為問題相當複雜,因此本文將盡力回答常見問題,盡可能提供詳細的細節和背景資訊。

不過,在詳細說明之前,請務必聲明 Google 對於用來建構網站的架構或技術,完全沒有偏好。我們認為 SPAs 和多頁應用程式 (MPA) 能夠為使用者提供優質體驗,而 Web Vitals 計畫的用意是提供測量與技術無關的指標,以評估使用體驗。雖然現今的環境限制各不相同 (因為網路平台有所限制),但我們正在積極設法縮短這些差距

常見問題

網站體驗核心指標指標是否會包含 SPA 路徑轉換?

不會。網站體驗核心指標的每項指標,都會與目前的頂層網頁瀏覽活動相對評估。如果網頁以動態方式載入新內容,並更新網址列中的網頁網址,則不會影響 Core Web Vitals 指標的評估方式。指標值不會重設,而與各項指標評估作業相關聯的網址,則是使用者前往哪個網址啟動網頁載入。

網站體驗核心指標的資料是否可以像傳統網頁載入一樣處理 SPA 路徑變更?

很抱歉,不會。

如今還沒有標準化的 SPA 建構方式,即使在常見的 SPA 和路由程式庫中,使用者體驗也可能因應用程式而異:

  • 部分 SPA 只會在載入新的「完整頁面」內容時更新網址,其他網站則只會更新網址,進行小幅內容變更,或甚至是使用者介面狀態變更。
  • 有些 SPA 會使用 History API 更新網址,有些則會利用雜湊變更來支援舊版瀏覽器 (有些則不會更新網址)。
  • 有些 SPA 會載入內容並更新網址,有些則在載入內容前更新網址。
  • 有些 SPA 會在單一 JavaScript 工作中以同步方式一次載入所有內容,而其他 SPA 則會在多項工作中以非同步方式轉換內容 (沒有明確的轉換結束事件)。
  • 部分 SPA 一律會從網路載入內容,有些則預先預先載入所有內容,以便立即從記憶體載入路徑變更。

這些差異使得定義和辨識構成 SPA 路徑變更的因素,甚至是 SPA 本身非常困難,必須「大規模」才能做到。

在某些情況下,SPA 路徑變更與 MPA 網頁載入在邏輯上完全相同,在此情況下,如果能套用現有的 Core Web Vitals 指標,會是相當不錯的選擇。

不過,如果沒有可靠的經驗法則,才能準確辨別所有其他網址變更的「實際」路徑變化,以及清楚標示這類轉換開始和結束的明確信號,在這些情況下回報 Core Web Vitals 指標將難以利用資料,並降低資料對網站實際使用者體驗的實用性或代表性。

為什麼 SPAs 比 MPA 更容易在 Core Web Vitals 中得到良好?

SPA 架構本身並無任何作用,會阻礙 SPA 中的網頁載入速度和所有 Core Web Vitals 指標的評分,就像 MPA 中的類似網頁一樣。

然而,經過適當最佳化處理的 MPA 確實具有一些優勢,能夠達到 SPA 等級無法達到的核心 Web Vitals 門檻。這是因為在 MPA 架構下,每個「頁面」都會以全頁導覽的形式載入,而不是以動態方式擷取內容再插入現有頁面,也就是說,造訪 MPA 的使用者更有可能從網站載入多個網頁,這也意味著,所有 MPA 載入的網頁中,有部分或全部的快取會分配得更大。

前提是,MPA 需要做到以下幾點,才能改善網站體驗核心指標指標的成效:

  • MPA 需要經過最佳化子資源快取,才能確保相同來源的頁面載入速度確實比在第 75 個百分位數的跨來源頁面載入更快。
  • 造訪 MPA 的使用者需要造訪多個網頁,才能獲得快取方面的優勢,進而加快網頁載入速度。

由於網站體驗核心指標的評估作業會考量網頁造訪的第 75 個百分位數,因此只要資料集內有高成效的網頁造訪次數,造訪數就位在分佈情形的第 75 個百分位數內,更有可能達到建議的門檻。

請注意,比較網站體驗核心指標分數時,請務必考量資料的匯總方式。也就是說,分佈情形中的資料集是否包含網站或來源的所有網頁,或只載入特定網頁網址的網頁載入。

將特定來源中所有網頁的分數進行匯總時,個別的快速網頁可改善整體來源的第 75 個百分位數。但是,當依個別網頁匯總時,一個網頁的分數不會影響下一個網頁的分數。換句話說,在依網頁匯總 MPA 分數時,結帳頁面上出現快速快取載入並無法改善網站到達網頁中初始載入速度緩慢的分數。

您可以使用 PageSpeed InsightsChrome User Experience Report API,查看網站評分的不同匯總方法。這項工具會回報個別網頁網址和整個來源的分數。

SPA 架構會影響網站體驗核心指標分數的另一個方式,是考量網頁的完整生命週期指標。由於造訪 SPAs 的使用者在整個工作階段中通常會停留在相同的「頁面」,因此長期累積的指標可能會比 MPA 更嚴重。

我們在 2021 年 4 月宣布關於 CLS 指標的異動,這部分可以解決這項問題。先前的 CLS 會累積整個網頁生命週期,但現在只會累積一段特定時間 (基本上是特定網頁上的版面配置位移最嚴重的爆發現象)。

然而,即使採用新的 CLS 定義,SPA 仍是缺點,因為在路徑轉換後,如同在 MPA 中載入完整頁面一樣,CLS 值不會「重設」。這也可能會造成混淆,因為系統會將路線轉換後的版面配置轉乘,歸給載入時的網頁網址,而非平移時網址列中的網址 (詳情請參閱下文)。

如果 SPA 架構可以改善使用者體驗,指標是否該改善?

是的,正確。如前文所述,由於 SPA 是目前網頁所採取的各種做法,因此我們很難大規模地量化體驗改善的程度。

事實上,網路效能產業 (包括 Google 在內) 以往都沒有足夠的時間和心力開發以使用者為中心的指標,以便評估網頁在載入後的效能,如同網頁載入本身對效能的影響。這並不是因為載入後的效能並不重要,因為載入後的使用者體驗和互動情況都大同小異且定義不夠明確,所以很難設計相關的指標。

不過,即使我們已正確定義用於評估 SPA 效能的載入後指標,也不會因為後續載入體驗較佳,而忽略載入體驗。

網站體驗指標計畫的目標之一,就是盡可能針對網頁載入及使用的各方面,提升並促進良好的使用者體驗。我們不希望鼓勵不當體驗的合理情境。使用者希望網頁能快速載入,「並且」快速轉換至新內容,因此我們在設計的指標上偏好這些體驗。

因此,相較於相同網站的 SPA 版本,網站的 MPA 版本確實可以提昇在 Core Web Vitals 指標的第 75 個百分位數值,但 SPA 版本仍應盡力達到「良好」門檻。如果 SPA 版本未達大部分使用者的「良好」門檻,可能仍然不認為初始載入體驗良好,即使後續的網頁內瀏覽體驗良好也一樣。

我們計劃在未來開發指標,藉此鼓勵在載入後提供優質服務。我們相信,這是推動優質 SPA 獎勵的最佳途徑,但可以避免影響初始載入體驗。我們已推出名為「Interaction to Next Paint (INP)」的新指標,用於測量整個頁面生命週期中的互動延遲時間,也正在積極研究其他載入後指標,包括評估 SPA 路徑轉換的指標 (請參閱下方說明)。

我們的網站從 MPA 切換為 SPA,分數下降。這是正常的嗎?

視情況而定。在主要架構遷移後,分數出現變化的原因有很多,但暖快取負載減少可能導致一些變更。

想要快速確認,可以使用 Lighthouse 測試其中一個到達網頁的 MPA 和 SPA 版本。如果 Lighthouse 針對 SPA 版本的任何網站體驗核心指標分數較低,很有可能在更新後載入體驗是否變得更糟。

我是否應該將網站從 SPA 切換為 MPA,才能提高網站體驗核心指標的分數?

別緊張。除非您對 SPA 堆疊不滿意,且有充分理由相信 MPA 可提供更優質的使用者體驗,否則請勿從 SPA 改用 MPA。

隨著網站體驗核心指標改善並涵蓋更多完整瀏覽體驗,如果團隊擁有完善的 SPA 內容,可提供絕佳的使用者體驗,他們應該就能看到相應的網站體驗核心指標分數。

如果只針對 SPA 到達網頁回報網站體驗核心指標分數,該如何對路徑轉換後「網頁」問題進行偵錯?

用於回報網站體驗核心指標指標資料 (例如 Search Console 和 PageSpeed Insights) 的 Google 工具會從 Chrome 使用者體驗報告 (CrUX) 取得資料。CrUX 會按來源或網頁網址 (也就是載入時的網頁網址) 匯總資料。

基於上述所有原因,CrUX 無法依 SPA 路徑匯總資料。不過,身為熟悉自家架構的網站擁有者,也可以自行評估相關成效,而許多數據分析工具也可讓您在 SPA 路徑發生變更時發出信號,並據此更新評估資料。

使用分析工具評估網站體驗指標指標時,請務必同時評估目前路徑網址和原始網頁網址。這可讓您對整個網頁生命週期中發生的個別問題進行偵錯,並且按照原始網頁網址匯總,以符合 Google 工具測量及回報指標的方式。

如需這個主題的詳細資訊和最佳做法,請參閱:針對欄位中的效能進行偵錯

與 SPA 相比,Google 採取了哪些措施來確保製造商零件協議不會有不公平的優勢?

如上所述,在某些情況下,經過適當最佳化的 MPA 可以回報網站體驗指標分數達到第 75 個百分位數的較佳,因為快取網頁造訪的比例可能較高。相反地,任何網站體驗核心指標指標目前都無法

Google 發現,這樣的獎勵措施無法與網站體驗指標計畫的目標完全一致,也積極設法解決這個問題。我們正在研究兩種可能的解決方案,一個短期和一個長期的解決方案:

  1. 分別評估跨來源和相同來源的網頁造訪次數。
  2. 設計新的 API 以改善 SPA 評估作業。

分別評估跨來源和同來源網頁的造訪次數

目前,網站體驗核心指標會將所有網頁造訪匯總為單一值區,因此不會區分新訪客與回訪/到達網頁,以及結帳頁面或快取狀態可能對效能造成影響的任何其他匯總類型。

如要將 SPA 和 MPA 效能差異正規化,其中一種方法是針對不同類型的造訪套用不同的權重,甚至可能會採用完全不同的門檻建議

雖然我們絕對希望獎勵有效實作的快取,但不希望快速的內部瀏覽才涵蓋到達網頁載入速度緩慢的情況。我們也不想為了提高指標分數,而誘導網站將冗長的網頁拆成一組較短的網頁。

藉由單獨評估跨來源和相同來源的網頁造訪次數,我們就能確保這兩種體驗都很重要,而且不會因為網站某類的相對熱門度出現特定指標的分佈偏差。

設計新的 API 以改善 SPA 評估作業

同時,我們也正在積極開發的另一個解決方案是新的 App History API,能協助將目前的 SPA 模式標準化,更輕鬆地大規模評估及瞭解 SPA 用量。

App History API 導入了新的 navigate 事件,具備 SPA 評估作業專屬的兩項主要功能:

  • userInitiated 標記;只有當導覽是透過連結點擊、表單提交,或瀏覽器的返回/前進 UI 啟動時,才會設為 true。
  • transitionWhile() 方法:此方法會在使用者為了執行導覽而啟動的作業時,讓開發人員發出信號。

userInitiated 旗標可用來決定 SPA 路徑轉換的語意起點,用於表示明確的使用者意圖。transitionWhile() 承諾解析可協助瀏覽器找出繪製路線與特定路線轉換的關聯,以便判斷與轉換相關的最大內容繪製作業。

以上一節介紹的概念為基礎,甚至可以將 SPA 路徑轉換時間匯總至相同的值區,如同在 MPA 中載入相同來源的頁面。這相當令人振奮,因為這樣可以讓網站從 MPA 遷移至 SPA ,才能實際比較前後效能差異。

當然,我們還需要進行更多研究,才能確定是否能夠準確做出決定。如果您對這些提案有任何建議或意見,請傳送電子郵件至 web-vitals-feedback@googlegroups.com

結論

Google 致力於改善網站體驗指標,並確保這些指標能評估並鼓勵對使用者至關重要的優質體驗。儘管如此,我們確實瞭解現今的評估落差確實存在。這些指標目前無法涵蓋所有使用者體驗層面,但我們正積極努力解決這些缺口。

儘管目前的限制有所限制,我們仍相信現有指標所擷取的領域對於網站的健全與成功至關重要。如果網站 (無論架構為何) 都未達到建議的門檻,我們相信還有改進空間。

希望這篇文章能幫助你清楚瞭解這個複雜又微妙的主題。 與往常一樣,如要針對目前或未來的 Web Vitals 指標提出意見,請傳送電子郵件至 web-vitals-feedback@googlegroups.com