嘗試測量軟導覽

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

自從推出網站以來，Core Web Vitals 計畫持續評估網站的實際使用者體驗，而非網站的建立或載入方式背後的技術細節。三項 Core Web Vitals 指標是以以使用者為中心的指標建立而成，是與現有技術指標 (例如 DOMContentLoaded 或 load) 評估而來的結果，這些指標先前經過評估，而這些指標通常與使用者感受到網頁效能無關。因此，用來建立網站的技術應該不會影響提供該網站效能的評分。

實際上，其實際難度總是比理想來得有點難，而且熱門的單頁應用程式架構也尚未完全受到 Core Web Vitals 指標支援。這些網路應用程式會使用所謂的「軟瀏覽」，而不是在使用者瀏覽網站時載入不同的網頁，而它們的網頁內容則由 JavaScript 變更。在這些應用程式中，傳統的網頁架構會改變網址，並將先前的網址推送到瀏覽器記錄中，讓返回和前進按鈕都能按使用者預期的方式運作。

許多 JavaScript 架構使用這種模型，但方式各有不同。由於瀏覽器傳統會解讀為「網頁」以外的語言，因此要進行評估並不容易：在「目前」網頁上，使用者與這次互動 (而非視為「新」網頁) 互動之間所繪製的線條為何？

Chrome 團隊已考慮這項挑戰一段時間，目前正考慮將「軟導覽」的定義標準化，並指定網站體驗核心指標的評估方式，做法與在傳統多網頁架構 (MPA) 中實作的網站類似。雖然這在初期開發階段，但該團隊已準備好讓更多實作內容可供網站試用。這樣一來，網站就能繼續提供意見回饋。

什麼是軟導覽？

「軟導覽」的定義如下：

  • 導覽是由使用者動作啟動。
  • 導覽介面對使用者顯示的網址有所改變，記錄也有所變更。
  • 導覽會導致 DOM 發生變更。

對某些網站而言，這些經驗法則可能會導致誤判 (使用者不會真的認為「導覽」發生了「導覽」事件) 或偽陰性 (使用者認為發生「導覽」行為，但即使不符合這些條件)。歡迎前往軟導覽規格存放區提供有關經驗法則的意見回饋。

Chrome 如何實作軟導覽？

啟用軟導覽經驗法則 (詳情請參閱下一節) 後，Chrome 會變更部分成效指標回報方式：

這些異動可幫助系統評估網站體驗核心指標，以及部分相關的診斷指標，不過仍須考量一些細微差異。

在 Chrome 中啟用軟導覽會造成什麼影響？

啟用這項功能後，網站擁有者必須考慮下列事項：

  • 如果是軟式導覽，系統可能會重新發出其他 FP、FCP 和 LCP 事件。雖然 Chrome 使用者體驗報告 (CrUX) 會忽略這些額外值，但這可能會影響網站的任何即時使用者評估 (RUM) 監控。如果您對這些測量結果有任何疑慮，請洽詢您的 RUM 供應商。請參閱「評估軟導覽網站的網站體驗核心指標」一節。
  • 對於效能項目，您可能需要使用這些項目的最新 (和選擇性) navigationID 屬性。
  • 只有以 Chromium 為基礎的瀏覽器才支援這種新模式。雖然許多新指標都僅適用於以 Chromium 為基礎的瀏覽器，但部分指標 (FCP、LCP) 可在其他瀏覽器中使用，而並非所有使用者都能升級至以 Chromium 為基礎的最新版瀏覽器。因此請注意，部分使用者可能不會回報軟瀏覽指標。
  • 我們將對預設未啟用的實驗性功能進行測試，以確保不會產生任何其他非預期的副作用。

如要進一步瞭解如何評估軟導覽指標，請參閱「依軟導覽評估網站體驗核心指標」一節。

如何啟用 Chrome 的軟瀏覽？

Chrome 預設不會啟用軟導覽，但只要明確啟用這項功能，即可在 Chrome 110 中進行實驗。

