如何测量用户体验？

这篇post内容其实主要是对WebPagetest的一个性能指标speed index（如果你打不开，请尝试这个我提前准备好的pdf版本）释义文档的翻译。

这篇文章真正的标题应该是：WebPagetest性能指标: speed index。speed index和用户体验有什么关系呢？

speed index是webPagetest推出的一个专门用于衡量页面加载过程快慢的指标。目前已有的受浏览器支持的性能指标，如DOMContentLoaded和onload事件耗时，甚至一些公司自己通过插入js监测代码也能统计到的首屏渲染耗时，都能用来衡量页面加载快慢。但是speed index衡量的是页面加载的整个过程（更准确一些，是用户可见区域的加载过程）用户能感知到的快慢，而其他指标大多只是衡量加载到某个关键事件发生的快慢（或耗时）。

举个例子，假设iQiYi的播放页和youku的播放页的首屏渲染耗时都是5秒，即在用户页面从打开到第5秒结束的时候第一屏才渲染完毕。iQiYi的播放页在第200ms的时候导航栏就渲染出来了，第1秒的时候flash播放器显示出来，第2秒的时候视频就开始播放了，第3-5秒首屏的其他区域都逐渐渲染出来；而youku的播放页第1秒的时候才渲染出导航栏，第2秒的时候flash播放器才显示出来，第3-5的时候视频才开始播放，首屏的其他区域才逐渐渲染出来。这两种加载过程的首屏耗时指标相同，都是5秒，但是对于用户而言，明显前一种加载过程的体验更好一些！speed index就是用于衡量用户可见区域加载过程快慢的综合指标！

由于是综合指标，speed index在指导开发，定位具体问题，确定优化方向方面没有那些单项指标那么友好。比如，白屏时间变高，你可以把问题原因定位到dns解析、tcp链接、页面head部分script请求阻塞方向等；但是speed index单独一个指标并不能告诉我们性能瓶颈所在。

废话扯完了，下面开始正文（尽管是我翻译的，但我还是推荐你看官方文档）：

WebPagetest性能指标: speed index

speed index衡量的是页面可见区域的平均展示时间，以毫秒为单位，与浏览器视口的尺寸有关。

speed index指标在2012年4月才加入到WebPagetest中，用于衡量页面内容在视觉上生成的快慢（数值越低越好）。它特别适用于比较不同页面（优化前后，竞手之间）在用户体验方面的差异，而且应该和其他指标（如load time, start render）一起使用才能更好地理解一个站点的性能。

问题

以往我们都根据一些关键事件发生的时刻来判断一个站点有多快（或多慢），其中最常用的就是页面资源加载完成（onload）事件的耗时时间。加载完成事件在实验条件和真实环境中都很容易测量到，但对于最终用户的体验而言，它不是很好的指标。随着网页越来越臃肿，onload耗时会因为页面加载了很多用户看不见的内容而升高，尽管用户可见的内容早已呈现出来。为了更好地表述耗时，我们已经引入更多的关键时间点（如DOMContentLoaded，firstPaint），但这些指标在本质上都是有不足的：它们测量的是单个事件发生的时刻，并不能用来描述整个内容加载过程中真实的用户体验。

speed index介绍

speed index根据页面的可见区域的视觉上的加载进度，计算出一个综合的数值来表征内容绘制的快慢。为了做到这点，首先要能够计算出在页面加载过程的每个（固定间隔的）时间点的页面完成度（Visually Completeness，简称VC，下同）。这在WebPagetest中通过在浏览器中页面加载过程中抓拍视频并检查每一帧（每秒10帧，只在视频抓拍开启的情况下生效）。目前计算每一帧完成度（VC）的方法将会在后面介绍，但现在先假设我们能给每一帧计算出一个用百分比表示的完成度（图中上面一排是页面A，下面一排是页面B的绘制过程）：

如果我们绘出页面A和页面B的完成度（VC）随时间的变化趋势，我们将得到如下所示的图：

接着，我们可以把加载进度计算为曲线以下x轴以上区域的面积：

到现在计算方法已经很完美了，除了一个小问题：它是无界的。如果一个页面在可视区域完成后又持续加载了10秒钟，那么这个分数将持续增长。如果使用曲线上面的区域来计算页面未渲染的比例，我们将得到一个有限的区域，最终页面达到100%完成度（VC），而且随着页面变快，这个值将趋于0。

测量可见区域渲染进度

前面没有介绍每一帧的完成度是如何计算的，但speed index本身的计算过程并不依赖计算每一帧完成度所用的技术。目前有两种可用的计算方法：抓拍视频（Video Capture）和监测浏览器绘制事件(Paint Event)。

抓拍视频

比较简单直接的方法是检查每一帧图片的每一个像素，和最终加载完成时图片上的像素逐个进行对比，计算出每一帧的匹配的像素所占的百分比（或许把介于第一帧和最后一帧的之间的像素也算作匹配）。这种方法的主要问题是：页面通常是变化的，比如一个广告加载之后会导致页面的其他内容的位置被移动。在像素对比的模式下，屏幕上每一个像素看起来好像都变了，尽管页面的实际内容只是向下移动了1像素。

WebPagetest最后选定的方案是：绘制图片中颜色的直方图（红绿蓝各一个），只关注页面上的总体分布。计算出第一帧的三个颜色直方图和最后一帧的三个颜色直方图的差值，作为基准值。每一个中间帧的直方图与第一帧的直方图的差值除以基准值，作为中间帧的完成度。在某些场景下这种方法确实不是很精确，但根据已经测试过的大部分页面来看，这种折衷的方案都被证明是可行的。

抓拍视频逐帧分析是speed index指标最初推出时的计算机制，而且到现在也在继续使用。在一些场景下它确实是有问题的，比如页面有视频播放，焦点图切换动画和大面积的空隙等。这种方法算出来的speed index值对页面最终状态非常敏感，而且计算过程是以最后一帧图片为基础。这只能在实验条件下才能测量到，而且依赖抓拍视频功能。

监测绘制事件

最近WebPagetest已经（成功地）试验了使用Webkit提供的绘制事件来计算speed index。

我还没写完！