一个慢腾腾的网站，可能会让许多关键的访客和用户失去耐心，造成交易量降低、品牌形象变差，以及更高的“跳出率”。目前看来，无论网站是否提供在线交易的功能和服务，性能优化都已经不再是可选项，而是必选项。
那么，应该如何更加科学地评价Web性能优化技术及其背后的CDN厂商呢？
性能评价方法：“模拟测试” 和 “RUM”
在讨论“性能评价”这个话题的时候，我们都会非常频繁地说到这样一个词：模拟测试（Synthetic Measurements）。
尽管现在业界都在使用真实客户监测（RUM：Real User Monitor）的数据，来衡量真实的用户体验，但RUM并不是一个放之四海而皆准的一个标准。因为：
在某些场景下，我们无法得到真实用户的数据，因此，“模拟测试”就成为了我们的另外一个选择。
”模拟测试“怎么做？本文列举一些方法，希望能够帮助大家更好地分析、评价。
考虑到CDN已然是Web网站的标配，因此在如下案例方法中，都假设已使用CDN，而且都处于“上线前（Pre-Production）”的环境之下。
性能评测及优化的5个步骤
步骤1：搭建环境
当对某一Web站点可能使用的多个CDN厂商进行评估时，每一个厂商都应该提供一个不需要客户进行任何改动的模拟环境。
并且，CDN厂商应该提供“测试”域名，来尽可能真实地模拟生产环境的网站。
举个例子：假设待评测网站域名是 www.customer.com，CDN厂商服务域名是 xxxx.com，那么厂商应提供的临时测试域名通常为：
www.customer.com.xxxx.com
步骤2：环境确认
临时测试域名应该是“完全”与生产用站点对应匹配的。我们建议的检查清单如下，大家可按此进行检查：
对象数量一致，在测试域名下的对象数量，应该和真实网站所包含的对象数量一致；
文件总大小一致，测试网站的字节数应该和真实网站一致。当然，由于每一个厂商采用的压缩方式不同，其字节数可以比真实网站“略小”；
缓存规则一致，所有CDN厂商使用的缓存规则应该要一致，因为有一些厂商可以缓存动态请求（比如缓存html页面的整体框架）。
如果某个厂商可以做到这一点但是其他厂商不行，那么这个测试的公允性就值得质疑，因为那些采取更加激进的缓存策略的厂商就会获得优势。所以在正式开始之前，我们必须对配置进行一次全面的核查。
步骤3：性能测试方案的设定
在测试环境妥善搭建之后，下一步就是要对真实的性能测试方案进行设定。建议在设置“正确”的测试方案之前，应思考如下问题：
1.测试的类型是什么？
就像我们提及的，在对没有处于真实生产阶段的网站配置进行评估的时候，是没有“真实用户”的，没有真实用户，就没有真实用户数据。这时候，我们就需要采取综合测试的方式来进行衡量。
综合测试可以提供一个“清洁屋”式的测试环境，来方便我们对性能进行衡量。但是，即便是综合测试，也是分许多种类的，如：骨干网络性能测试、最后一公里测试、蜂窝网络测试（也称移动网络测试）等等。
相对于骨干网络性能测试，最后一公里测试可能更加能够反映真实的用户体验情况；而如果网站或者公司拥有大量的移动端接入客户，那么就一定要在移动网络下进行性能测试。这也会引发关于不同供应商对移动端进行加速的能力和技术的讨论。
2.采用什么样的性能测试平台？
总体来说，推荐使用在你所处行业内有一定业务经验和业绩的第三方测试平台。做一些简单的调查，看看有哪些公司在你所处的行业内发布过与性能有关的信息、指数或者文章。
不要使用某个厂商内部的特定测试工具，否则测试的结果会带有非常明显的倾向性。一个好的模拟测试平台应该拥有一批稳定的分布于全国/全球的测试节点，这些测试节点最好能和您业务重点区域相一致。
注意：这些测试节点应该在浏览器上模拟真实用户的种种行为。有些测试平台使用仿真浏览器，而不是真实浏览器。仿真浏览器只能捕捉网络时间，而真实的浏览器则可以获取前端（或“渲染”）时间、浏览器缓存和并行链接等数据。
因此，如果有条件，还是要使用“真实浏览器”进行测试。
3.测试应该在哪里进行？
测试地点应该包括“跨域分发”（也就是说跨越洲际和国家）以及“域内分发”两种情况。在这里，需要再次强调的是，由于业务不同和所面对的用户类型不同，这两种测试都需要进行考虑。
如果是面向全球的业务，源站服务器位于北美，而需要向全球用户进行分发，那么就应该对美国和美国以外的远距离地点进行性能测试，而不是只关注美国国内的用户体验。
如果是仅仅面向国内的业务，则也需要考虑不同运营商的问题，至少目前为止，电信、联通之间的”墙“，还很牢固。
4.测试对象应该包括什么？
典型的网站交互行为会包含对多个页面的访问和使用，这是用户在网站上完成一个任务或行为的通常模式，这也是我们需要进行测试的对象，这样做是出于两个目的：
首先，这能够模拟一个最终用户可能在真实情景下所体会到的性能；
其次，这能够帮助您了解一个优化解决方案可以给网站带来怎样的收益。
可能有个优化方案A可以给某一种特定类型的页面带来好处，而另一种优化方案B可能会给其他类型页面带来改善，这取决于站点的结构、数据或者对象的特性。
如果仅局限于对单个对象进行测试、并以此判断缓存的收益，或者仅仅关注“基础”的html页面、而不对其他种种特性复杂的对象、微小的API交互行为进行测试，这样很可能导致以偏概全，也无法观测到解决方案的真实效果，以及是否真的适用。
5.测试应该跑多久？
测试时间应该包括高峰时段和非高峰时段。一般来说，3到5天的数据总和是比较具有参考价值的。如果测试的时间过短，比如说只有几个小时，那么由于网络状况的不稳定和用户数量的变化没有得到真实反映，测试得到的数据也很难是真实的。
6.测试的频率应该是怎样？
高频率的测试能够反映流量高峰时的场景，在这种情况下，缓存中的内容总是新的，且可以命中；而低频率的测试则反映出非流量高峰时的情况，此时，内容可能是从你的源站一次一次抓取回来的。
一般情况下，我们建议每30分钟发起一次测试，这样可以反映出一个比较真实的流量模拟。
最后还要注意，测试期间源站带宽的用量可能有所上升，请提前做好准备。
步骤4：性能指标的评估
以下为一个测试结果的示例，其中包含了各种评估性能测试结果的参数，供大家参考。
其中一个非常有用的参数，就是展示一个完整用户交互过程的一系列页面响应时间的加总数值。同样，在使用了前端优化技术的场景下，W3C专有的完整 DOM数值也非常有用。
直方图：测试结果直方图可以帮助你了解在优化之前和优化之后的测试结果分布。
我们来看上面两个图表。
从第一张图，两个CDN厂商的测试结果，很难看出来哪个更好；但是，从第二张直方图上，我们可以清楚地看到，蓝色这家CDN厂商的效果更好，因为：
加载时间小于7秒的所有用户（包括6秒、6.5秒和7秒）的占比总和，蓝色比橙色多了15%。
这种图表同样也可以帮助我们排除测试中的异常值。
深入分析：除了总体测试参数之外，我们还应该在如下方面多花一些时间：
1.以测试地点为维度对结果进行细分
如果单纯只看“表现好”和“表现不好”这两个简单的参数，那测试结果可能会被曲解。所以按地点对性能测试结果进行分析，对于业务来说就非常重要。
2.以交互步骤为维度对结果进行细分
某些性能优化解决方案可能不会对交互行为的某一个或者某几个步骤起作用。
比如，一个交互动作可能包括上传一个文件。但是并不是所有的CDN供应商都有能够帮助上传提速的能力。
按照不同的交互步骤来观察相应的时间，可以帮助我们选择更加符合自己业务需求的CDN厂商。
3.可用性
大家不要被自己误导了！有时，测试结果显示的可用性下降很有可能是由于脚本错误，而不是CDN厂商的问题。
根据经验，性能指标仅应该从测试的健康可用性（90%+）这个角度进行衡量，另外10%，可能是因为测试平台自身的问题。
4.带宽负载
CDN厂商应该能够提供全面的点击及带宽负载数据，只有这样才能对节省下来的费用进行测算。这也可以帮助客户在选定某个厂商之后，对其源站基础设施的投资力度进行规划。
步骤5：其他需要考虑的因素
除了解决方案的性能之外，还应该从如下一些维度对每个CDN厂商进行考评：
1.CDN节点覆盖
许多厂商都宣称自己的节点能够覆盖全国或全球，但是他们可能在某一个区域的覆盖率较低，而这个区域恰恰是你业务的重点。所以必须要对厂商的网络规模进行调查。
2.业务吻合程度
一个良好的、专业的厂商的解决方案路线图，应该是目光长远的。随着业务的扩展，厂商必须在那些对于客户业务大有裨益的领域扩展其服务。
3.客户解决方案和支持能力
许多公司都选择和那些有专门服务团队的厂商合作，旨在获取其平台上的定制化支持服务：
有些公司希望厂商提供7x24的客户服务支持；有些公司则希望厂商提供大量API，以充分发挥自己团队的技术能力，更灵活地处理和解决问题。
哪一种方式更合适您？这往往取决于您自身业务特点和您自有技术团队的支持能力。
最后
一个好的CDN厂商，应遵循这些建议，来帮助其客户评价各种优化解决方案的真实性能，特别是在市场上的同类产品比较多的情况下。
在上述实践方式的指引下，相信用户会做出适合自己的选择。