本文示例以PC的优化端为例，目前AE在这块的工作还主要在PC端，但文中的方法对无线端完全适用

1.1 什么是大数据驱动性能优化？

性能优化其实就是用各种可行的优化手段降低页面Latency，从而提升用户体验。通常会遇到如下困难：

Latency降低了，真的提升了用户体验吗？ 在AE的性能优化的灰度实验中，遇到了性能提升，转化率反而下降的情况，最后大家猛然醒悟，如果我的优化根本就是用户不可见的呢？比如减少了某个异步资源的加载，这个异步加载会降低pageload，但它可能就是一个用于统计的数据打点JS，加载了这个资源所耗时间并没有体现在用户的感观上。更极端一点说，Latency降低了，但这个降低引入了部分用户JS错误，甚至BLOCK了用户的下一步动作？可以通过大数据的方法识别出这样的问题。详见2.3。

Latency降低了，用户体验也提升了，但这个优化的投入成本较大，我是否应该投入？ 。通过度量大数据与业务转化的关系，可以精确量化性能优化所能带来的业务指标提升，从而精确计算性能优化的投入产出，也就容易判断是否值得投入。

以上讲述了通过大数据手段识别问题；度量投入产出；并且最终Review投入产出，给未来的性能优化提供知识和经验。

但事后对结果进行Review并没有体现出大数据的真正魅力，大数据的魅力在于把它在线应用起来，通过大数据结合算法对用户的场景和行为进行识别和预测，基于这个结果在线差异化优化性能，如预测用户的对下一个页面点击的可能性，从而在CDN中预先加载下一个页面的资源，提升性能和用户体验。

综上，大数据驱动性能优化是指运用大数据度量性能，以及基于大数据优化性能。

1.2 如何构建大数据驱动性能优化

1.2.1 如何运用大数据度量性能？

A. 找出接近用户感受的性能指标

页面的展现过程从DNS Lookup到页面的Fully Load，经历了很多步骤，这个步骤中有很多精细的度量指标。

对于用户来讲，最重要的一般是StartRender(白屏时间)，FirstScreen(首屏时间)，PageLoad(页面加载时间)，对于AE来讲，我们最关注的指标有StartRender及PageLoad。FirstScreen由于目前我们页面的特点及种不同终端使得这个数值目前还很难做到"准确"，因此暂时未参考。

B. 找出与性能相关的业务指标

性能不好时，用户更可能跳失，性能好时，用户更可能产生下一步动作。因此，通常来讲，转化率(CTR)和跳失率(Abandon Rate，或SAR)，但是并不能直接将CTR或SAR拿来计算，因为性能更容易影响用户的是第一次访问的时间，因此我们在度量业务贡献时采用的是第一次访问的PV点击率和PV跳失率。

另外业内也有数据显示，好的性能体验可以提升网站的整体pv，由于pv受到太多的业务因素影响，性能可能是特别小的因素之一，因此AE还没有对PV与性能的关系建立模型，如果哪位大神有这方面的经验和建议，欢迎与我们共建这块内容。

C. 基于大数据平台建立业务指标与性能指标的关联

通过以上找出的业务指标和性能指标，我们就可以通过某种模型来度量性能与业务的关系，从而指导性能优化的生产实践。

1.2.2 如何基于大数据优化性能？

A. 深入研究各种性能优化手段

回到最根本，想要优化性能，离不开各类性能优化的手段，个人对Native一点儿不懂，PC端的性能优化手段，请见本文3.1

B. 构建大数据模型，基于此与性能优化手段相结合，优化性能

目前我们想到的有两块可以利用大数据模型来进行性能优化的。第一是构建用户点击行为模型，能较准确的预测用户下一各可能点击的页面，并对页面内容活资源进行预先加载，比如预测用户在LIST中点击下一页的可能性，若大于90%，就将下一个页面的图片预先加载到CDN的边缘借点。

第二个是用户网络环境，用户对页面丰富度以及漂亮程度的依赖，用户页面化简从而实现快速呈现三者与用户转化活流失的关系模型。从而以用户转化最大化为目标，对不同网络环境的用户，呈现不同级别的页面，从而通过快速的性能体验提升转化。在这方面Gmail很早就上线了让慢加载的用户可以选择切换 "Load Basic HTML Page..."

