嘗試測量軟導覽

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

自推出以來，Core Web Vitals 計畫一直致力於評估網站的實際使用者體驗，而非網站建立或載入方式背後的技術細節。這三項 Core Web Vitals 指標是以使用者為中心的指標，與現有的技術指標 (例如 DOMContentLoaded 或 load) 不同，後者測量時間點與使用者對網頁效能的感受通常無關。因此，只要網站效能良好，建構網站所用的技術不應影響評分。

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

許多 JavaScript 架構都會使用這個模型，但每個架構的做法都不同。由於這不是瀏覽器傳統上所理解的「網頁」，因此一直很難評估這類互動：在目前網頁上的互動與新網頁之間，究竟有何差異？

Chrome 團隊一直在思考如何解決這個問題，並希望將「軟性導覽」的定義標準化，並且針對這類導覽方式，以類似於傳統多頁架構 (MPA) 中網站的評估方式，評估網站使用體驗核心指標。雖然仍處於初期階段，但團隊已準備好讓網站更廣泛地採用已導入的功能，進行實驗。這樣網站就能針對目前的做法提供意見。

什麼是軟性導覽？

我們對軟性導覽的定義如下：

  • 導覽是由使用者動作啟動。
  • 導覽結果會導致使用者看到網址變更，並且變更歷史記錄。
  • 導覽結果會導致 DOM 變更。

對於某些網站，這些推測法可能會導致偽陽性 (使用者不會真的認為「導覽」已發生) 或偽陰性 (使用者認為「導覽」已發生，但不符合這些條件)。歡迎您前往軟性導覽規格存放區，針對這項規則提供意見回饋。

Chrome 如何實作軟性導覽功能？

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

  • 系統偵測到每個軟性導覽功能後，就會觸發 soft-navigation PerformanceTiming 事件。
  • Performance API 將提供 soft-navigation 時間項目的存取權，如 soft-navigation PerformanceTiming 事件所發出。
  • 系統會重設「First Paint (FP)」、「First Contentful Paint (FCP)」、「Largest Contentful Paint (LCP)」指標，並在下次出現這類情形時重新發出。(注意：FP 和 FCP 並未實作)。
  • 系統會在與事件相關聯的導覽項目對應的每個效能時間 (first-paint、first-contentful-paint、largest-contentful-paint、first-input-delay、event 和 layout-shift) 中加入 navigationId 屬性，以便計算累計版面配置位移 (CLS) 和互動至下次繪製 (INP)。

這些變更可讓 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 標記。在效能觀察器層級明確選擇加入，是為了確保現有的效能觀察器不會受到這些額外項目的影響，因為在嘗試評估軟性導覽的 Core Web Vitals 時，需要考量一些額外因素。

系統仍會根據原始「硬性」導航開始時間傳回時間。舉例來說，如要計算軟性導覽的 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？

傳統網頁載入作業的第 1 個位元組時間 (TTFB) 代表原始要求的首個位元組傳回時間。

對於軟性導航來說，這項問題就比較棘手。是否應評估針對新頁面提出的第一個要求？如果應用程式中已存在所有內容，且沒有其他要求，該怎麼辦？如果已預先透過預先擷取發出要求，該怎麼辦？如果要求與使用者角度的軟性導覽無關 (例如分析要求)，會發生什麼情況？

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

日後，我們可能會支援更精確的方式，以便瞭解哪些要求是軟性導覽的「導覽要求」，並提供更精確的 TTFB 評估。但這並非目前實驗的一部分。

如何評估舊版和新版？

在這個實驗期間，建議您繼續以目前的方式，根據「硬式」網頁導覽來評估 Core Web Vitals，以便與 CrUX 評估和回報的資料相符，並做為 Core Web Vitals 計畫的官方資料集。

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

如要同時評估這兩項指標，您必須留意軟式導覽模式可能會發出的全新事件 (例如多個 FCP 和其他 LCP 事件)，並在適當時間完成這些指標的計算，同時忽略只適用於軟式導覽的未來事件。

使用 web-vitals 程式庫評估軟性導覽的 Core 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 值。

這些變更是否會納入 Core Web Vitals 評估資料？

這項軟性導覽實驗就是如此，我們希望評估這項經驗法則，看看這項指標是否能更準確地反映使用者體驗，再決定是否將其納入 Core Web Vitals 計畫。我們很期待這項實驗的可能性，但無法保證這項實驗是否會取代目前的評估方式，也無法保證何時會取代。

我們非常重視網頁程式開發人員對於實驗的意見回饋、使用的啟發，以及你覺得更能準確反映使用者體驗。軟性導覽 GitHub 存放區是提供這類意見回饋的最佳位置，不過，Chrome 實作這項功能時發生的個別錯誤，應透過 Chrome 問題追蹤器提出。

軟性導覽功能在 CrUX 中會如何回報？

如果這項實驗成功，我們還需要決定如何在 CrUX 中回報軟性導覽功能。這類導覽可能不會與目前的「硬式」導覽相同。

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

因此，我們可能會決定在 CrUX 中分別製作這類軟體導覽機制，或是在計算特定網頁或一組網頁的 Core Web Vitals 時，採用加權計算。隨著經驗法則的發展，我們也可以完全排除部分載入軟性導覽。

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

意見回饋

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

變更記錄

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

結論

軟性導覽實驗是 Core Web Vitals 計畫的創新做法，可評估現今網路上缺少指標的常見模式。雖然這項實驗功能仍處於初期階段，且仍有許多工作要完成，但讓更多網友參與測試，也是重要的一步。收集這項實驗的意見回饋，是這項實驗的重要一環，因此我們強烈建議對這項開發有興趣的人員運用這個機會，協助打造 API，確保該 API 確實代表我們希望以這項做法進行評估。

特別銘謝

縮圖圖片來源：Unsplash 上的 Jordan Madrid