評估軟性導覽

Barry Pollard

Michal Mocny

發布日期：2023 年 2 月 1 日，上次更新時間：2026 年 9 月 2 日

自推出以來，Core Web Vitals 計畫旨在評估網站的實際使用者體驗，而非網站的建立或載入方式背後的技術細節。這三項 Core Web Vitals 指標是以使用者為中心的指標，相較於DOMContentLoaded或 load 等現有技術指標，可衡量與使用者感受到的網頁效能相關的時間。因此，只要網站效能良好，用來建構網站的技術就不會影響評分。

實際情況往往比理想情況複雜，而網站體驗核心指標從未完全支援熱門的單頁應用程式架構。這類網路應用程式會使用所謂的「軟性導覽」，也就是透過 JavaScript 變更網頁內容，而不是在使用者瀏覽網站時載入不同的個別網頁。在這些應用程式中，系統會變更網址並將先前的網址推送至瀏覽器的記錄，維持傳統網頁架構的錯覺，讓返回和上一頁按鈕如使用者預期般運作。

許多 JavaScript 架構都使用這個模型，但方式各不相同。由於這類互動並非瀏覽器傳統上所認知的「網頁」，因此一向難以評估：究竟要將這類互動視為「目前」網頁的互動，還是「新」網頁的互動？

Chrome 團隊已考慮這項挑戰一段時間，並希望標準化「軟性導覽」的定義，以及如何針對這項指標評估網站使用體驗核心指標，做法與評估以傳統多頁面架構 (MPA) 實作的網站類似。

我們根據開發人員的意見回饋，對提案進行了多項改良，並從 Chrome 151 版開始推出兩項新的效能 API，協助解決這個問題。

什麼是軟式導覽？

我們為軟性導覽定義如下：

• 瀏覽動作是由使用者動作啟動。
• 瀏覽作業會導致使用者看到的網址發生變化。
• 互動會導致可見的繪製作業。

對於某些網站，這個定義可能會導致誤判 (使用者不會真的認為發生「導覽」)，或誤判為否定 (使用者認為發生「導覽」，但未符合這些條件)。歡迎前往軟體導覽規格存放區提供意見。

開發人員工具支援軟性導覽

我們已在「即時指標」檢視畫面中，為開發人員工具的「效能」面板新增軟性導覽支援功能，並在追蹤檢視畫面中提供洞察和標記支援：

Chrome 如何為網頁開發人員實作軟性導覽？

啟用軟性導覽功能後 (詳情請見下一節)，Chrome 會變更部分成效指標的計算方式：

• 系統偵測到每次軟性導覽後，都會發出 soft-navigation PerformanceTiming 事件。
• 這個 soft-navigation 項目會包含 navigationId、name 屬性中的新網址，以及啟動互動的 interactionId。
• 在導致內容繪製的互動後，系統會發出一個或多個 interaction-contentful-paint 項目。這個項目會包含 largestContentfulPaint 項目，可用於評估軟性導覽的 Largest Contentful Paint (LCP)。
• navigationId 屬性會新增至每個效能時間 (first-paint、first-contentful-paint、largest-contentful-paint、interaction-contentful-paint、first-input-delay、event 和 layout-shift)。這對應於事件發出的導覽項目。請注意，如果這些項目跨越軟性導覽，則可能會包含前一個或下一個 navigationId，視項目發出的時間而定。詳情請參閱「針對適當網址回報指標」一節。
• soft-navigation 會包含 getLargestInteractionContentfulPaint() 函式，用於擷取該導覽的最大 interaction-contentful-paint 項目。這項資料隨後可用於該導覽的初始 LCP，且隨著觀察到該互動的更多 interaction-contentful-paint 項目，該 LCP 隨後也會更新。請注意，這會取代先前原始碼試用中提供的 largestInteractionContentfulPaint 屬性。
• 在軟性導覽發生前，可能已發生一些 interaction-contentful-paint 項目 (如果網址更新發生在這些繪製作業之後)。在這些情況下，getLargestInteractionContentfulPaint() 函式可避免在軟性導覽完成後，需要緩衝處理及回顧舊項目。請注意，getLargestInteractionContentfulPaint() 傳回的項目是發出時最大 interaction-contentful-paint 項目的確切副本，因此該項目可能使用先前的 navigationId，因為這是發生繪製的時間，但這些繪製作業應根據新的 navigationId 進行測量。
• soft-navigation 項目也會將 paintTime 和 presentationTime 納入該導覽的 FCP。
• 請注意，後續互動也會發出 interaction-contentful-paint 項目，但網址的 LCP 應僅限於符合軟性導覽 interactionId 的 interaction-contentful-paint 項目，以排除這些項目，且僅限於其中的 largestContentfulPaint 屬性。

