嘗試測量軟導覽

Barry Pollard

Michal Mocny

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

2026 年 3 月更新：Chrome 147 (4 月 7 日起推出) 將開始進行新的軟體導覽來源試用，希望這是最後一次。開發人員也可以啟用 chrome://flags/#soft-navigation-heuristics，在 Chrome 147 中試用這項功能。

自推出以來，Core Web Vitals 計畫旨在評估網站的實際使用者體驗，而非網站建立或載入背後的技術細節。Core Web Vitals 是以使用者為中心的指標，可做為DOMContentLoaded或 load 等現有技術指標的演進版。這些指標通常會測量與使用者對網頁效能的觀感無關的時間。因此，只要網站效能良好，用來建構網站的技術就不會影響評分。

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

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

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

我們根據上次來源試用的開發人員意見回饋，對 API 進行了多項改善，現在請開發人員試用最新版本，並在正式推出前提供做法意見回饋。我們相當有信心，經過這些疊代後，API 已臻於完善，並預計在今年稍晚推出 API，但仍須視這次最新來源試用計畫的意見回饋而定。

什麼是軟式導覽？

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

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

在某些網站上，這些啟發式方法可能會導致偽陽性 (使用者不會真的認為發生「導覽」) 或偽陰性 (使用者認為發生「導覽」，但未符合這些條件)。歡迎在軟體導覽規格存放區提供有關啟發式方法的意見。

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

我們在追蹤記錄檢視畫面中，為開發人員工具的「效能」面板新增了軟性導覽支援功能：

「Performance」面板中的軟體導覽標記，以及來自 youtube.com 的追蹤記錄。

您會看到軟性導覽和 LCP 的標記，兩者都會標上 *，方便您與一般硬性導覽項目區別。這項功能預設為啟用，與我們接下來要討論的 Performance API 變更不同。這項工具可快速測試網站的軟性導覽實驗是否正常運作。

目前追蹤記錄檢視畫面只會顯示軟性導覽和 LCP 時間戳記。其他指標 (例如 LCP) 和「即時指標」檢視畫面支援功能將於日後推出。

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

啟用軟性導覽啟發式方法後 (詳情請見下一節)，Chrome 會變更部分成效指標的匯報方式：

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

這些變更可讓系統根據網頁瀏覽評估 Core Web Vitals 和部分相關診斷指標，但請注意，這項功能有幾項細微差異。

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

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

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

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

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

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

Chrome 預設不會啟用軟性導覽，但您可以明確啟用這項功能，進行實驗。

開發人員只要在 chrome://flags/#soft-navigation-heuristics 中開啟旗標，即可啟用這項功能。或者，您也可以在啟動 Chrome 時使用 --enable-features=SoftNavigationHeuristics 指令列引數啟用這項功能。啟用 chrome://flags/#enable-experimental-web-platform-features 旗標也會啟用軟性導覽。

如果網站想為所有訪客啟用這項功能，瞭解其影響，可以從 Chrome 147 開始執行來源試用，只要註冊試用並在 HTML 或 HTTP 標頭中加入含有來源試用權杖的中繼元素，即可啟用這項功能。詳情請參閱「開始使用來源試用計畫」一文。

網站擁有者可以選擇在網頁上為所有使用者或僅為部分使用者加入來源試用。請詳閱先前的影響一節，瞭解這項變更對指標回報方式的影響，特別是為大量使用者啟用這項來源試用功能時。請注意，無論這項軟體導覽設定為何，CrUX 都會繼續以現有方式回報指標，因此不會受到這些影響。此外，也請注意，原始碼試用活動最多只能在 14 天內，啟用所有 Chrome 網頁載入作業中位數的 0.5% 實驗功能，但這只會對非常大型的網站造成問題。

偵測 Soft Navigations API 支援的功能

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

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

請注意，supportedEntryTypes 會在首次使用時凍結，因此如果來源試用權杖插入網頁後，動態新增了軟性導覽支援，這時可能會傳回原始值，也就是該功能啟用前的值。

在這種情況下，您可以改用下列替代方案，因為系統預設尚未支援軟性導覽，且處於這種轉換狀態：

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

如何評估軟性導覽？

啟用軟性導覽實驗後，系統會使用 PerformanceObserver API 匯報指標，與其他指標相同。不過，這些指標需要額外考量一些因素。

回報軟性導覽

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

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

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

針對適當的網址回報指標

如果系統偵測到軟性導覽，應先完成前一頁的網站使用體驗核心指標，然後為前一個網址產生報表，並開始監控新網址。

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

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

