02
OCT
2017
那些真正影响用户体验的网页性能数据指针 - Google I/O 2017
by 痞客邦 UX
在 Google I/O 2017 中我认为有一场谈论网页性能数据与用户体验的演讲很值得分享：Web Performance: Leveraging the Metrics that Most Affect User Experience，虽然内容围绕在网页技术架构的建议上，可能会让不懂程序技术的人却步，但身为 UX 从业人员，数据分析是一个非常重要的技能，可以帮助我们创建衡量的基准、理解产品的表现，这场演讲内容是将用户的感受对应于网站速度性能需要被衡量的指针，是 UX 工作者非常需要的知识。
（图/翻摄自 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）
后记：根据我访问的内行人表示，程序在开发时若要考量到以上这些条件，会需要花费更多倍的时间来处理才能做到，而通常在项目时限很赶的情况下，即便知道这些问题有可能发生，还是挤不出时间来细细调整啊。套一句残酷的口白：「我什么都能做，只是没有时间而已！」
或许你会想：这一篇内容很技术耶，有点难懂！我建议你把不懂的地方拿去问问可爱的工程师们，并且借机了解一下他们都在什么样的水深火热之中，伸出你的友谊之手，永远不嫌晚！这边建议你第一个可以问的问题：「请问现在我们都怎么测试公司的产品性能呢？」
作者：Isabel
推荐阅读：
- UX 写作的品牌原则，以 Android Pay 为例 - Google I/O 2017
- 从产品的错误提示消息理解三个 UX 写作原则 - Google I/O 2017
- 如何从文本用语来塑造产品的用户体验 - Google I/O 2017
