Trustworthy Online Controlled Experiments Part 2 Chap 5
一个关键的假设：局部线性逼近
减速实验的关键假设是，指标（例如收入）与效果之间的关系可以通过与效果相匹配的点周围的直线来很好地近似。这是一阶泰勒级数逼近或线性逼近。
下图显示了，描述了响应时间（效果）和感兴趣指标（例如，点击率（CTR）或每用户收入）之间的常见关系。通常，响应越快，度量值越好（在此示例中越高）。
当我们放慢响应速度时，我们将从垂直线与图形相交的点移动到右侧，我们可以测量指标的变化。我们做出的假设是，如果我们要移至垂直线的左侧（以提高性能），则左侧的增量将与我们在右侧测得的增量大致相同。
这个假设是否能够成立？有两个条件可能使其成立：
根据我们自己作为用户的经验，搜索越快越好。很难想象函数会出现间断或急剧变化，尤其是在当前性能点附近。如果延迟三秒钟，可能会出现剧烈的变化（间断点），但是如果增加或减去十分之一秒，则发生这种情况的可能性较小。 【从数学上解释，就说 性能-收益 函数在当前状态对应的点附近可导】
我们可以在两个点对图形进行采样，以查看线性近似是否合理。具体来说，Bing进行了100毫秒和250毫秒的减速实验。在几个关键指标上，250毫秒实验的增量约为100毫秒研究的增量的2.5倍（在置信区间内），这支持了线性假设。
如何测量网站的性能
衡量网站性能并像看上去那么简单。本节涉及的一些测量的复杂性和所做的一些假设。这些重要的细节可能会影响实验设计。我们在这里详细介绍一下看起来简单的事物在真实生活中的复杂性。
为了可靠地测量延迟，服务器必须同步，因为请求通常由不同的服务器处理，并且我们已经看到服务器之间的时钟偏差会导致数据质量问题（例如，持续时间为负）。服务器经常同步其时钟非常重要。我们的示例没有将客户端和服务器时间混合在一起，因为它们可以位于不同的时区（请参见第13章），并且客户端时钟的可靠性通常较低，有时甚至会差好几年（例如，当电池耗尽时）。
下图显示了高度优化的网站（例如搜索引擎）的请求步骤。
步骤如下：
用户在时间T0发出请求，例如在浏览器地址栏或搜索框中键入查询，然后按回车键或单击放大镜。
该请求花费时间到达服务器，并且到达时间T1。 T1-T0似乎很难估计，但是我们可以使用一个不错的技巧来计算，之后进行解释。
在接收到请求时，服务器通常在时间T2处将HTML的第一块发送给客户端。该第一块独立于请求（例如查询或URL参数），因此可以快速提供服务。它通常包含基本的页面元素，例如标题，导航元素和JavaScript函数。向用户提供接收到请求的可见反馈是有益的：通常会清除页面，并显示带有某些页面装饰的标头，有时也称为chrome或frame。由于服务器需要时间（到时间T4）来计算页面的URL依赖部分（例如查询或URL参数），在T4 之前，服务器端传递给客户端的代码越多，整个页面加载时间越短；因为这这段时间网络比较空闲 （在比较闲的时间尽量把简单的事情做了）。
在时间T4，服务器开始发送页面的其余部分，这可能涉及其他数据（例如图像）。
在时间T6，浏览器将触发Onload事件，指示页面已准备就绪。此时，它发出一个日志请求，通常是一个简单的1×1图像请求（信标）或等效的请求。该请求在时间T7到达服务器。在Onload事件和其他日志记录之后，可能还会发生其他活动（例如，诸如滚动，悬停和点击之类的用户操作）。
用户体验的页面加载时间（PLT）为T6-T0，我们可以通过测量T7-T1来近似得出。由于初始请求到达服务器所花费的时间可能与Onload事件信标到达服务器所花费的时间非常相似（均为小请求），因此这两个增量可能非常相似，因此我们可以近似得出用户体验时间。
在支持新的W3C（万维网联盟）标准的新浏览器中，“导航计时”调用提供了多个与PLT相关的信息（请参阅www.w3.org/TR/navigation-timing/）。上面的测量更为通用，并且和来自W3C导航时间的数值匹配得很好。
