iT邦幫忙

2021 iThome 鐵人賽

DAY 12
1
IT管理

從 IT 技術面細說 Search Console 的 27 組數字 KPI 系列 第 12

從 IT 技術面細說 Search Console 的 27 組數字 KPI (12) :網頁體驗 - Core Web Vitals

註:這篇不打算講 Core Web Vitals 的介紹、以及如何去解決,因為這資訊很難靠這樣一篇寫完,因此這篇是以 IT 管理者須要的『觀點角度』去寫。

https://ithelp.ithome.com.tw/upload/images/20210912/20000065pF0WvjKFce.png

網頁體驗是一個很難量化的事,因為說到體驗就應該是種感受,而每一個人對感受的認知與解讀都不一樣,要去衡量網頁或網站是不是有好的體驗真的見人見智。

在早期倒是有一個很簡單的定義:速度,只要速度夠快體驗就不會太差。

在 Google Analytics 現在還是保留了六項網站速度的指標:

  • 平均網頁載入時間 (秒)
  • 重新導向平均需時 (秒)
  • 網域查詢平均需時 (秒)
  • 伺服器連線平均需時 (秒)
  • 平均伺服器回應時間 (秒)
  • 網頁下載平均需時 (秒)

https://ithelp.ithome.com.tw/upload/images/20210912/20000065NytxFNHaGV.png

Search Console 的早期也是有用快、中、慢來去定義網站體驗,但那時主要是用在 FCP 與 FID 這種以速度為主的指標,但速度這件事在 CSR 變成網站很重要開發的方式後,速度已經沒那麼絕對了。

因為速度的前提有時須要有一個時間區間,在 AJAX 的技術被大量使用之後,就很難定義網站『讀取完畢』的時間點,更不要說是『瀑布流』之後了,真正的速度早已經不只是開始讀到內容,或是讀完內容的時間,因為很有可能是永遠讀不完。

現在網站技術在使用大量前端的 UI Framework 時,javascript 的執行變成了一個很重要的瓶頸,不要說傳輸的時間可能比圖片更久,執行的效率決定 FCP 、LCP 與 FID 等等。

但在大量的 UI Framework 或外部 Javascript 的影響,雖然定義 LCP 有時就足夠影響體驗,但不代表 LCP 是穩定的,因此就有了 CLS 來去做協助,所以到現在 Search Console 最後用 LCP、CLS、及 FID 三項指標來去定義是合理的。

把 CWV 定義為 KPI,最大的問題是如何透過這數字知道那時已經很嚴重須要去開單執行,這才是重點,這邊通常分成幾個象限來看:

  • 超過 Poor 的數字兩倍,例如在行動裝置的 CLS 是 0.25,而網頁的數字超過 0.5 的話,幾乎可以說是在 SEO 很有可能被懲罰、被消失,是必須立刻執行處理。
  • 網頁是 Poor (不良) 的話,要看這網頁是否是內容頁,若這些頁面是主要的流量來源,這就須要去解決,但若這個不是重要的頁面或是極少數的頁面,的確優先次序就沒這麼高。
  • 主要內容頁不是良好 (Good),或是多是須要改善 (Need Improvement) 時,這還是要開單,除非這問題是很難解決或解決成本極高,這另當別論,甚至此時要考慮是有另外的頁面到 Good 去爭取流量。
  • 網頁是 Good 良好的比例:若是網站有一半以上的網頁是良好,且主要流量來源的網頁都是良好,基本上就沒太大問題。

https://ithelp.ithome.com.tw/upload/images/20210912/20000065IT42WtTvXD.jpg

上面四項的原則並不絕對,有時更會因為時間因素而改變,就像是從七月開始,有發現原本大家都把重心放在行動裝置上,但現在桌面的良好更會影響到流量,即使網站的主要流量都是行動裝置。

在前一篇網頁體驗說到 CWV 的報表有幾個問題,如時間更新過慢,無法真正表現出網站的真實狀況,甚至要在解決問題時去按下檢驗,而檢驗也很常卡關,也包含網址數很容易搞混。

Core Web Vitals 網站核心體驗指標的網址數是較難計算,不只是上面說的時間更新的問題,因為一個網址若不是良好的話,很有可能在 LCP、CLS、FID 三項都會有問題,因此網頁有時會有三倍數字的狀況,且無法排除。

而在今年四月,又把 AMP 的網址獨立出來,造成行動版的網址數變成兩倍(若 AMP 的覆蓋率夠高的話),加上要跟前面做比較,就很如易有問題,就像是 CWV 的次級指標:

MAX(行動裝置良好網址數 、桌面良好網址數) / 有效網頁數

這個數字正常情型都是小於 1 ,尤其是網站一大,甚至很難超過 0.2 (20%),但在 AMP 讓這數字變成雙倍後,就有時一過門檻就會成倍數成長,無法穩定的知道網站的優化 KPI。

所以最後 CWV 變成是用來檢查網頁體驗問題,找出解法時所須要的工具,在做進一步探索解決問題方法要用的數字,即使知道這數字有很高的不穩定與陷阱,因此會用新的網頁體驗做為更重要的 KPI 是比較好的。


上一篇
從 IT 技術面細說 Search Console 的 27 組數字 KPI (11) :網頁體驗
下一篇
從 IT 技術面細說 Search Console 的 27 組數字 KPI (13) :網頁體驗 - 行動裝置可用性
系列文
從 IT 技術面細說 Search Console 的 27 組數字 KPI 30

尚未有邦友留言

立即登入留言