在 Google I/O 2017 中我认为有一场谈论网页效能数据与使用者体验的演讲很值得分享:Web Performance: Leveraging the Metrics that Most Affect User Experience,虽然内容围绕在网页技术架构的建议上,可能会让不懂程式技术的人却步,但身为 UX 从业人员,数据分析是一个非常重要的技能,可以帮助我们建立衡量的基准、理解产品的表现,这场演讲内容是将使用者的感受对应於网站速度效能需要被衡量的指标,是 UX 工作者非常需要的知识。

作者/ Isabel

(图/翻摄自 Youtube)

首先,讲者希望透过同理使用者的感受,帮助我们思考并提问:哪些数据应该被检视,并且成为使用者体验的衡量资料之一。一般来说,最常见的是透过网站流量分析工具来记录使用者在自家网站上的行为;不过,对网页的程式开发以及研究网站使用体验的人员来说,讲者建议将网页资讯下载的过程,分别记录不同阶段的载入完成时间,这些数据指标会更有助於了解网页效能提升之後对使用者的帮助是什麽。讲者也特别分析了 mobile web 与 mobile web app 类型的产品,也提供了目前 Google 公司的测试支援工具。

网页效能就是速度
一开始,我们必须要先了解「效能」对使用者来说的意义是什麽?是「速度感」,因为现今的使用者对於网页内容下载的感受非常没耐心敏锐,无论他们是在使用 app 或是在浏览器中寻找资讯,追求的目标就是过程中不被干扰、内容呈现快、系统操作反应快等,一旦下载速度过久,就会产生效能差的印象。但是讲者认为「效能」本身其实很难被定义如何叫做「快」,以下载快慢来说,网页内容的下载时间,其实不是一个单独的时间点可以代表,而是由许多事件运作综合起来的时间区间,然後再将不同状况的下载速度平均起来而得。我们如果可以对这些背後运作的架构多一点理解,就能用这样的思维来衡量「效能」。

平均下载速度的迷思,让人忽略真实世界中的效能问题
接着谈到的是关於产品被下载的速度测试,普遍存在一种迷思,那就是直接去看分析下载完成速度的「平均」数据,乍看之下好像可以得出一个满不错的「速度」,但是这会让我们忽略其中很大一部分人感受到的下载时间,其实是属於过长的状况,而用「平均计算」的方式来呈现效能,就是目前最常见的作法。因此,讲者希望我们不要再用概括的方式来介绍自己的产品效能,例如:「我测试了我们的 app,下载速度是 x.xx 秒以内。」事实上,这个秒数并不代表每一个单独的使用者在下载时的效能,讲者用一张长条图举例说明统计下载时间的现实统计,可以发现明显的「长尾」状态,显示出许多人的下载时间是过久的。

下载速度并非单一时间数字而来的结果(图/翻摄自 Youtube)

「下载时间」本身除了不该是单一个时刻的秒数之外,也该被视为是一个「过程」,讲者的说法是「一整段体验」,无论是从使用者感觉到已经在下载,或是程式从背景运作进行时的下载,都属於下载中的一部分。以 Youtube 和 Airbnb app 的下载过程来举例,我们都知道现在 app 载入内容会分阶段进行(Skeleton screens),不同元件会依序被下载,慢慢显示在萤幕上,这样的呈现方式可以视作一种系统给予使用者的回馈,目的是希望在下载过程中,让使用者知道 app 是有在动的!

Youtube 分阶段下载的过程(图/翻摄自 Youtube)

以技术人员的角度而言,决定这些元件出现的顺序就是一个很重要的思考。讲者特别以 Airbnb 的下载问题来说明,如果技术人员没有考量到使用者的网路环境,或手机规格可能不佳的问题,那麽资讯下载时的体验就会遇到瓶颈,造成使用者拼命点击画面,却一无所获的窘境。 Airbnb 是这样做的:在开发的环节中,特别使用较低阶的手机以及在比较慢的网路环境中做效能测试,这样一来,他们便知道在硬体环境不是最佳条件的状况中, app search bar UI 不应该在搜寻功能的背景运作还未准备好之前就显示出来,否则可能会造成使用者点按多次却没有反应的问题,这在以寻找住房为核心功能的产品体验上,将是一个很关键的缺失。

Airbnb 的搜寻功能在下载过程中无法顺利运作(图/翻摄自 Youtube)