這些變更可讓系統根據網頁瀏覽評估 Core Web Vitals，以及部分相關的診斷指標，但請注意，這項功能有幾點需要考量。

在 Chrome 中啟用軟性導覽會造成哪些影響？

啟用這項功能後，網站擁有者需要注意以下變更：

• 監控 soft-navigation 項目可將成效項目「切片」成各個「導覽」。
• CLS 和 INP 指標已可由您自行選擇時間範圍，不必在整個網頁生命週期內進行測量，但軟性導覽功能可提供標準化的測量結果，無論使用哪種基礎技術都適用。
• largest-contentful-paint 項目會在互動時完成 (這是啟動軟性導覽的必要條件)，因此只能用於測量初始「硬性」導覽 LCP。也就是說，系統在評估軟性導覽時不會變更這項指標，因此系統仍會照常評估初始硬性導覽的載入網頁 LCP。
• 互動發出的新 interaction-contentful-paint 項目可用於測量軟式導覽的 LCP，方法是查看其中的 largestContentfulPaint 屬性，但使用這個項目時須注意一些事項，本文將說明這些事項。
• 請注意，並非所有使用者都支援這項軟體導覽功能，尤其是使用其他瀏覽器或 Chrome 151 以前版本的使用者。請注意，部分使用者可能不會回報以軟性導覽為準的指標，即使他們會回報網站使用體驗核心指標也一樣。

請洽詢 RUM 供應商，確認他們是否支援透過軟性導覽評估網站體驗核心指標。許多人打算測試這項新標準，並將先前的考量因素納入考量。在此期間，部分供應商也允許根據自家啟發式方法，有限度地評估成效指標。

如要進一步瞭解如何評估軟性導覽的指標，請參閱「評估每次軟性導覽的 Core Web Vitals」一節。

如何在 Chrome 中啟用軟性導覽？

Chrome 151 版起，軟性導覽功能預設為啟用。

偵測 Soft Navigations API 支援情況的功能

您可以使用下列程式碼測試是否支援 API：

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

或者：

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

如何評估軟性導覽？

在支援的情況下，這些指標可透過 PerformanceObserver API 進行回報，與其他指標相同。不過，這些指標還需要考量其他因素。

回報軟性導覽

您可以使用 PerformanceObserver 觀察軟性導覽。以下是程式碼片段範例，可將軟性導覽項目記錄到控制台，包括使用 buffered 選項在這個頁面上進行的先前軟性導覽：

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

可用於完成先前導覽的完整生命週期網頁指標。

針對適當的網址回報指標

系統偵測到軟性導覽時，應先完成前一頁的 Core Web Vitals，然後回報前一個網址的指標，並開始監控新網址。

適當 soft-navigation 項目中的 name 屬性會包含用於回報指標的新網址，而 navigationId 則是這項導覽的專屬參照 (因為在單頁應用程式的生命週期中，可能會多次造訪相同網址)。

這應設為每個 soft-navigation 項目，並用於回報指標，直到收到下一個 soft-navigation 項目為止。

檢舉「interaction-contentful-paint」的正確網址

從 interaction-contentful-paint 項目計算 LCP 時，需要額外考量，因為並非所有 interaction-contentful-paint 項目都應使用 navigationId 對應，並回報為該網址的 LCP：

• 第一個問題是，如果 URL 更新前發生繪製，則可能會在軟性導覽發生前發出 interaction-contentful-paint 項目。在這種情況下，navigationId 會是舊網址。如果網址先更新，繪製作業會完成軟性導覽，在這種情況下，系統會先發出 soft-navigation 項目，而 interaction-contentful-paint 則會包含新網址。
• 第二個問題是，interaction-contentful-paint 仍會針對較新的互動發出項目，因為這項成效指標的範圍不只涵蓋軟性導覽的 LCP。我們只希望將軟性導覽載入的繪製作業納入 LCP 考量，而非後續互動的繪製作業。