如果您是開發人員，可以在 chrome://flags/#enable-experimental-web-platform-features 中開啟「實驗功能 Web Platform 功能」旗標，或是在啟動 Chrome 時使用 --enable-experimental-web-platform-features 指令列引數。

如果網站想讓所有訪客使用這項功能，並看見 Chrome 117 版本的來源試用，則可先申請試用，並在 HTML 或 HTTP 標頭中加入包含來源試用權杖的中繼元素，藉此啟用 Chrome 117 的來源試用功能。詳情請參閱「開始使用來源試用」一文。

網站擁有者可以選擇在網頁中加入來源試用，包括所有使用者或部分使用者。請留意上述影響一節，瞭解這項異動會如何變更指標的回報方式，尤其是針對大量使用者啟用此來源試用的情況。請注意，無論此軟導覽設定為何，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});

除了在 Chrome 中啟用軟導覽功能以外，還需要 observe 方法的額外 includeSoftNavigationObservations 旗標。在效能觀察器層級明確選擇加入的項目，是確保現有效能觀察器不會因這些額外項目感到意外，因為在嘗試評估軟體式導覽網站體驗核心指標時，必須將一些額外考量納入考量。

系統仍會依據原本的「困難」導覽開始時間傳回時間。因此，如要計算軟導覽的 LCP，您必須利用 LCP 時間，並如前所述，減去適當的軟導覽開始時間，以便取得相對於軟導覽的時間。以 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: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

一般而言，系統會在網頁的整個生命週期內測量一些指標，例如 LCP 可能會在互動發生前變動。CLS 和 INP 可以更新直到頁面離開頁面為止。因此，每次發生新的軟式導覽時，每個「導覽」(包括原始導覽) 可能需要完成前一個網頁的指標。這表示初始的「困難」導覽指標可能會提早完成。

同樣地，在開始評估這些長期指標的全新軟導覽指標指標時，指標必須「重設」或「重新初始化」並視為新指標，且不會記憶體與先前「網頁」所設定的值相同。

應如何處理在瀏覽動作之間保持不變的內容？

軟導覽的 FP、FCP 和 LCP 只會測量新的繪製效果。這可能會導致不同的 LCP，例如從冷導覽的冷載入到輕微載入。

舉例來說，假設有一個包含 LCP 元素的大型橫幅圖片，但該元素底下的文字會隨著每次軟導覽改變而改變。初次載入網頁時，會將橫幅圖片標記為 LCP 元素，並據此設定 LCP 時間。至於後續的軟式導覽，下方的文字會是您在軟導覽後繪製的最大元素，且將成為新的 LCP 元素。不過，如果新網頁透過軟導覽網址的深層連結載入，橫幅圖片就會是新的繪製方式，因此可被視為 LCP 元素。

如這個範例所示，軟導覽的 LCP 元素回報方式會根據網頁載入的方式而異，就像在網頁較下方的錨點連結載入網頁時產生不同的 LCP 元素一樣。

如何評估 TTFB？

傳統網頁載入所需的時間 (TTFB) 代表系統傳回原始要求第一個位元組的時間。

因此，在柔軟瀏覽的情況下，這會是一個較棘手的問題。我們應該評估新網頁發出的第一個要求嗎？如果應用程式中的內容均已存在，沒有其他要求，該怎麼辦？如果該要求已透過預先擷取功能提前提出，該怎麼辦？如果從使用者的角度來看，如果要求與軟導覽導覽無關 (例如，這是數據分析要求)，該怎麼辦？

而更簡單的做法是，針對軟瀏覽回報 TTFB 為 0，方法與我們建議執行往返快取還原的方式類似。這是軟導覽目前使用的 web-vitals 程式庫方法。

未來，我們可能會支援更精準的方式，判斷哪個要求屬於軟導覽的「導覽要求」，並且能夠進行更精準的 TTFB 測量。但目前實驗還不參與這些實驗。

如何評估新舊客戶？