在真实的世界中计算数位效能
所以在真实的世界里,要怎麽衡量数位世界中的下载效能?讲者建议我们采取多样化的指标来尝试得到答案。前面提到一个常见的迷思,就是只在乎资讯下载的总时间 (load time),因为我们目前所见的工具总是专注在记录 loading 的时间数据,但是在真实世界中,使用者在等待下载时还会不受控的进行做很多动作,像是点击、滑上滑下、长按萤幕等,这些互动的反应速度却常常被忽略,所以在讨论效能这件事情的时候,应该将所有使用者可以互动的事件都考虑进来,因为「效能好不好」是跟使用者在整个下载过程中所感受到的结果,「完成下载的时间」只是谈论效能时的其中一个部分。

下列四个方向的提问就是这场演讲中的核心议题:

什麽样的指标可以反映出使用者所感知的效能?
我们如何从真实的使用者身上测量到这些指标?
我们该如何阐释这些衡量结果代表的意义?
未来该如何改善和避免效能下降的问题?

讲者提到旧有的效能衡量指标并没有考量到现在 web app 在下载的过程中那些使用者会与系统互动的可能,所以如此统计出来的数据,就无法察觉操作体验时会发生的瓶颈,例如:当 web app 在下载 CSS 档案时,可能会因为背景程式中的 JavaScript 还没载入完成而造成使用者先看得到按钮,但操作後系统却没反应的状况。

四个关於使用者感受效能的指标
现在若我们用使用者体验的角度来检视效能指标,我们会想知道什麽体验指标会形成使用者对效能的观感?讲者用使用者的心声来说明四个概念的提问:

Is it happening? 啊现在是开始下载了没?
Is it useful? 这是我要看的吗?
Is it usable? 可以开始操作了吗?
Is it delightful? 操作起来顺畅吗?会卡住吗?

这四个问题,就是我们最需要关注的数据指标,透过观察这四件事来检视系统透过什麽方式让使用者知道资料正在载入中?是否有足够的内容让使用者判断这是他要的资讯?如何让使用者在适当的时间开始与系统互动?什麽原因可能会造成延迟感或让使用者无法顺利完成操作?为了回答这些问题,讲者提出将下载阶段分割成几部分来观察的方法。

下载过程的阶段画面(图/翻摄自 Youtube)

下载进度可以被切成四个主要阶段,并且为它们命名,以便追踪达成阶段的时间点,特别是在低规的环境中,像是手机硬体规格不佳或网路速度慢的时候,产品内下载效能是否有达到预期?现在若将前面所说过的的四个主要的下载阶段,对应於四个使用者在乎的问题,将有助於我们理解数据指标对改善使用者体验的意义为何。

FP/ First Paint 可以开始知道有在下载的变化
FCP/ First Contentful Paint 可以感受到有内容的画面
FMP/ First Meaningful Paint 可以开始理解意义的画面
TTI/ Time to Interactive 可以开始与画面互动的时间点

透过四个下载阶段的效能指标来回答使用者感受上的提问(图/翻摄自 Youtube)

找出 Hero Elements
在分阶段检视下载效能的同时,我们还可以把载入的资讯内容做出重要性排序,讲者将这些对使用者能够产生最大意义的资讯区块称之为 Hero Elements,因为对使用者来说,Hero Element 在出现的那一刻,会让使用者感觉到自己正在获得有用的东西,而不同属性的产品会有属於自己的 Hero Elements,必须在下载的阶段中优先出现。

以提供内容的平台举例说明各自的 Hero Element(图/翻摄自 Youtube)

盘点出影响下载效能的 Long Task 有哪些
决定了自家产品中最重要的资讯区块後,再来要检视内容载入时,哪些 task (任务)会发生执行不顺的状况?对程式技术用语不熟悉的人可能不明白「 task 」到底是什麽,但我们可以想像一下,那些会让用户感到等待太久或操作反应不顺畅的事件,可能就是因为 long tasks 所产生的,这些会让程序无法按部就班执行的 long tasks,正是浏览器页面中的威胁,最终会形成不好的使用者体验。好比人们排队等待购物结帐或是等待银行柜台服务的经验,总是有人会因为等太久而生气感到疑惑:「现在到底是在等什麽啊?」。Long tasks 在浏览器程序执行中若因为某些原因而运作不顺利,就会延迟其他 tasks 的工作,不断让既定的执行程序被阻塞起来导致效能变差,如此一来,使用者介面上的动作就变成「卡卡的」或「没反应,当掉了!」等情形。