因此，您應使用 interactionId (而非 navigationId) 將 interaction-contentful-paint 項目對應至 soft-navigation-entries，以取得正確的網址。這會處理任何含有舊 navigationId 的項目，並篩除不應納入 LCP 考量的 interaction-contentful-paint 項目。

此外，您應先處理 soft-navigation 項目中的 getLargestInteractionContentfulPaint() 函式，以便處理 soft-navigation entries 發出前發生的 interaction-contentful-paint 項目。

取得軟性導覽的 startTime

所有效能時間 (包括軟性瀏覽的時間)，以及用於計算 Core Web Vitals 指標的項目，都會以初始「硬性」網頁瀏覽時間為基準回報。因此，應從軟性導覽載入指標時間 (例如 LCP) 減去軟性導覽開始時間，改為回報與軟性導覽時間相關的指標。

以類似方式對應至適當的 soft-navigation 項目並使用其 startTime，即可取得導覽開始時間。

startTime 是啟動軟體導覽的初始互動時間 (例如點選按鈕)。這與「硬式導覽」有些不同，後者的「開始時間」是指瀏覽器「提交」新網頁的時間，以及執行部分事件處理常式程式碼之後的時間。軟性導覽開始時間也包含該事件處理常式程式碼，因為我們是從互動開始時間開始測量。

評估每次軟性導覽的網站體驗核心指標

如要評估網站體驗核心指標，請監聽 soft-navigation 項目，並在收到這些項目時重設指標。系統可以根據 presentationTime 發出 FCP，並將 LCP 初始化為 getLargestInteractionContentfulPaint() 項目。INP 和 CLS 應初始化為 0，如同載入網頁時一樣。

接著，您就能照常評估及監控 LCP、INP 和 CLS (但使用 interaction-contentful-paint 取得 LCP 時，interactionId 必須相符)。interactionId 可用來為網址的項目命名，如先前所述。

系統仍會根據原始的「硬性」導覽開始時間傳回時間。因此，如要計算軟性導覽的 LCP，您需要取得 interaction-contentful-paint 時間，並減去適當的軟性導覽開始時間 (如先前詳細說明)，以取得相對於軟性導覽的時間。

傳統上，部分指標是在網頁的整個生命週期中進行評估，例如 LCP 可能會變更，直到發生互動為止。無論是否有任何互動，只要離開網頁，CLS 和 INP 就無法再更新。因此，每次發生新的軟性導覽時，都應完成前一次導覽的指標。也就是說，使用軟性導覽評估 Core Web Vitals 時，初始「硬性」導覽指標可能會比平常更早完成。

同樣地，開始評估這些長期指標的新軟性導覽指標時，指標需要「重設」或「重新初始化」，並視為新指標，不會記憶先前「網頁」設定的值。也就是說，系統會重設對「最大」繪製、Interaction to Next Paint 或版面配置變更的瞭解，以便從頭開始再次評估。

如果導覽之間內容相同，該如何處理？

軟性導覽的 LCP (從 interaction-contentful-paint 計算) 只會測量新的繪製作業，以及與導致導覽的互動相關聯的繪製作業。這可能會導致 LCP 與從軟式導覽的冷載入到軟式載入不同。

舉例來說，假設網頁包含大型橫幅圖片 (LCP 元素)，但圖片下方的文字會隨著每次軟性導覽而變更。網頁初始載入時，系統會將橫幅圖片標示為 LCP 元素，並據此計算 LCP 時間。後續的軟性導覽中，下方文字會是軟性導覽後繪製的最大元素，也是新的 LCP 元素。不過，如果網頁是透過深層連結載入軟性導覽網址，橫幅圖片會重新繪製，因此符合 LCP 元素的條件。

同樣地，動畫可能會持續更新網頁的一部分，與發生的任何軟性導覽無關。由於背景動畫，任何新的繪製作業都不會納入新軟式導覽的 LCP 考量。不過，如果網頁是從這個網址重新載入，系統可能會將這些資源納入 LCP 考量。

如這些範例所示，軟性導覽的 LCP 元素可能會因網頁載入方式而異，就像載入網頁時使用網頁下方的錨點連結，可能會導致硬性導覽的 LCP 元素不同。

如何評估 TTFB？

傳統網頁載入的第一個位元組時間 (TTFB) 代表系統傳回原始要求的第一個位元組所用的時間。