第一章从通用概念角度讲解了大数据驱动性能优化。本章讲主要讲解AE的工作，AE如何通过大数据度量性能，系统架构如何，等等。

2.0 系统架构

系统分为数据采集层，数据计算层，应用层三层。顾名思义，架构简单，这里不累述。

2.1 性能度量

2.1.1 性能分布度量

各项指标的平均值不足以描述网站的性能情况，它不够微观，看不到展部用户如何，中间用户如何，全站有多少用户活在水深火热中，等等。因此我们采用不同性能情况下的流量占比来度量页面的性能。根据业内对各指标快、较快、慢、很慢范围的定义，我们找到各范转内的样本占比情况来度量性能好坏。如下图展示了3月16日至3月23日某页面PageLoad各性能范围里面的占比情况。

2.1.2 统一评分

如上性能分布虽然可以更真实的反映性能情况，但还是缺少一个统一的度量，统一评分就是基于分布情况，来用一个统一的加权值来反映性能分布情况。下图中红框里面的部分是指一个页面的一个指标的统一评分，如首页的PageLoad分数。依次类推，下图展示了各页面各指标->各页面->各站点->全站的展次结构中各层次的统一分数，而这个分数就来源于性能分布数据。

2.1.3 TP99，TP50，平均值

除此以上，平均值，TP50(中位数)，TP99仍然是需要重点关注的指标，我们完全不需要有了一个好的指标，就放弃其它指标，每个指标都从自己的角度出发，有很大的观测意义。

TP99是一个尤其值得关注的指标，它一方面代表了我们站点中性能体验最差的一批用户的性能情况；另一方面在一些基础优化时，可能只有对尾部有价值，如DNS的全球部点，它无法提升本来就已经在Local DNS中的LOOKUP，但它不在Local DNS中的请求提升非常大，此时TP99就是度量优化效果的最合适指标之一。

2.2 业务度量

2.2.1 性能与转化率的关系度量

更多详情前往http://www.atatech.org/articles/29988?rnd=220065575

2.2.2 性能损耗

性能损耗的计算方法是，假定网站核心转化链路页面的PageLoad Latency都到3S内，则依据每个页面的性能与转化率关系曲线可以得出，每个页面的转化率提升多少，这个提升转化为PV或点击，不断的向它的下一跳增长，最终可以得出订单数增长，订单数的增长比例即性能损耗。@桑植未来会专门有文章介绍这块的计算，有兴趣的同学先可以线下联系他。

2.3 性能评估

第1章中已经介绍，Latency的降低可能是"假象"，它甚至是引入错误，牺牲用户体验为代价的，那么如何度量识别这样的问题呢？如下图所示，相同的性能区间里面转化率应该是在一定时间内较稳定的，性能优化提升转化率是因为我们上性能好的区间里面流量变大了。基于2.2.1介绍的性能与转化率关系曲线，如果性能优化后，同样性能区间的转化率有所下降，则证明引入了问题，否则证明是一个正常的优化。在我们的实际项目中，就通过这个方法发现了问题。

对于基于大数据优化性能目前AE还处于初级阶段，只是YY并无实施，这一章的目的除了逻辑上的完整外哈哈，另一方面想发起更多的思考，让更多的人一起来建设这块内容。

3.1 性能优化手段介绍

3.2 资源预取

资源预取已经是一个性能优化里面的成熟手段，浏览器就支持页面预取，以及DNS预取等。

CDN也同样支持预取的概念，可以把用户需要的图片等资源预先加载到边缘节点(离用户最近的节点)，我们可以利用CDN的这一特性，通过算法预估用户最有可能点击的下一个页面，可能的点击概率如何，若大于一定值，就将下一个页面的资源预先加载到边缘节点。

同样，我们的ESI静态资源可以放在L1上面，点击预测可以同样有助于我们提升ESI的命中率。

3.3 个性化展现

基于对用户的画像，如国家民族，历史的购物行为，接入的网络环境等，可以对不同类的用户推送不同层次的页面，最终达到转化率的最大化。这个是个人认为值得去探索的一个方向，尤其是集团全球化，会面临各种网络条件、种族文化的用户，他们的网络接入条件不同，对慢的忍耐程度也不同，试想在偏远的非洲，他们也许不需要丰富多采的页面，只需要拿着手机，访问简单的WAP页面，完成浏览下单就可以了。