檢舉「`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 項目中的 largestInteractionContentfulPaint 項目，以便更輕鬆地處理 soft-navigation entries 發出前發生的 interaction-contentful-paint 項目。

取得軟體導覽的 `startTime`

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

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

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

評估每次軟性導覽的 Core Web Vitals

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

接著，您就可以照常測量及監控 LCP、INP 和 CLS (使用 interaction-contentful-paint 的 LCP 提供 interactionId 比對時除外)。interactionId 和 navigationId 可用來為網址的項目命名，如先前所述。

系統仍會根據原始的「硬性」導覽開始時間傳回時間。因此，如要計算軟性導覽的 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 元素可能會不同一樣。

提示：收集 RUM 資料時，應加入 navigationType，以便針對軟性導覽以不同方式區隔 LCP (以及 INP 和 CLS)，因為這些指標的特性可能有所差異。

如何評估 TTFB？

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

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

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

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

在實驗期間，建議您繼續以目前的方式，根據「硬性」網頁導覽來評估 Core Web Vitals，因為新實作方式可能會在最終發布前發生問題或變更。這項做法也會與 CrUX 目前的測量結果相符 (稍後會詳細說明)。

除了這些指標外，您也應評估軟性導覽，瞭解日後如何評估這類導覽，並向 Chrome 團隊回報這項實作方式的實際運作情形。這有助於您和 Chrome 團隊共同打造未來的 API。

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

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

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

如要輕鬆掌握所有細微差異，最簡單的方法是使用 web-vitals JavaScript 程式庫，該程式庫在獨立的 soft-navs branch 中實驗性支援軟性導覽 (也可在 npm 和 unpkg 上取得)。您可以透過下列方式評估這項指標 (視情況替換 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 程式庫會回報下列軟性導覽指標：

指標	詳細資料
TTFB	回報為 0。
FCP	首次顯示內容所需時間，以觸發軟性導覽的互動為準，相對於軟性導覽的開始時間。系統不會考慮先前導覽中出現的現有繪製，或與互動無關的繪製。
LCP	相對於軟式導覽開始時間，從觸發軟式導覽的互動開始，最大內容繪製的時間。系統不會考慮先前導覽中出現的現有繪製，或與互動無關的繪製。與往常一樣，系統會在互動發生時或網頁移至背景時回報這項指標，因為只有在這些情況下，系統才能完成 LCP。
CLS	導航時間之間最大的時段。與往常一樣，只有在網頁進入背景時，系統才能完成 CLS 計算。如果沒有輪班，系統會回報值 0。
INP	導覽時間之間的 INP。與往常一樣，系統會在互動發生時或網頁進入背景時回報這項指標，因為只有在這些情況下，INP 才能完成計算。如果沒有任何互動，系統不會回報 0 值。

警告：web-vitals 實作方式仍在積極開發中，且會隨著發布至該分支版本的新變更而有所變動。如果使用者打算在正式版網站上使用 web-vitals JavaScript 程式庫，請注意這項異動，並取得本機副本、測試該版本，以及監控分支版本變更。

這些變更會納入 Core Web Vitals 的評估嗎？

我們想先評估這些啟發式方法，看看是否能更準確地反映使用者體驗，再決定是否將其整合至 Core Web Vitals 計畫。最終目標是提供方法，以便更準確地評估實際使用者的體驗成效。因此，如果這項實驗成功，我們就會將這些指標納入所有工具顯示的 Core Web Vitals 評估結果。

我們很重視網頁開發人員對這項實驗和所用啟發式方法的意見，以及您是否認為這項實驗能更準確地反映體驗。如要提供意見回饋，建議前往軟體導覽 GitHub 存放區，但如果 Chrome 實作該功能時發生個別錯誤，請在 Chrome 問題追蹤器中回報。

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

如果這項實驗成功，CrUX 會如何回報軟性導覽，目前也尚未確定。系統不一定會以處理目前「硬性」導覽的方式處理這些導覽。

在某些網頁中，就使用者而言，軟性導覽幾乎與完整網頁載入相同，而單頁應用程式技術的使用只是實作細節。在其他情況下，則可能更像是載入部分額外內容。

因此，我們可能會決定在 CrUX 中分別回報這些軟性導覽，或是在計算特定網頁或網頁群組的 Core Web Vitals 時，為這些導覽設定權重。隨著啟發式演算法的演進，我們或許也能完全排除部分載入的軟體導覽。

團隊目前專注於啟發式和技術實作，以便判斷這項實驗是否成功，因此尚未就這些方面做出任何決定。

意見回饋

我們積極尋求這項實驗的意見回饋，歡迎透過下列管道提供：

如要提供 API 意見回饋，請在 GitHub 上回報問題。
如果 Chromium 實作項目發生錯誤，且不屬於已知問題，請在 Chrome 的問題追蹤工具中提出。
如要分享一般 Web Vitals 意見，請傳送電子郵件至 web-vitals-feedback@googlegroups.com。

如有疑慮，請放心，我們很樂意在任一平台收到意見回饋，並會分類問題，將問題重新導向正確位置。

變更記錄

由於這項 API 處於實驗階段，因此會進行多項變更，變動幅度比穩定版 API 更大。詳情請參閱軟性導覽啟發式異動記錄。

結論

軟性導覽實驗是令人振奮的做法，有助於我們瞭解 Core Web Vitals 計畫的演進方向，以便評估現代網路上常見但目前指標未涵蓋的模式。這項實驗目前仍處於初期階段，還有許多工作要做，但將目前的進展提供給更廣大的網路社群進行實驗，是相當重要的一步。收集這項實驗的意見回饋也是實驗的重要環節，因此我們強烈建議對這項開發計畫有興趣的使用者把握機會，協助我們調整 API，確保 API 能代表我們希望透過這項技術評估的內容。

特別銘謝

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

這項工作是延續 Yoav Weiss 在 Google 時期所做的努力。感謝 Yoav 為這項 API 付出的努力。

嘗試測量軟導覽 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

什麼是軟式導覽？

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

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

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

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

偵測 Soft Navigations API 支援的功能

如何評估軟性導覽？

回報軟性導覽

針對適當的網址回報指標

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

取得軟體導覽的 startTime

評估每次軟性導覽的 Core Web Vitals

如果導覽之間內容保持不變，該如何處理？

如何評估 TTFB？

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

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

這些變更會納入 Core Web Vitals 的評估嗎？

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

意見回饋

變更記錄

結論

特別銘謝

嘗試測量軟導覽

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

取得軟體導覽的 `startTime`

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