採用 Chrome 使用者體驗報告的首次輸入延遲時間進行實驗

瑞克.維斯科尼 (Rick Viscomi)
Rick Viscomi

Chrome 使用者體驗報告旨在協助網路社群瞭解實際使用者效能的發布和進化程度。截至目前,我們對繪製和網頁載入指標 (例如首次顯示內容所需時間 (FCP) 和負載 (OL)) 指標,可以幫助我們瞭解網站「視覺化」的成效。自 2018 年 6 月版本起,我們會嘗試以使用者為中心的全新指標,著重在網頁的互動首次輸入延遲時間 (FID)。這項新指標有助於我們進一步瞭解回應式網站對使用者輸入內容的程度。

Chrome 最近以來源試用的形式提供 FID,這表示網站可選擇試用這項新的網路平台功能。同樣地,Chrome 使用者體驗報告也會將 FID 做為實驗指標提供,這表示在另一個「實驗」命名空間中的來源試用期間,將提供 FID。

FID 的評估方式

FID 到底是什麼?以下是首次輸入延遲時間公告文章中的定義:

「首次輸入延遲時間」(FID) 是指從使用者首次與網站互動 (即點選連結、輕觸按鈕或使用自訂 JavaScript 技術控制項) 到瀏覽器實際回應該互動所需的時間。

顯示主執行緒忙碌狀態如何延後回應使用者互動的動畫。

就像測量從有人按門鈴到出門的時間一樣。可能的原因有很多,例如,使用者可能離門太遠,或是對方無法快速移動。同樣地,網頁可能會忙於處理其他工作,或是使用者的裝置速度變慢。

透過 Chrome 使用者體驗報告探索 FID

市面上數百萬個來源提供的 FID 資料一個月,已經有許多有趣的洞見可供探索。讓我們來看看幾個查詢 如何從 BigQuery 的 Chrome 使用者體驗報告擷取這些洞察資訊

首先,請查詢 developers.google.com 的快速 FID 體驗百分比。我們可以定義快速體驗,也就是 FID 小於 100 毫秒的快速體驗。根據 RAIL 建議,如果延遲時間為 100 毫秒或更好,使用者就能立即感受到 FID 體驗。

SELECT
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid
WHERE
  origin = 'https://developers.google.com'

結果顯示,系統認為此來源有 95% 的 FID 體驗會視為即時。聽起來還不錯,但如何與資料集中的所有來源比較?

SELECT
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid

這項查詢結果顯示,84% 的 FID 體驗不到 100 毫秒,因此 developer.google.com 高於平均值。

接下來,讓我們試著縮小資料,看看電腦和行動裝置的快速 FID 百分比是否有差異。我們對此假設,其中一個假設是行動裝置的 FID 值較慢,原因可能是硬體比電腦更慢。如果 CPU 的功能較不強大,則可能會比較繁忙,並導致 FID 體驗速度較慢。

SELECT
  form_factor.name AS form_factor,
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid
GROUP BY
  form_factor
form_factor fast_fid
電腦版 96.02%
手機號碼 79.90%
平板電腦 76.48%

實驗結果證明我們的假設正確無誤。與手機和平板電腦板型規格相比,電腦快速 FID 體驗的累積密度更高。如果瞭解這些差異的「原因」(例如 CPU 效能),就需要在 Chrome 使用者體驗報告之外進行 A/B 測試。

我們已經學會如何判斷來源是否提供快速的 FID 體驗,接著就來看看幾個成效良好的來源。

範例 1:http://secretlycanadian.com

Secretlycanadian.com 的 WebPageTest 幻燈片

這個來源的 FID 體驗有 98% 少於 100 毫秒,是怎麼做到的?分析在 WebPageTest 中是如何建構的,我們可以看見這是一個包含大量圖片的 WordPress 頁面,但其中有 168 KB 的 JavaScript 在我們的研究室機器上執行約 500 毫秒。根據 HTTP 封存,這並不是非常簡單的 JavaScript,因此會將這個網頁置於第 28 個百分位數。

Secretlycanadian.com 的 AWebPageTest 瀑布

橫跨 2.7 到 3.0 秒的粉紅色長條是「剖析 HTML」階段。在這段期間內,該網頁沒有互動式內容,而且看起來不完整 (請參閱上方膠捲中的「3.0s」)。之後,所有需要處理的較長工作都會將其細分,確保主執行緒保持靜止狀態。第 11 列的粉紅色線條示範 JavaScript 工作如何快速爆發。

範例 2:https://www.wtfast.com

wtfast.com 的 WebPageTest 膠卷

此來源有 96% 的即時 FID 體驗。它會在研究室機器上載入 267 KB 的 JavaScript (HTTP 封存檔中的第 38 個百分位數),並在研究室機器上處理它 900 毫秒。幻燈片顯示頁面需要約 5 秒繪製背景,大約需要 2 秒才能繪製內容。

wtfast.com 的 WebPageTest 瀑布

關於結果,最特別的是,當主要執行緒處於 3 至 5 秒之間的時間時,根本不會顯示互動內容。實際上,這個網頁的 FCP 加快 FID 的改善速度。透過使用許多指標來呈現使用者體驗,這個重要範例就是很好的例子。

開始探索

如要進一步瞭解 FID,請觀看本週的《The State of the Web》系列影片:

在 Chrome 使用者體驗報告中提供 FID,可讓我們建立互動體驗的基本基準。利用這個基準,我們可以觀察日後版本發生變化,或是對個別來源進行基準測試。如果想開始在自家網站的現場測量資料收集 FID,請前往 bit.ly/event-timing-ot 並選取「事件時間」功能,註冊來源試用。當然,您也可以開始探索資料集,取得值得注意的網路互動狀態洞察。這仍為實驗性指標,歡迎在 Twitter 上透過 Chrome 使用者體驗報告討論群組@ChromeUXReport 提供意見,並與我們分享您的分析結果。