讲者建议技术人员除了在测试环境中,也需要尽量在「真实的环境中」找出这些关键的 long tasks,并且排除它们。而 Google 也有提供相关的测试工具(例如:Lighthouse, DevTools)让开发者可以侦测 mobile web 产品中是否有属於 long task 的事件,藉由记录与分析效能速度表现,在未来进行优化的时候,就可以作为得知效能是否进步的依据。

将 long task 比喻为产生等待队伍的事件(图/翻摄自 Youtube)

透过效能指标思考商业目的
讲者提到,虽然 Google 做的许多研究告诉我们 good performance is good for business,但是每一个产品属性不同,我们还是要懂得活用这四个效能指标,从使用者的体验角度检视效能,验证产品的业务表现实际上有何进步?甚至不要排斥为产品建立新的指标。举例来说,在商业上的思考,可能是:

使用者有因为 app 中的互动更快而买更多东西吗?
使用者有因为在结帐流程中遇到 long tasks 而更容易放弃结帐吗?

找出商业提问的答案将有助於排序产品中需要优化的项目,并且更能说服公司为改善产品效能投入更多工作资源。

留意观察数据时的盲点
不过,讲者提醒我们若仅看这些数据也是有盲点的,因为目前为止我们讨论的都是针对「有存留下来使用 app」的使用者所统计的数据, 而那些在画面下载完成之前就离开的使用者呢?这些放弃使用的人也一样提供了重要的统计数据让我们分析效能问题。而且,假设这些提早离开的人,很不幸地才是占多数的使用者,那麽统计「有存留下来使用 app」的数据资料也不具有代表性了。

因此,对於没有真正与内容产生互动,在下载完毕之前就离开的使用者,虽然无法知道他们的 TTI (执行第一个互动前的等待时间),但还是可以试着衡量他们发生「提早离开」的机率有多高?更重要的是,他们在离开之前平均停留多久时间?

制定一个防止产品越改越退步的计画
讲者最後提到,刻意用四个下载阶段来检视效能,是为了让每一个阶段的效能都能找出进步的空间,而最终是希望看到整体下载时间可以被缩短。因此在技术的实作上就需要考量许多层面,例如:为了避免载入不必要的 JavaScript ,我们要先检视哪些页面是使用者可能不太会去互动的地方,排序出来之後,让重要的 JavaScript 先执行。像这样的规划在产品进入开发前可能就会花掉不少时间,这也牵涉到产品开发资源(人力、工时)是否足够的问题。因为很多时候,为了加速开发速度,工程师可能就会倾向把十几页网页的 JavaScripts 合并成一包,在网页被下载时同时执行,但这件事情会让不必要的程式码也送给浏览器,拖垮了下载的整体速度。

除此之外,网页中的第三方内容也要列入检视范围,像是广告以及其他社群外挂程式的载入效能。一个与 Google 合作的研究服务公司 SOASTA 指出,广告与社群外挂程式是造成 long task 的主因。因此,在产品释出之前必须经过制定好的验证计画,以确认新版本效能有比旧版本更好;而更有效率的做法,则是让这些验证可以自动化来获得足够的真实效能资料。例如:使用 GA (Google Analystic) 设定警示,如果刚才说的第三方外挂程式有任何变动影响到效能,开发者便能及时收到通知。

Google 建议的程式码更新的验证流程(图/翻摄自 Youtube)

後记:根据我访问的内行人表示,程式在开发时若要考量到以上这些条件,会需要花费更多倍的时间来处理才能做到,而通常在专案时限很赶的情况下,即便知道这些问题有可能发生,还是挤不出时间来细细调整啊。套一句残酷的口白:「我什麽都能做,只是没有时间而已!」

或许你会想:这一篇内容很技术耶,有点难懂!我建议你把不懂的地方拿去问问可爱的工程师们,并且藉机了解一下他们都在什麽样的水深火热之中,伸出你的友谊之手,永远不嫌晚!这边建议你第一个可以问的问题:「请问现在我们都怎麽测试公司的产品效能呢?」

本文由 痞客邦 UX 实验室 提供,原文出处 那些真正影响使用者体验的网页效能数据指标 – Google I/O 2017

痞客邦 UX 实验室团队藉由分享使用者经验研究与设计相关心得与成果报告,将 UX 相关经验贡献给社群,促进台湾的 UX 相关专业的发展。

诚挚邀请你成为好朋友–>

  

 

 

 

0 0 投票数
Article Rating
订阅评论
提醒
guest
0 Comments
内联反馈
查看所有评论