从 IT 技术面细说 Search Console 的 27 组数字 KPI (12) ：网页体验 - Core Web Vitals

注：这篇不打算讲 Core Web Vitals 的介绍、以及如何去解决，因为这资讯很难靠这样一篇写完，因此这篇是以 IT 管理者须要的『观点角度』去写。

网页体验是一个很难量化的事，因为说到体验就应该是种感受，而每一个人对感受的认知与解读都不一样，要去衡量网页或网站是不是有好的体验真的见人见智。

在早期倒是有一个很简单的定义：速度，只要速度够快体验就不会太差。

在 Google Analytics 现在还是保留了六项网站速度的指标：

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 良好的比例：若是网站有一半以上的网页是良好，且主要流量来源的网页都是良好，基本上就没太大问题。

上面四项的原则并不绝对，有时更会因为时间因素而改变，就像是从七月开始，有发现原本大家都把重心放在行动装置上，但现在桌面的良好更会影响到流量，即使网站的主要流量都是行动装置。

在前一篇网页体验说到 CWV 的报表有几个问题，如时间更新过慢，无法真正表现出网站的真实状况，甚至要在解决问题时去按下检验，而检验也很常卡关，也包含网址数很容易搞混。

Core Web Vitals 网站核心体验指标的网址数是较难计算，不只是上面说的时间更新的问题，因为一个网址若不是良好的话，很有可能在 LCP、CLS、FID 三项都会有问题，因此网页有时会有三倍数字的状况，且无法排除。

而在今年四月，又把 AMP 的网址独立出来，造成行动版的网址数变成两倍(若 AMP 的覆盖率够高的话)，加上要跟前面做比较，就很如易有问题，就像是 CWV 的次级指标：

MAX(行动装置良好网址数、桌面良好网址数) / 有效网页数

这个数字正常情型都是小於 1 ，尤其是网站一大，甚至很难超过 0.2 (20%)，但在 AMP 让这数字变成双倍後，就有时一过门槛就会成倍数成长，无法稳定的知道网站的优化 KPI。

所以最後 CWV 变成是用来检查网页体验问题，找出解法时所须要的工具，在做进一步探索解决问题方法要用的数字，即使知道这数字有很高的不稳定与陷阱，因此会用新的网页体验做为更重要的 KPI 是比较好的。