Google Web Vitals – 使用者體驗量化

Google Web Vitals - 使用者體驗量化

Google 在 2020/5/4 號發佈了新的搜尋引擎演演算法更新,影響許多站主的來客流量,正當大家還摸不著頭緒時,5/5 又提出了新的消費者體驗量化方式 Web Vitals,在 5/28 更指出此量化方式將開始至少試驗一年的時間,在 2021 年之後某個時間點成為 Google 搜尋排序指標之一,符合 AMP 或良好 Web Vitals 的網站都能出現在 Search Top Stories 上。 究竟什麼是 Web Vitals 以及 Google 發展體驗量化標準能夠對他們的業務帶來什麼説明,以下部份內容包含自己的觀點,希望能拋磚引玉,互相切磋成長。

閱前聲明:每個人的經歷、視角、以及所處的環境都會有所差異,這是一篇主觀的總結建議,觀點也會有所偏頗,並不涉及深刻的技術實現。 另外篇幅和時間所限,每一部分都挖的不夠深也沒有展開,請見諒。

成果回顧

Google 在 Web 上的發力始終很積極,很難想像在 15 年前 Google 面對高市占比的 IE 瀏覽器、JAVAScript 和 CSS 的支援混亂以及 Flash 外掛程式橫行的年代,能夠逐步站穩自身瀏覽器市占,進而擁有極高的話語權,影響整個 Web 技術發展,而且發力的面向是非常全面的,基於本文討論內容,下圖列出 Google 在使用者體驗量化發展的相關成果。

使用者體驗好或不好一直是前端領域中,常常被拿出來講的話題,因為涉及設計、藝術和美感等難以量化的成份,所以難有一個統一衡量標準,而 Google 試著解答這個難題,從一開始提供 GA 服務上報操作訊息,發表自己的瀏覽器支援最新 W3C Web 技術,然後推出 PWA & AMP 設計開發標準、RAIL 指標、衡量網站體驗的工具和 Lighthouse ,並基於上百萬位站主合作經驗上不斷修正標準,嘗試抓出這個標準,在 2020 年推出了 Web Vitals。

Web Vitals ?

什麼是 Web Vitals ,Google 給的定義是一個良好網站的基本指標 (Essential metrics for a healthy site),為什麼還要再定義一個新的指標集,原因是過去要衡量一個好的網站,需要使用的指標太多,推出 Web Vitals 是簡化這個學習的曲線,站主只要觀注 Web Vitals 指標表現即可。

而在 Web Vitals 指標中,Core Web Vitals 是其中最重要的核心,目前包含三個指標:

  • LCP 顯示最大內容元素所需時間 (衡量網站初次載入速度)
  • FID 首次輸入延遲時間 (衡量網站互動順暢程度)
  • CLS 累計版面配置移轉 (衡量網頁元件視覺穩定性)

指標標準如下圖。

這三個指標不是突然出現的,如 LCP 在 WICG 已經孵化至少 1 年以上,FID 在 Google Chrome Labs 上已經實施 2 年以上,LCP 和 CLS 已於今年入 W3C 草擬標準。 而 Core Web Vitals 為何精挑這三個指標,讓我們來細部瞭解其內容。

技術實踐

衡量網站初次載入速度

在過去的翻頁設計,常用 load 和 DOMContentLoaded 事件反應頁面元件完成載入,但為了更精準地抓到頁面到完成渲染的持續時間,得使用 FCP 指標。 不過在 SPA 的時代,頁面常常一開始是先顯示一個載入圖示,此時,FCP 就很難反應頁面初次載入直到 Web 能夠提供使用的那個時間點。 FMP 和 Speed Index 嘗試説明抓到此時間點,不過衡量標準過於複雜,不易推廣。

