新的軟體導覽來源試用

Barry Pollard
Michal Mocny

發布日期：2025 年 7 月 31 日

Chrome 將從第 139 版開始，推出新的來源試用，供您試用我們先前實驗的 Soft Navigations API。網站可透過這項來源試用計畫，在網站上讓實際使用者試用 API，進行現場測試並向 Chrome 團隊提供意見回饋。

什麼是軟性導覽？

如果 JavaScript 攔截導覽 (例如點選連結)，並更新現有網頁上的內容，而不是載入新網頁，然後更新網址列中的網址 (並提供記錄狀態，允許返回和前進的軟性導覽)，就是軟性導覽。對使用者而言，這些看起來與傳統導覽相同，但就瀏覽器而言，網頁仍是原始網頁。

為何需要 Soft Navigation API

軟體導覽 API 是一項提案 API，可根據啟發式方法偵測單頁應用程式 (SPA) 網站使用的所謂「軟體導覽」。由於軟性導覽不會實際導覽至其他網頁，因此您必須透過 JavaScript 手動管理通常會在導覽時發生的特定動作。您可以使用目前的 API 執行某些動作，例如管理瀏覽記錄。不過，您無法對這些導覽執行其他動作，例如評估網站體驗核心指標。

Soft Navigation API 可觀察軟性導覽。啟動軟性導覽的 JavaScript (通常是 JavaScript 架構) 會知道何時發生導覽，但其他 JavaScript 和瀏覽器本身則不會知道。

網站使用體驗核心指標和單頁應用程式

Soft Navigation API 的主要用途之一，是讓您評估 SPA 的網站體驗核心指標。瀏覽器和實際使用者監控 (RUM) JavaScript 程式庫都會評估 Core Web Vitals，並在 Chrome 使用者體驗報告等工具中顯示。

JavaScript 架構可以評估 Core Web Vitals 的某些層面。特別是「Interaction to Next Paint (INP)」和「Cumulative Layout Shift (CLS)」，都是以原始值 (分別是 Event Timing API 和 Layout Instability API) 為基礎，可在任何時間範圍內進行評估，以計算 INP 和 CLS 指標。不過，由於瀏覽器會根據網頁導覽和互動回報並完成 Largest Contentful Paint (LCP)，因此 JavaScript 架構只能瞭解 SPA 的初始載入效能。

軟性導覽 API 如何評估 SPA 的 Core Web Vitals

Soft Navigation API 的第一個疊代版本會將軟式導覽啟發式方法與 LCP 重設作業配對。重設後，系統可以針對新內容繪製的軟性導覽重新發出 LCP，以便測量軟性導覽的這項指標。

這個最新疊代版本採用不同做法，將這些概念解耦為 Soft Navigation API 和新的 Interaction to Contentful Paint 效能項目。interaction-contentful-paint 項目會測量互動後的「有內容的繪製」。目前，這項指標只會針對軟性導覽發出，但如果針對所有互動啟用，除了 LCP 以外，還能用於其他潛在用途。

此外，API 也擴充了 largest-contentful-paint、interaction-contentful-paint、event-timing 和 layout-shift 的每個效能項目，加入項目所屬導覽的 ID。系統會在測量的事件發生後發出效能項目，通常是在閒置期間。也就是說，發出效能項目時，網址通常已變更。如果項目包含導覽，您就不必比對效能項目時間和軟性導覽項目時間，即可輕鬆評估指定網址的 Core Web Vitals。

為什麼要使用啟發式方法？

發生下列情況時，Soft Navigation API 會將其視為軟性導覽：

  • 發生以使用者為準的互動 (未經使用者互動而更新網址不算在內)
  • … 這會導致 DOM 修改和繪製
  • …並更新網址
  • 更新網址，包括變更記錄。

這個 API 採用的是啟發式方法，而不是允許 JavaScript 架構「發出」軟性導覽，或以 Navigation API 為基礎建構，因為這樣無論架構為何，或開發人員如何使用，都能一致瞭解軟性導覽的構成要素。

即使沒有使用者互動或 DOM 更新，架構或開發人員仍可更新軟性導覽的網址，而我們認為使用者會將此視為導覽。他們也可能在不同時間更新網址，例如在互動開始時、互動完成時，或是在這兩者之間的任何狀態。

與其依賴框架選擇，不如在瀏覽器中建立軟性導覽偵測機制，確立標準的「啟發式方法」(根據您在這項來源試用中提供的意見回饋)，這樣我們就能大規模評估 Core Web Vitals 的軟性導覽，並大規模比較這些評估結果。

架構和開發人員也可以忽略 Soft Navigations API 啟發式方法，並使用基礎的 Event Timing、Layout Instability 和 Interaction to Contentful Paint API，視需要測量其他成效指標，但我們建議使用啟發式方法測量 Core Web Vitals，以便跨網站進行測量。

需要協助測試 Soft Navigation API

我們需要協助測試 Soft Navigations API，確認啟發式演算法是否符合您對軟式導覽發生時機的預期。您認為發生軟性導覽時，API 是否有未回報的情況？反之，API 是否會重複導覽您認為不是軟性導覽的項目？

舉例來說，如果更新網址時使用 replaceState 而非新增記錄，或是發生非使用者啟動的導覽 (例如因逾時而登出)，就可能導致問題。這兩種情況都可解釋為不符合啟發式方法，Chrome 團隊很樂意不納入這些方法，但我們想聽聽網頁開發人員是否同意。如果啟發式方法似乎符合條件，但 API 仍無法辨識軟式導覽，請務必回報給我們。

此外，我們也想瞭解這項 API 和新的「Interaction to Contentful Paint」基本元素，是否能解決主要用途，也就是允許測量 SPA 的 Core Web Vitals。

我們希望 API 盡可能實用，因此在 API 發布前，以及網站開始依賴實作項目之前，更容易進行這類調整。因此，我們邀請 SPA 開發人員和有興趣評估這類網站網頁效能的使用者試用這項 API，並提供意見回饋。

如何測試

您可以使用 Chrome 旗標或指令列選項，在本機測試 API。此外，您也可以透過來源試用計畫在實際環境中測試。

如要進一步瞭解 API 的技術詳情，請參閱說明文件或 GitHub 存放區，特別是如何評估 Core Web Vitals。此外，我們也提供網頁指標程式庫的軟性導覽實驗版本。

意見回饋

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

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