評估軟性導覽

Barry Pollard

Michal Mocny

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

Core Web Vitals 計畫自推出以來，一直致力於評估網站的實際使用者體驗，而非網站建立或載入方式的技術細節。這三項 Core Web Vitals 指標是以使用者為中心的指標，由現有的技術指標 (例如 DOMContentLoaded 或 load) 演變而來，用於衡量通常與使用者對網頁效能的感知無關的時間。因此，只要網站成效良好，建構網站所用的技術就不會影響評分。

現實情況總是比理想情況更棘手，而熱門的單頁應用程式架構從未完全支援 Core Web Vitals 指標。使用者瀏覽網站時，這些網頁應用程式不會載入不同的個別網頁，而是使用所謂的「軟導覽」，由 JavaScript 變更網頁內容。在這些應用程式中，系統會變更網址，並將先前的網址推送至瀏覽器的歷史記錄，讓上一頁和下一頁按鈕能按照使用者的預期運作，藉此維持傳統網頁架構的假象。

許多 JavaScript 架構都使用這個模型，但方式各不相同。由於這超出瀏覽器傳統上對「網頁」的理解，因此一直很難衡量：目前網頁上的互動與新網頁的互動，兩者之間的界線在哪裡？

Chrome 團隊已考慮這項挑戰一段時間，並希望標準化「軟導覽」的定義，以及如何評估 Core Web Vitals，方法與傳統多頁架構 (MPA) 實作的網站類似。

我們根據開發人員的意見回饋，對提案進行了多項改善，並推出兩個新的效能 API，協助解決 Chrome 151 的問題。此外，我們也在 Chrome 使用者體驗報告 (CrUX) 中，將軟導覽指標列為實驗指標。

什麼是軟導覽？

我們對軟導覽的定義如下：

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

對某些網站來說，這項定義可能會導致偽陽性 (使用者不認為發生「導覽」) 或偽陰性 (使用者認為發生「導覽」，但未符合這些條件)。歡迎前往軟導覽規格存放區提供意見。

DevTools 支援軟導覽

我們在開發人員工具的「效能」面板中，新增了對軟導覽的支援，包括「即時指標」檢視畫面，以及支援「洞察」和標記的追蹤檢視畫面：

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 項目時更新。請注意，這會取代先前來源試用中提供的 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 指標已可由您自行決定切片，而非在整個網頁生命週期內測量，但無論使用的基礎技術為何，Soft Navigation 功能都能提供標準化的測量方式。
• largest-contentful-paint 項目會在互動時完成 (這是啟動軟導覽的必要條件)，因此只能用於評估初始「硬」導覽 LCP。這表示評估軟導覽時，這項設定不會變更，因此初始硬導覽的載入網頁 LCP 仍可照常評估。
• 互動發出的新 interaction-contentful-paint 項目，可用於評估 LCP 的軟導覽，方法是查看其中的 largestContentfulPaint 屬性，但本文將討論如何使用這個項目。
• 請注意，並非所有使用者都支援這項軟導覽功能，尤其是使用其他瀏覽器或 Chrome 151 之前版本的使用者。請注意，部分使用者可能不會回報軟導覽指標，即使他們回報 Core Web Vitals 指標也一樣。

請向 RUM 供應商確認，他們是否支援透過軟導覽評估 Core Web Vitals。許多人打算測試這項新標準，並會考量上述因素。同時，部分供應商也允許根據自己的經驗法則，對成效指標進行有限的評估。

如要進一步瞭解如何評估軟導覽的指標，請參閱「評估每個軟導覽的 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：

• 第一個問題是，如果網址更新前發生繪製，系統可能會在軟導覽發生前發出 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 是啟動軟導覽的初始互動 (例如點選按鈕) 時間。這與「硬導覽」有些不同，後者的「開始時間」是指新頁面「提交」至瀏覽器，且部分事件處理常式程式碼執行後的時間。由於我們是從互動開始時間起算，因此軟導覽開始時間也包含該事件處理常式程式碼。

評估每次軟導覽的 Core Web Vitals

如要評估 Core Web Vitals，請監聽 soft-navigation 項目，並在收到這些項目時重設指標。FCP 可根據 presentationTime 發出，LCP 則可初始化為 getLargestInteractionContentfulPaint() 項目。INP、CLS 應初始化為 0，就像載入網頁時一樣。

接著，您可以照常評估及監控 LCP、INP 和 CLS (但 LCP 必須使用 interaction-contentful-paint，且 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？

傳統載入網頁的 Time to First Byte (TTFB) 代表原始要求傳回第一個位元組的時間。

如果是軟導覽，這個問題就比較棘手。是否應評估新網頁的第一個請求？如果所有內容都已存在於應用程式中，且沒有其他要求，該怎麼辦？如果事先透過預先擷取功能提出要求，會怎麼樣？如果要求與使用者角度的軟導覽無關 (例如數據分析要求)，該怎麼辦？

更簡單的方法是將軟導覽的 TTFB 回報為 0，這與我們建議的往返快取還原方式類似。web-vitals 程式庫會使用這個方法來測量軟導覽，這也是我們目前建議用於這項指標的方法。

是否應同時使用這兩種方法評估 Core 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 程式庫會回報下列軟導覽指標：

這些異動會納入 Core Web Vitals 評估項目嗎？

最終目標是提供一種方法，更準確地評估實際使用者的體驗成效。因此，我們的目標是在 API 推出後，將這些指標納入所有工具提供的 Core Web Vitals 評估項目。

CrUX 如何回報軟導覽？

我們已在 CrUX 中推出 Core Web Vitals 指標的實驗版本。這些指標會在首次軟導覽後結束「硬導覽」CLS 和 INP，並包含每次軟導覽的其他 LCP、CLS 和 INP 測量結果。我們預計在 2027 年 5 月將這些實驗性指標升級為穩定指標。詳情請參閱「CrUX 現已提供實驗性軟導覽指標」網誌文章。

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

在不支援 API 的瀏覽器中，很難透過程式輔助方式偵測軟導覽，這正是我們開發這個 API 的原因。

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

同時，我們認為這個 API 提供的洞察資料非常有價值，不容忽視，無論是評估軟導覽的時間，還是將指標歸因於正確的導覽，都是如此。雖然目前並非所有瀏覽器都支援這個新 API，但我們仍建議您使用。就像 Core Web Vitals 推出時一樣，即使目前只有 Chromium 瀏覽器會顯示問題和效能解決方案，但這些問題和解決方案仍可能影響所有瀏覽器。

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

意見回饋

我們正積極透過下列管道徵求對這個 API 的意見回饋：

• 如要提供 API 意見回饋，請在 GitHub 回報問題。
• 如果 Chromium 實作項目中的錯誤尚未列入已知問題，請在 Chrome 的 Issue Tracker 中提出。
• 如要提供網站體驗指標的一般意見回饋，請寄信至 web-vitals-feedback@googlegroups.com。

如有疑慮，請不必太擔心，我們很樂意在任一處收到意見回饋，並會在這兩處分類問題，並將問題重新導向至正確位置。

變更記錄

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

結論

Soft Navigations 功能是令人期待的做法，可讓 Core Web Vitals 計畫演進，評估現代網路上常見但指標中缺少的模式。我們從廣大的網路社群收集了大量意見回饋，並對這個 API 的潛力感到振奮。

特別銘謝

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

這項工作是 Yoav Weiss 在 Google 任職時開始的工作延續。感謝 Yoav 對這個 API 的貢獻。