延伸閱讀: FMP 演演算法](https://link.zhihu.com/?target=https%3A//docs.google.com/document/d/1BR94tJdZLsin5poeet0XoTW60M0SjvOJQttKT-JK8HI/view) ,Speed Index 演演算法

WICG 上則孵化了一個新的指標 LCP ,簡單清楚地以網頁 Viewport 最大 Element 載入為基準點,衡量標準如下圖所示,在 2.5 秒內載完最大 Element 為良好的網頁載入速度。

其最大指的是實際 Element 長寬大小,Margin / Padding / Border 等 CSS 大小效果不計入。 包含的種類 為 , url(...),

因為網頁上的 Element 可能持續載入,最大的 Element 也可能持續改變 (如文字載入完,然後載入圖片) ,所以當每一個當下最大的 Element 載完,瀏覽器會發出一個 PerformanceEntry Metric,直到消費者可以進行 Keydown / Scrolling / Tapping 等操作,Browser 才會停止發送 Entry,故只要抓到最後一次 Entry ,即能判斷 LCP 的持續時間。

如下圖所示,綠色區域是 LCP 不斷改變的偵測物件,也能看到 FCP 與 LCP 的判斷差異。

下圖可以看到一開始的 圖片並沒有被計入 LCP 的偵測物件。

開發者可透過 PerformanceObserver 及設定 Type \'largest-contentful-paint\' 拿到 LCP 的時間,如下圖所示。 (建議使用 Chrome v83 以上版本)

衡量網站互動順暢程度

如何衡量網站操作的順暢程度,Google 採用 FID 指標,其定義為在 TTI 的時間內第一個互動事件的開始時間與瀏覽器回應事件的時間差,其互動事件為單次事件如 Clicks / Taps / Key Presses 等,其他連續性事件 Scrolling / Zooming 則不計,如下圖所示。

為什麼要取在 TTI 發生的第一次的操作事件,Google 給的理由有以下三點:

  • 消費者的第一次互動體驗印象相當重要
  • 當今網頁最大的互動性問題通常發生在一開始載入時
  • 頁面載入完后的第二次操作事件延遲,有其他專門的改善解決建議

但是 FID 的計算有其明顯的問題,如當消費者在 Main Thread 閑置時操作,那 FID 可能就短,若不操作則 FID 則無法計算。 這對開發者來說,很難去衡量網站的 FID 符合良好的標準,所以 Google 給的建議是透過降低 TBT 的時間來降低 FID 的值,當 TBT 越短,其 FID 就越好。

開發者可透過 PerformanceObserver 及設定 Type \'first-input\' 拿到 FID 的時間,如下圖所示。 (建議使用 Chrome v83 以上版本)

衡量網頁元件視覺穩定性

相信大家在操作網頁時,常常發生以下誤點的情況,讓人對此 Web 的印象相當不好。

為了衡量此體驗指標,Google 基於 Layout Instability API 建立 CLS 指標,衡量標準如下圖所示。

其 CLS 代表的是每個 Element 非預期位移的累積,而每個位移的演算法如下:

元件位移分數 (Layout Shift Score) = 影響範圍 (Impact Fraction) * 移動距離 (Distance Fraction)

如上例來說,影響範圍 (紅色) 佔比 Viewport 75% ,箭頭 (紫色) 移動占 Viewport 的 height 25%,故 0.75 * 0.25 = 0.1875。

上例影響範圍 (紅色) 占 Viewport 38%,單個 Zebra 箭頭 (藍色) 移動最大占 Viewport height 30% ,故 0.38 x 0.3 = 0.114。 依序將每個移位的元件之位移分數累計起來即是 CLS。 (透過 Layout Instability API 即可拿到目前可視元件在每兩個 Frame 間的位置異動訊息)

演演算法已經瞭解了,但是指標定義的「期望」如何定義,Google 給的解釋如下:

Layout Shifts 的發生與消費者的互動是關聯的,如透過點擊一個連結、按了一個按鈕或在搜尋框打字。

故在消費者操作後的 500ms 內的 Layout Shifts Performance Entry 的 hadRecentInput 標識為 true ,將不被計入 CLS 指標內。 所以如載入一個下拉式選單內容,消費者送了一個 AJAX 至後端,前端應先建立空白區塊 (位移不被計入 CLS),並放入載入圖示,於訊息回傳後填入空白區域,而不是載入後才配置區塊空間。

開發者可透過 PerformanceObserver 及設定 Type \'layout-shift\' 拿到 Layout Shift 的時間,如下圖所示。 (建議使用 Chrome v83 以上版本)

其他

  • Core Web Vitals 的指標衡量針對單一網頁,但是一個良好的網站,應該是 75 % 的 PV 都能取得良好的程度才能稱得上是良好的網站。
  • 某些動畫效果是用來做為引導消費者,CSS 的 transform 不會被計入 CLS 。
  • FID 對應到 RAIL 的 R,Scrolling / Zooming 對應到 RAIL 的 A。

推廣

Google 總共在六種工具上新增了 Web Vitals 的衡量功能,如下圖所示。

其中推薦 PageSeed InsightsWeb Vitals Extension 來簡易測試網站的表現分數。

Google 此次大幅度地推出六樣工具,基於過去推行的幾次量化指標成效沒有很明顯 (如 RAIL),2021 年後可能將 Web Vitals 表現納入自家搜尋引擎排序演演算法中,半強迫地讓眾多仰賴來客流量的站主能事前利用這些工具改善體驗分數,表現良好的網站還能優先出現在 Google Search Top Stories,另外線上也推出相關主題活動可以參與瞭解 - web.dev LIVE

業務整合

Google 積極在使用者體驗量化上定出標準,對自家的雲業務也進行了深度的整合,盡可能地提供各式各樣的工具給經營網站的站主,此模式透過站主深入到各式各樣的網站經營,讓 Web Vitals 能變成是業界使用者體驗量化的衡量標準。 以下列出 BigQuery 和 Google Data Studio 整合 Web Vitals 的使用方式。

Google 在 BigQuery 上有提供各式網站的 CrUX 報表資訊並且免費查詢 (有限查詢量),Google 也提供了不少查詢的 SQL 的範例可以參考, 如下圖為淘寶在 2020 年 5 月 1 日所收集到的 Web Vitals 表現 (p75_lcp 2000ms 為表現良好),此數值呈現各消費者不同裝置下的 75% 體驗表現,能提供給站主較客觀的資訊。

在 Data Studio 上能選取 CrUX Report 外掛程式做為數據源產出制定報表,如下圖。

下一步流覽各欄位設定。

接下來報表就產生在 Data Studio ,如下圖。

除了 Core Web Vitals 指標以外,還包含使用設備類型及連線網路類型。

這對於管理網站的站主而言是一個簡易瞭解整個使用者體驗及數據分析的方式,如果要進階處理細部資訊,能選擇 BigQuery 外掛程式作為數據源。

瀏覽各欄位設定。

透過設定圖表瞭解每月 Web Vitals 指標變化,如下圖。

下圖為手機及桌機上 LCP 的每月表現。

利用以上工具 (另還有 Google Analytics 和 Search Console 資料源外掛程式),站主能透過這些不同外掛程式的數據源結合網站營運資料來進行綜合分析,如營收、獲利和使用者體驗的關係。

小結

Google 在 Web 上的紮根與投資是非常長期的,從一開始對面微軟來說也是很渺小,十年累積的發展成果,使之越來越有話語權。 而單看使用者體驗量化標準制定的發展策略,我們可以看到 Google 把所得的數據再回饋到既有業務的 BigQuery 與 DataStudio 進行分析,對 Google 自己和網站經營者都是魚幫水水幫魚,讓使用 Google Search 出來的網站都是體驗良好的網站,並且豐富了 Google 應用生態圈。

雖然說 Google 所提出的消費者體驗量化指標不一定完全適合於我們,但是其數據使用方式及生態圈建立都是我們能取經的地方,我們也能從中學習 Google 如何兼顧利用使用者體驗的量化資訊以及提升整個體驗層次。

Core Web Vital 台灣優化專家? Tenten.co

Tenten Core Web Vitals 優化 涵蓋 Core Web Vitals 三項指標,而我們也利用 CWV 準則持續導入我們製作的網站中,進而提升整體產品服務體驗水準。

資料來源

https://tenten.marketing/blog/tag/seo/
https://seo.tenten.co/
https://www.hubsoda.com/

2021年前端開發回顧

頁面載入性能之Web Vitals