在這個實驗期間，建議繼續以目前的方式評估網站體驗核心指標，根據「硬性」網頁瀏覽指標，符合 CrUX 評估資料並將其列為 Core Web Vitals 計畫的官方資料集。

因此，建議您一併評估非網頁導覽元件，以便瞭解日後的評估方式，並讓您有機會向 Chrome 團隊提供意見，瞭解這項實作方式的實際運作情形。這將有助於你和 Chrome 團隊日後規劃 API。

如要評估這兩種情況，您必須瞭解在軟導覽模式下可能會發出的新事件 (例如多個 FCP 和其他 LCP 事件)，並在適當時機確定這些指標，並妥善處理這些事件，同時忽略日後僅適用於軟導覽事件的未來事件。

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

如要掌握所有細微差異，最簡單的方法是在獨立的 soft-navs branch 中使用 web-vitals JavaScript 程式庫，這個程式庫在 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 web-vitals 程式庫目前只會回報網頁的第一個 FCP。
LCP 下一個最大內容繪製的時間 (相對於軟導覽開始時間)。從上一個導覽畫面顯示的現有繪製內容不會納入計算。因此 LCP 會是 >= 0。就像往常一樣，當使用者與網頁互動或網頁在背景執行時，系統才會回報這個問題，因為只有當 LCP 處於最終狀態時。
CLS 導航時間之間偏移的最大視窗。和往常一樣，只有在網頁在背景執行時，才能完成 CLS 測試。如果沒有偏移，則會回報 0。
INP 導覽時間之間的 INP。和往常一樣，我們會在發生互動或網頁在背景執行時回報 INP 最終結果。如果沒有互動，系統就不會回報 0 值。

這些變更是否會納入 Core Web Vitals 評估範圍？

而這項微瀏覽實驗正是這樣的實驗。我們想要評估經驗法則，並確定這些經驗法則能更準確反映使用者體驗，再決定是否將其納入 Core Web Vitals 計畫。對於這項實驗的可能，我們非常期待，但無法保證這項實驗未來是否會取代目前的評估標準。

我們重視網頁開發人員針對實驗的意見回饋、使用的經驗法則，以及你認為實驗體驗是否更準確地反映體驗。軟導覽 GitHub 存放區是提供回饋意見的最佳平台，不過 Chrome 實作時發生的個別錯誤應透過 Chrome Issue Tracker 回報。

CrUX 系統如何回報軟導覽？

CrUX 系統記錄的軟式導覽量為何，這項實驗結果是否還需有所決定)。但這不一定是系統在處理時，會將物件視為目前的「困難」瀏覽。

在某些網頁中，對使用者而言，軟導覽與完整載入網頁幾乎完全相同，使用單頁應用程式技術只是實作細節。有些則較為像部分額外內容的一部分。

因此，我們可能會決定在 CrUX 中分別回報這些軟性導覽，或在計算某個或一組網頁的「網站體驗核心指標」時，為其加權計算。我們或許也能隨著經驗法則演變，將部分載入的柔和導覽完全排除。

目前，我們的團隊將重點放在經驗法則和技術實作，這有助於我們評估這項實驗的成效，因此未針對這些決策做出任何決定。

意見回饋：

我們目前正積極在下列位置徵求有關這項實驗的意見：

變更記錄

由於這個 API 仍處於實驗階段，因此會進行多項變更，而非穩定版 API。詳情請參閱軟導覽經驗法則。

結論

想要瞭解網站體驗核心指標計畫如何改進現代網頁中的常見模式，但這項實驗目前並未納入我們的指標，那麼軟導覽實驗是一項令人振奮的做法。雖然這項實驗還在初期階段，還有很多事要做，但截至目前為止，讓廣大網路社群瞭解相關進展至關重要。收集這項實驗的意見回饋是實驗中另一項重要的一環，因此強烈建議有意參加這項實驗的人員善用這次機會，協助打造能代表實驗目標的 API。

特別銘謝

Jordan Madrid 在 Unsplash 網站上提供的縮圖