發布日期：2026 年 4 月 20 日
Chrome 預計在今年稍晚推出我們先前實驗的 Soft Navigations API。為此，我們將在 Chrome 147 到 Chrome 149 期間，再進行一次來源試用。本次試用計畫會根據先前試用計畫的意見回饋，調整 API 的最終預期樣貌。我們建議對這項功能感興趣的網站擁有者，在 API 發布前進行最終測試，確認 API 的最終樣貌符合預期。
什麼是軟性導覽？
「軟性導覽」是指 JavaScript 攔截導覽 (例如點選連結)，並更新現有網頁上的內容，而不是載入新網頁，但網址列仍會更新網址。對使用者而言，這些導覽方式與傳統導覽方式相同，但從瀏覽器的角度來看，網頁仍是原始網頁。
需要 Soft Navigation API
軟性導覽 API 是建議使用的 API，可偵測單頁應用程式 (SPA) 網站使用的軟性導覽。由於軟性導覽不會實際導覽至其他網頁，因此 JavaScript 必須手動管理通常會在導覽時發生的特定動作。您可以使用目前的 API 執行某些動作，例如管理瀏覽記錄。不過，您無法對這些導覽執行其他動作，例如評估網站體驗核心指標。
Soft Navigation API 可觀察軟性導覽。雖然啟動軟性導覽的 JavaScript (通常是 JavaScript 架構) 會知道何時發生導覽，但網站使用的其他 JavaScript (例如 Analytics 指令碼) 和瀏覽器本身不會知道。
網站使用體驗核心指標和單頁應用程式
Soft Navigation API 的主要用途之一，是讓您評估 SPA 的網站體驗核心指標。瀏覽器和網站擁有者都會使用實際使用者監控 (RUM) 解決方案，測量網站使用體驗核心指標，並顯示在 Chrome 使用者體驗報告等工具中。
JavaScript 架構可評估 SPA 的部分網站體驗核心指標。特別是 Interaction to Next Paint (INP) 和累計版面配置位移 (CLS)，都是以可跨任何時間範圍測量的基本項目 (分別是 Event Timing API 和 Layout Instability API) 為基礎，用來計算這些指標。不過，其他指標 (例如最大內容繪製 (LCP)) 只會由瀏覽器發出，且會根據網頁導覽和互動完成時最終確定。
API 如何評估 SPA 的網站體驗核心指標
Soft Navigation API 導入了兩項新的效能項目：
- 當所有軟性導覽需求都符合時，系統會發出
SoftNavigationEntry項目。包括導致軟性導覽的互動interactionId、專屬navigationId，以及設為新網址的name和各種繪製時間，可用於評估軟性導覽的首次顯示內容所需時間。 InteractionContentfulPaint項目：可評估互動後多個越來越大的內容繪製，以評估軟性導覽的 LCP。
您可以使用 PerformanceObserver，分別透過 soft-navigation 和 interaction-contentful-paint 類型觀察這些新項目。
此外，API 也會擴充每個 largest-contentful-paint、interaction-contentful-paint、event-timing 和 layout-shift 效能項目 (以及其他項目)，加入代表項目所屬導覽的 ID navigationId。由於 PerformanceObserver 要等到網頁閒置時才會觀察效能項目，因此從建立效能項目的事件發生到您觀察到該項目，可能會經過一段時間。如果網頁非常忙碌 (例如在軟性導覽期間)，就更是如此。這項 navigationId 值有助於將項目歸因至正確的導覽。
部分 interaction-contentful-paint 項目可能會在導覽前發生，部分則會在導覽後發生。不必追蹤所有可能導致軟性導覽的繪製作業，soft-navigation 項目會包含 largestInteractionContentfulPaint 項目，這是截至目前為止的最大繪製作業。
這些指標可共同評估下列 Core Web Vitals：
- LCP：針對初始載入網頁使用
largest-contentful-paint，並針對軟性導覽使用新的interaction-contentful-paint和soft-navigation項目。 - CLS：使用
layout-shift項目，並根據軟性導覽的soft-navigation項目進行切片。 - INP：使用
event項目，並根據軟性導覽的soft-navigation項目進行切片。 - FCP：使用
first-contentful-paint進行初始載入網頁，並使用新soft-navigation項目中的繪製時間詳細資料進行軟性導覽。
詳情請參閱軟性導覽說明文件。
如何觸發軟性導覽？
發生下列情況時，Soft Navigation API 會觸發軟性導覽：
- 發生使用者互動，
- … 導致使用者可見的內容繪製，
- 並更新網址。
API 採用這種做法，而不是讓 JavaScript 架構「發出」軟性導覽，或以 Navigation API 為基礎建構，原因有二：
- 首先，這包括所有現有 SPA 網站，且這些網站不需要進行任何變更。
- 其次，無論架構或開發人員如何處理導覽，都能確保對軟性導覽的定義有一致的理解。
即使沒有使用者互動或使用者視為導覽的 DOM 更新，架構或開發人員仍可更新軟性導覽的網址。他們也可以在不同時間更新網址：互動開始時、互動完成時 (僅限此時)，或介於兩者之間的任何狀態。
在瀏覽器中建構軟性導覽偵測功能，可建立標準定義，大規模評估軟性導覽的 Core Web Vitals，並大規模比較這些評估結果，不必依賴架構和開發人員的選擇。
架構和開發人員也可以忽略 Soft Navigations API，並使用基礎的 Event Timing、Layout Instability API 和新的 InteractionContentfulPaint 效能項目，視需要評估其他效能指標。不過，我們建議使用 API 評估 Core Web Vitals，以便在網站和工具中進行一致的評估。
需要協助測試 Soft Navigation API
我們需要您協助測試 Soft Navigations API，判斷 API 是否符合您對軟性導覽發生時機的預期。您認為發生了軟性導覽，但 API 未回報嗎？反之，API 是否會過度回報您不認為是導覽的導覽？
自上次來源試用以來有什麼變化
最新疊代的主要變更，是將 InteractionContentfulPaint 與軟性導覽功能分離，以便為該效能項目啟用其他用途，並將額外的 largestInteractionContentfulPaint 屬性新增至 SoftNavigationEntry。
從網站的角度來看，API 現在也包含 replaceState 做為軟性導覽，因為我們收到您的意見，指出在許多情況下，這項導覽非常重要。如果 API 無法辨識軟性導覽，歡迎回報其他案例。
我們也對實作方式進行了無數其他改良。如要瞭解最新疊代版本有哪些變更，請參閱軟體導覽異動記錄，查看所有變更的詳細記錄。
我們希望這項 API 盡可能實用，並願意進一步調整，以達成這個目標。在 API 發布前，以及網站開始依賴實作項目之前，變更 API 實作項目會容易得多。因此，我們邀請 SPA 開發人員和有興趣評估這類網站網頁效能的使用者測試這項 API，並提供意見回饋。
如何測試
您可以使用 Chrome 旗標或指令列選項，在本機測試 API。此外，您也可以透過來源試用計畫在實際環境中測試這項功能 (進一步瞭解來源試用計畫)。
如要進一步瞭解 API 的技術細節，特別是如何評估 Core Web Vitals，請參閱說明文件或 GitHub 存放區。
此外，GitHub 和 npm 也提供實驗性的網頁指標程式庫軟體導覽版本。
如要進行較簡單的測試，Chrome 開發人員工具的「效能」面板會顯示效能追蹤記錄中的軟性導覽 (Chrome 145 以上版本)，即使未啟用這項功能也一樣：
意見回饋
如要提供 API 相關意見，請在 GitHub 上提出問題；如要回報 Chromium 實作中的錯誤，請前往 Chrome 的問題追蹤器。如果不確定意見屬於哪個類別，也別太擔心，我們很樂意在任一平台收到意見回饋，並會在這兩個平台分類問題，然後重新導向至正確位置。