嘗試測量軟導覽

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 會變更部分成效指標的回報方式：

完成這些變更後，系統就會依網頁瀏覽方式評估 Core Web Vitals (和部分相關聯的診斷指標)，但其中有一些細微差異需要納入考量。

在 Chrome 中啟用軟導覽功能會有哪些影響？

以下是網站擁有者在啟用這項功能後需考量的一些變更：

  • 針對軟性導覽，可重新發出其他 FP、FCP 和 LCP 事件。Chrome 使用者體驗報告 (CrUX) 會忽略這些額外的值，但這可能會影響網站上所有即時使用者評估 (RUM) 監控作業。如對上述評估影響有任何疑問，請洽詢您的 RUM 供應商。請參閱這篇文章，瞭解如何評估 Core Web Vitals 以建立軟導覽。
  • 您可能需要在應用程式的程式碼中，使用這些項目對效能項目的新 (和選用的) navigationID 屬性。
  • 只有以 Chromium 為基礎的瀏覽器支援這項新模式。雖然許多新指標都只能在以 Chromium 為基礎的瀏覽器中使用，但某些 (FCP、LCP) 也可在其他瀏覽器中使用，但不是每個人都會升級至最新版的 Chromium 瀏覽器。因此請注意，有些使用者可能不會回報軟導覽指標。
  • 網站是預設為不啟用的實驗性新功能，因此網站應測試這項功能，確保不會產生任何其他非預期的副作用。

如要進一步瞭解如何評估軟導覽的指標，請參閱「根據網頁體驗導覽評估 Core Web Vitals」一節。

如何在 Chrome 中啟用軟導覽功能？

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

開發人員只要開啟 chrome://flags/#enable-experimental-web-platform-features 的「實驗性 Web Platform 功能」旗標，或在啟動 Chrome 時使用 --enable-experimental-web-platform-features 指令列引數，即可啟用這項功能。

如何評估軟導覽？

啟用軟導覽實驗後，系統會照常使用 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)。

依系統性導覽評估 Core Web Vitals

如要納入軟導覽指標項目，您需要在效能觀察器的 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，直到頁面離開頁面為止。因此每個「導覽」區塊(包括原始導覽) 需要完成前一頁的指標，因為每次發生新的軟式導覽時，都可能需要完成。這表示一開始的「困難」導航指標可能會提早完成。

同樣地，當您開始為這些長效指標的新版軟導覽開始評估指標時，就必須「重設」指標。或「重新初始化」並視為新指標，但不會產生先前「網頁」所設定的值記憶體。

Google 如何處理導覽間保持相同內容的內容？

使用軟導覽模式的 FP、FCP 和 LCP 只會測量新顏料。這可能會導致不同的 LCP，例如從軟導覽的冷載入到軟載入。

舉例來說，假設網頁上有一個大型橫幅圖片是 LCP 元素，但下方的文字會隨著系統柔性導覽而改變。初次載入網頁時，會將橫幅圖片標示為 LCP 元素，並據此設定 LCP 時間。對後續的軟導覽來說，下方文字會是柔性導覽後繪製的最大元素，並成為新的 LCP 元素。不過，如果新網頁是透過軟體導覽網址的深層連結載入，該橫幅圖片會是新的畫作，因此才符合 LCP 元素的資格。

如範例所示，軟體導覽 LCP 元素的回報方式取決於網頁載入的方式，這和在網頁下方載入錨點連結的網頁一樣，可能會導致不同的 LCP 元素。

如何測量 TTFB？

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

如果是軟式導覽，實在是比較棘手的問題。我們是否應評估對新網頁提出的第一個要求？如果應用程式中已經有所有內容，而且沒有其他要求，該怎麼辦？如果已預先透過預先擷取發出要求，該怎麼辦？如果要求從使用者的角度來看與軟導覽無關 (例如 Analytics 要求)，會發生什麼情況？

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

未來我們會支援更精準的方式，找出軟導覽的「導航要求」為何。還能取得更準確的 TTFB 測量結果但不屬於目前的實驗。

如何評估新舊手機？

在實驗期間，建議您根據「硬性」標準，繼續以目前的方式評估 Core Web Vitals來比對 CrUX 評估及記錄為「Core Web Vitals」計畫的官方資料集。

除了上述測試方式之外，您也應評估這些軟性導覽，以便瞭解日後如何評估這些情形，並有機會向 Chrome 團隊提供意見，說明這項實作方式的實際運作情形。這將協助您和 Chrome 團隊在未來打造 API。

如要評估這兩種情況，請務必瞭解在軟導覽模式中可能發出的新事件 (例如多個 FCP 和其他 LCP 事件)，並在適當時機完成這些指標以妥善處理這些事件，同時忽略僅適用於軟體導覽的未來事件。

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

指標 詳細資料
文字轉語音 回報為 0。
FCP 系統只會回報網頁的第一個 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 中分別製作這類軟體導覽機制，或是在計算特定網頁或一組網頁的 Core Web Vitals 時，採用加權計算。隨著經驗法則的發展，我們也可以完全排除部分載入軟性導覽。

這個團隊專注於經驗法則和技術執行，協助我們判斷這項實驗的成效，因此尚未就這些要素做出決定。

意見回饋

我們正積極尋求關於這項實驗的意見回饋，歡迎前往下列位置：

變更記錄

這個 API 仍在實驗階段，因此會比穩定版 API 進行多項變更。詳情請參閱電子導覽啟發式變更記錄。

結論

軟體式導覽實驗是一項有趣的做法，有助於改善 Core Web Vitals 計畫，以評估新世代網路中指標未達到的常見模式。儘管這項實驗才剛起步，現在還有許多值得期待的功能，但還有許多進步空間，讓廣大的網路社群能從中進行實驗，是非常重要的一步。收集這項實驗的意見回饋，是這項實驗的重要一環，因此我們強烈建議對這項開發有興趣的使用者運用這個機會打造 API，確保該 API 確實代表我們希望以這項做法評估的內容。

特別銘謝

縮圖圖片是由 Jordan Madrid 於 Unsplash 提供