如果是軟性導覽，這就是比較棘手的問題。我們是否應評估新網頁的第一個要求？如果應用程式中已有所有內容，且沒有其他要求，該怎麼辦？如果預先擷取要求是提前發出，該怎麼辦？如果要求與使用者角度的軟性導覽無關 (例如是分析要求)，該怎麼辦？

較簡單的方法是針對軟性導覽回報 TTFB 0，這與我們建議的往返快取還原方式類似。這是 web-vitals 程式庫用於軟性導覽的方法，也是我們目前建議用於這項指標的方法。

您是否應該使用這兩種方法評估網站體驗核心指標？

雖然這些新 API 僅適用於以 Chromium 為基礎的瀏覽器，但網站可能想透過軟性導覽來區分這兩者，並繼續透過硬性導覽來區分。這樣就能比較不同瀏覽器的資料，以及歷來趨勢。

就 LCP 而言，這表示目前的方式只會考量 largest-contentful-paint 項目，而新方式則會考量 largest-contentful-paint 和 interaction-contentful-paint 項目。

就 CLS 和 INP 而言，這表示要像目前一樣，在整個網頁生命週期中評估這些指標，並依軟性導覽分別劃分時間軸，以評估新指標的 CLS 和 INP 值。

然後，指標需要信號化並儲存兩次，才能進行分析。

使用 web-vitals 程式庫評估軟性導覽的 Core Web Vitals

如要輕鬆掌握所有細微差異，最簡單的方法是使用 web-vitals JavaScript 程式庫，該程式庫自 6.0.0 版起支援軟性導覽。您可以透過下列方式評估這項指標 (視情況替換 doTraditionalProcessing 和 doSoftNavProcessing)：

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

web-vitals 程式庫也會確保您回報的指標是針對正確的網址 (如先前所述)，因為這些指標包含 navigationId 和回呼中提供的項目 navigationURL。

web-vitals 程式庫會回報下列軟性導覽指標：

這些變更會納入網站體驗核心指標評估嗎？

最終目標是提供方法，以便更準確地評估實際使用者的體驗成效。因此，在 API 發布後，所有工具都會顯示這些指標，並將其納入網站體驗核心指標評估。

Chrome 使用者體驗報告會如何回報軟性導覽？

這項功能推出後，CrUX 會如何回報軟性導覽，目前也尚未確定。我們會在有更多資訊時，於此處公布 CrUX 的變更內容。

如何處理其他瀏覽器中的軟性導覽？

在不支援 API 的瀏覽器中，很難以程式輔助方式偵測軟性導覽，這也是我們開發這項 API 的原因。

您可以使用 Navigation API 監控網址變更，以便依網址區隔 INP (以及 CLS，但目前僅限 Chromium，因此無論如何都不會測量)。不過，這無法解決繪製指標 (FCP 和 LCP) 的問題，因為這些指標只能估算。

但我們認為，無論是評估軟性導覽的時間，還是將指標歸因於正確的導覽，這項 API 提供的洞察資料都非常重要，不容忽視。儘管目前尚不支援跨瀏覽器，我們仍建議使用這項新 API。就像推出 Core Web Vitals 時一樣，即使目前僅限於 Chromium 架構的瀏覽器，所發現的問題和效能解決方案可能也會影響所有瀏覽器。

我們會繼續完成標準化程序，並與其他瀏覽器供應商合作，展現這項 API 的重要性。

意見回饋

我們正積極徵求下列位置的 API 意見回饋：

• 如要提供 API 意見回饋，請在 GitHub 上回報問題。
• 如果這不是已知問題，請在 Chrome 的問題追蹤工具中提出 Chromium 實作的錯誤。
• 如要提供一般網頁指標意見，請傳送電子郵件至 web-vitals-feedback@googlegroups.com。

如有疑問，請放心，我們很樂意在任一平台收到意見回饋，並會妥善分類問題，將問題轉送至正確位置。

變更記錄

這個 API 在開發過程中經歷了許多變更，比穩定版 API 更甚。詳情請參閱軟性導覽異動記錄。

結論

軟性導覽功能是令人振奮的創新做法，可望成為 Core Web Vitals 計畫的演進方向，用來評估我們指標中缺少的現代網路常見模式。我們已彙整廣大網路社群的意見，並對這項 API 的潛力感到振奮。

特別銘謝

縮圖圖片由 Jordan Madrid 拍攝，取自 Unsplash

這項工作延續了 Yoav Weiss 在 Google 時期開始的工作。感謝 Yoav 為這項 API 付出的努力。