嘗試測量軟導覽

Barry Pollard
Michal Mocny

發布日期：2023 年 2 月 1 日，上次更新日期：2025 年 7 月 22 日

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

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

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

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

自上次原始碼試用以來，我們一直努力改善 API，現在請開發人員試用最新版本，並在正式發布前提供意見回饋。

什麼是軟體導覽？

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

  • 導覽是由使用者動作啟動。
  • 導覽結果會導致使用者可見的網址變更，以及記錄變更。
  • 導覽作業會導致 DOM 變更。

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

Chrome 如何實作軟性導覽？

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

  • 系統偵測到每次軟性導覽後，都會發出 soft-navigation PerformanceTiming 事件。
  • 在導致有意義的繪製作業的互動後，系統會發出新的 interaction-contentful-paint。如果繪製作業跨越軟性導覽，這項事件可用於測量軟性導覽的最大內容繪製 (LCP)。請注意，原始實作會重設 largest-contentful-paint 指標，允許重新發出，但我們已採用這個替代方法，不僅簡化作業，也擴大未來範圍。
  • 系統會為每個效能時間 (first-paint、first-contentful-paint、largest-contentful-paint、interaction-contentful-paint、first-input-delay、event 和 layout-shift) 新增 navigationId 屬性，對應事件相關的導覽項目，以便計算最大內容繪製 (LCP)、累計版面配置位移 (CLS) 和下次彩繪互動 (INP)，並歸因至正確的網址。

這些變更可讓系統根據每次網頁瀏覽評估網站使用體驗核心指標和部分相關診斷指標，但請注意，這項功能有幾項細微差異。

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

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

  • CLS 和 INP 指標可能會依軟性導覽網址劃分，而不是在整個網頁生命週期內測量。
  • largest-contentul-paint 項目已在互動中完成，因此只用於測量初始「硬性」導覽 LCP，不需要額外邏輯來變更測量方式。
  • 新的 interaction-contentful-paint 指標會從互動發出，可用於評估軟性導覽的 LCP。
  • 如要將軟性導覽歸因於正確的網址，您可能需要在應用程式程式碼中，使用這些項目考量成效項目的新 navigationID 屬性。
  • 並非所有使用者都支援這項軟體導覽 API，尤其是使用舊版 Chrome 和其他瀏覽器的使用者。請注意，部分使用者可能不會回報軟性導覽指標，即使回報網站使用體驗核心指標也一樣。
  • 這項實驗性新功能預設為停用，因此網站應測試這項功能，避免產生非預期的副作用。

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

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

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

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

開發人員可以在 chrome://flags/#soft-navigation-heuristics 中開啟「Experimental Web Platform features」(實驗性網頁平台功能) 旗標，或在啟動 Chrome 時使用 --enable-features=SoftNavigationHeuristics:mode/advanced_paint_attribution 指令列引數，啟用這項功能。

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

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

如何評估軟性導覽？

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

回報軟性導覽

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

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

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

針對適當的網址回報指標

由於軟性導覽只能在發生後查看，因此部分指標必須在這個事件發生後完成，然後針對先前的網址回報，因為目前的網址會反映新網頁的更新網址。

適當 PerformanceEntry 的 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;

請使用這個 pageUrl 回報正確網址的指標，而不是過去可能使用的網址。

取得軟體導覽的 startTime

導航開始時間的取得方式類似：

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

startTime 是啟動軟體導覽的初始互動時間 (例如點選按鈕)。

所有效能時間 (包括軟性導覽的時間) 都會以初始「硬性」網頁導覽時間為準。因此，您需要軟性導覽開始時間，才能根據這個時間，為軟性導覽載入指標時間 (例如 LCP) 建立基準。

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

如要納入軟性導覽指標項目，您需要在效能觀察工具的 observe 呼叫中加入 includeSoftNavigationObservations: true。

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

隨著 API 的最新變更，includeSoftNavigationObservations 標記已不再必要，日後可能會移除，但目前除了在 Chrome 中啟用軟性導覽功能外，還需要在效能觀察工具層級明確選擇加入。

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

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'interaction-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

傳統上，部分指標是在整個網頁生命週期中進行評估，例如 LCP 可能會變更，直到發生互動為止。在離開頁面之前，CLS 和 INP 都可以更新。因此，每次發生新的軟性導覽時，每個「導覽」(包括原始導覽) 可能都需要完成前一頁的指標。也就是說，初始「硬」導覽指標可能會比平常更早完成。

同樣地，開始評估這些長期指標的新軟性導覽指標時，指標需要「重設」或「重新初始化」，並視為新指標，不會記憶先前「網頁」設定的值。

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

系統會從 interaction-contentful-paint 計算軟性導覽的 LCP，且只會測量新的繪製作業。這可能會導致不同的 LCP，例如從該軟式導覽的冷載入到軟式載入。

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

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

如何評估 TTFB？

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

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

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

未來我們可能會支援更精確的方式，瞭解哪個要求是軟體導覽的「導覽要求」，並能更精確地測量 TTFB。但這不屬於目前的實作項目。

如何評估新舊成效？

在實驗期間，建議您繼續以目前的方式，根據「硬性」網頁導覽測量網站使用體驗核心指標，與 CrUX 測量及回報的資料相符，因為 CrUX 是網站使用體驗核心指標計畫的官方資料集。

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

因此，就 LCP 而言，這表示舊方法只會考慮 largest-contentful-paint 項目，新方法則會考慮 largest-contentful-paint 和 interaction-contentful-paint 項目。

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

使用 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';

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 程式庫會回報下列軟性導覽指標：

指標 詳細資料
TTFB 回報為 0。
FCP 系統只會回報網頁的第一個 FCP。
LCP 下一個最大內容繪製的時間，相對於軟性導覽的開始時間。系統不會考量先前導覽中呈現的現有繪製作業。因此 LCP 會 >= 0。與往常一樣，系統會在互動發生時或網頁進入背景時回報這項指標，因為只有在這些情況下，系統才能完成 LCP。
CLS 導航時間之間最大的班次時間差。與往常一樣，只有在網頁進入背景時，系統才能完成 CLS 計算。如果沒有輪班，系統會回報值 0。
INP 導覽時間之間的 INP。與往常一樣，系統會在互動發生時或網頁進入背景時回報這項指標，因為只有在這些情況下，系統才能完成 INP 計算。如果沒有任何互動，系統不會回報 0 值。

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

這項軟性導覽實驗就是實驗，我們想先評估這些啟發式方法，看看是否能更準確地反映使用者體驗，再決定是否將其納入網站使用體驗核心指標計畫。我們對這項實驗的可能性感到非常興奮，但無法保證這項實驗何時或是否會取代目前的評估方式。

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

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

如果這項實驗成功，我們還需要決定如何在 CrUX 中回報軟性導覽。系統不一定會以處理目前「硬性」導覽的方式處理這些導覽。

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

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

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

意見回饋

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

變更記錄

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

結論

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

特別銘謝

縮圖圖片來源：Jordan Madrid 發表於 Unsplash

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